diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 00000000..541dd010 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,66 @@ +######## +# +# In the event that a file is not covered by policies below, the +# Community Structure WG should advise changes or create a new +# CODEOWNERS entry for it. +# +# NOTE: If the GitHub automated reviewers do not behave as expected, +# please contact the Community Structure WG. +* @finos/ccc-wg-community-structure +.github/CODEOWNERS @finos/ccc-wg-community-structure +# +######## + +######## +# +# Changes that might impact automation must be reviewed by the Delivery WG +# Code owners should only be modified by the SteerCo +.github @finos/ccc-wg-delivery +.github/CODEOWNERS @finos/ccc-steerco +# +######## + +######## +# +# Community Guidelines only need review from the Community Structure WG +docs/governance/community-guidelines @finos/ccc-wg-community-structure +# +######## + +######## +# +# Each WG may place ad hoc documentation in their governance subdirectory +docs/governance/working-groups/communications @finos/ccc-wg-communications +docs/governance/working-groups/community-structure @finos/ccc-wg-community-structure +docs/governance/working-groups/delivery @finos/ccc-wg-delivery +docs/governance/working-groups/duplication-reduction @finos/ccc-wg-duplication-reduction +docs/governance/working-groups/security @finos/ccc-wg-security +docs/governance/working-groups/taxonomy @finos/ccc-wg-taxonomy +# +######## + +######## +# +# Changes to the services directory must be reviewed by the Taxonomy WG +# excluding threats and controls definitions +services @finos/ccc-wg-taxonomy +# +######## + +######## +# +# Threats or controls definition changes must be reviewed by the Security WG +**/threats.md @finos/ccc-wg-security +**/controls.md @finos/ccc-wg-security +# +######## + +######## +# +# Charters and policies require review from at least one SteerCo member +# Policies also require review from the Community Structure WG +docs/governance/steering @finos/ccc-steerco +docs/governance @finos/ccc-steerco @finos/ccc-wg-community-structure +**/charter.md @finos/ccc-steerco +# +######## diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md deleted file mode 100644 index 2baa2721..00000000 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -name: "\U0001F41B Bug Report" -about: "If something isn't working as expected \U0001F914." -title: '' -labels: '' -assignees: '' - ---- - -## Bug Report - -### Steps to Reproduce: - 1. ...step 1 description... - 2. ...step 2 description... - 3. ...step 3 description... - -### Expected Result: -...description of what you expected to see... - -### Actual Result: -...what actually happened, including full exceptions (please include the entire stack trace, including "caused by" entries), log entries, screen shots etc. where appropriate... - -### Environment: -...version and build of the project, OS and runtime versions, virtualised environment (if any), etc. ... - -### Additional Context: -...add any other context about the problem here. If applicable, add screenshots to help explain... diff --git a/.github/ISSUE_TEMPLATE/generic_issue_template.md b/.github/ISSUE_TEMPLATE/generic_issue_template.md deleted file mode 100644 index a83a2fbd..00000000 --- a/.github/ISSUE_TEMPLATE/generic_issue_template.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -name: "\Generic template" -about: "If you need to raise any other issue" -title: '' -labels: '' -assignees: '' - ---- - -## Add title here - -...add content here diff --git a/.github/ISSUE_TEMPLATE/minutes_all-hands-comms.md b/.github/ISSUE_TEMPLATE/minutes_all-hands-comms.md new file mode 100644 index 00000000..a56092f8 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/minutes_all-hands-comms.md @@ -0,0 +1,42 @@ +--- + +name: All Hands (Communications WG) Meeting Minutes +about: To track Common Cloud Controls meeting agenda and attendance +title: MM/DD/YYYY All Hands Meeting Minutes +labels: + - meeting + - communications +assignees: 'alexstpierrework' +projects: + - finos/18 +--- + +## Date + +MM/DD/YYYY - (X)am ET / (Y)pm UK + +- [Join Zoom Meeting](https://zoom.us/j/94416168360) +- Meeting ID: 944 1616 8360 +- Passcode: 042805 +- [Find your local number](https://zoom.us/u/apjhwwA3K) +- [Copy this meeting to your calendar](calendar.finos.org) + +## Meeting notices + +- FINOS **Project leads** are responsible for observing the FINOS guidelines for [running project meetings](https://community.finos.org/docs/governance/meeting-procedures/). Project maintainers can find additional resources in the [FINOS Maintainers Cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet). +- **All participants** in FINOS project meetings are subject to the [LF Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) and all other [FINOS policies](https://community.finos.org/docs/governance/#policies). +- FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions. +- FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available. + +## Agenda +- [ ] Convene & roll call (5mins) +- [ ] Display [FINOS Antitrust Policy summary slide](https://community.finos.org/Compliance-Slides/Antitrust-Compliance-Slide.pdf) +- [ ] Review Meeting Notices (see above) +- [ ] Approve past meeting minutes +- [ ] [Project board](https://github.com/orgs/finos/projects/78/views/11) walkthrough +- [ ] ... +- [ ] AOB, Q&A & Adjourn (5mins) + +## Untracked attendees +- Fullname, Affiliation, (optional) GitHub username +- ... diff --git a/.github/ISSUE_TEMPLATE/project-name-data-meeting-minutes.md b/.github/ISSUE_TEMPLATE/minutes_community-structure.md similarity index 57% rename from .github/ISSUE_TEMPLATE/project-name-data-meeting-minutes.md rename to .github/ISSUE_TEMPLATE/minutes_community-structure.md index d39feebe..8e5c8554 100644 --- a/.github/ISSUE_TEMPLATE/project-name-data-meeting-minutes.md +++ b/.github/ISSUE_TEMPLATE/minutes_community-structure.md @@ -1,34 +1,30 @@ ---- -name: Common Cloud Controls Meeting Minutes -about: To track Common Cloud Controls meeting agenda and attendance -title: MMDDYYYY Common Cloud Controls Meeting Minutes -labels: meeting -assignees: '' - --- ---- -name: "\U0001F91DCommon Cloud Controls Meeting Minutes" +name: Community Structure WG Meeting Minutes about: To track Common Cloud Controls meeting agenda and attendance -title: MMM DD YYYY - Common Cloud Controls Meeting Minutes -labels: Common Cloud Controls, meeting -assignees: '' +title: MM/DD/YYYY All Hands Meeting Minutes +labels: + - meeting + - community structure +assignees: 'sshiells-scottlogic' --- + ## Date -YYYYMMDD - (X)am ET / (Y)pm UK -## Untracked attendees -- Fullname, Affiliation, (optional) GitHub username -- ... +MM/DD/YYYY - (X)am ET / (Y)pm UK -## Meeting notices -- FINOS **Project leads** are responsible for observing the FINOS guidelines for [running project meetings](https://community.finos.org/docs/governance/meeting-procedures/). Project maintainers can find additional resources in the [FINOS Maintainers Cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet). +- [Join Zoom Meeting](https://zoom.us/j/99708793584) +- Meeting ID: 997 0879 3584 +- Passcode: 718089 +- [Copy this meeting to your calendar](calendar.finos.org) +- [Find your local number](https://zoom.us/u/abu2VMzm1v) -- **All participants** in FINOS project meetings are subject to the [LF Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) and all other [FINOS policies](https://community.finos.org/docs/governance/#policies). +## Meeting notices +- FINOS **Project leads** are responsible for observing the FINOS guidelines for [running project meetings](https://community.finos.org/docs/governance/meeting-procedures/). Project maintainers can find additional resources in the [FINOS Maintainers Cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet). +- **All participants** in FINOS project meetings are subject to the [LF Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) and all other [FINOS policies](https://community.finos.org/docs/governance/#policies). - FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions. - - FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available. ## Agenda @@ -36,48 +32,10 @@ YYYYMMDD - (X)am ET / (Y)pm UK - [ ] Display [FINOS Antitrust Policy summary slide](https://community.finos.org/Compliance-Slides/Antitrust-Compliance-Slide.pdf) - [ ] Review Meeting Notices (see above) - [ ] Approve past meeting minutes -- [ ] [Project board](https://github.com/orgs/finos/projects/78/views/4) walkthrough (filter by WG label, start right to left) +- [ ] [Project board](https://github.com/orgs/finos/projects/78/views/12) walkthrough - [ ] ... - [ ] AOB, Q&A & Adjourn (5mins) -### Zoom info -Join Zoom Meeting -https://zoom.us/j/93861901920 - -Meeting ID: 938 6190 1920 -Passcode: 284383 - ---- - -Dial by your location -• +1 719 359 4580 US -• +1 253 205 0468 US -• +1 253 215 8782 US (Tacoma) -• +1 301 715 8592 US (Washington DC) -• +1 305 224 1968 US -• +1 309 205 3325 US -• +1 312 626 6799 US (Chicago) -• +1 346 248 7799 US (Houston) -• +1 360 209 5623 US -• +1 386 347 5053 US -• +1 507 473 4847 US -• +1 564 217 2000 US -• +1 646 558 8656 US (New York) -• +1 646 931 3860 US -• +1 669 444 9171 US -• +1 669 900 6833 US (San Jose) -• +1 689 278 1000 US -• 855 880 1246 US Toll-free -• 877 369 0926 US Toll-free -• +1 438 809 7799 Canada -• +1 587 328 1099 Canada -• +1 647 374 4685 Canada -• +1 647 558 0588 Canada -• +1 778 907 2071 Canada -• +1 780 666 0144 Canada -• +1 204 272 7920 Canada -• 855 703 8985 Canada Toll-free - -Meeting ID: 938 6190 1920 - -Find your local number: https://zoom.us/u/acPjHdY2IO +## Untracked attendees +- Fullname, Affiliation, (optional) GitHub username +- ... diff --git a/.github/ISSUE_TEMPLATE/minutes_delivery.md b/.github/ISSUE_TEMPLATE/minutes_delivery.md new file mode 100644 index 00000000..5dd7deae --- /dev/null +++ b/.github/ISSUE_TEMPLATE/minutes_delivery.md @@ -0,0 +1,41 @@ +--- + +name: Delivery WG Meeting Minutes +about: To track Common Cloud Controls meeting agenda and attendance +title: MM/DD/YYYY All Hands Meeting Minutes +labels: + - meeting + - delivery +assignees: 'damienjburks' + +--- + +## Date + +MM/DD/YYYY - (X)am ET / (Y)pm UK + +- [Join Zoom Meeting](https://zoom.us/j/93010138669) +- Meeting ID: 930 1013 8669 +- Passcode: 432980 +- [Copy this meeting to your calendar](calendar.finos.org) +- [Find your local number](https://zoom.us/u/aeflbEDu94) + +## Meeting notices + +- FINOS **Project leads** are responsible for observing the FINOS guidelines for [running project meetings](https://community.finos.org/docs/governance/meeting-procedures/). Project maintainers can find additional resources in the [FINOS Maintainers Cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet). +- **All participants** in FINOS project meetings are subject to the [LF Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) and all other [FINOS policies](https://community.finos.org/docs/governance/#policies). +- FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions. +- FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available. + +## Agenda +- [ ] Convene & roll call (5mins) +- [ ] Display [FINOS Antitrust Policy summary slide](https://community.finos.org/Compliance-Slides/Antitrust-Compliance-Slide.pdf) +- [ ] Review Meeting Notices (see above) +- [ ] Approve past meeting minutes +- [ ] [Project board](https://github.com/orgs/finos/projects/78/views/8) walkthrough +- [ ] ... +- [ ] AOB, Q&A & Adjourn (5mins) + +## Untracked attendees +- Fullname, Affiliation, (optional) GitHub username +- ... diff --git a/.github/ISSUE_TEMPLATE/minutes_duplication-reduction.md b/.github/ISSUE_TEMPLATE/minutes_duplication-reduction.md new file mode 100644 index 00000000..bb0e470e --- /dev/null +++ b/.github/ISSUE_TEMPLATE/minutes_duplication-reduction.md @@ -0,0 +1,41 @@ +--- + +name: Duplication Reduction WG Meeting Minutes +about: To track Common Cloud Controls meeting agenda and attendance +title: MM/DD/YYYY All Hands Meeting Minutes +labels: + - meeting + - duplication reduction +assignees: 'jared-lambert' + +--- + +## Date + +MM/DD/YYYY - (X)am ET / (Y)pm UK + +- [Join Zoom Meeting](https://zoom.us/j/94109603410) +- Meeting ID: 941 0960 3410 +- Passcode: 353234 +- [Copy this meeting to your calendar](calendar.finos.org) +- [Find your local number](https://zoom.us/u/ab9zAHYy5T) + +## Meeting notices + +- FINOS **Project leads** are responsible for observing the FINOS guidelines for [running project meetings](https://community.finos.org/docs/governance/meeting-procedures/). Project maintainers can find additional resources in the [FINOS Maintainers Cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet). +- **All participants** in FINOS project meetings are subject to the [LF Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) and all other [FINOS policies](https://community.finos.org/docs/governance/#policies). +- FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions. +- FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available. + +## Agenda +- [ ] Convene & roll call (5mins) +- [ ] Display [FINOS Antitrust Policy summary slide](https://community.finos.org/Compliance-Slides/Antitrust-Compliance-Slide.pdf) +- [ ] Review Meeting Notices (see above) +- [ ] Approve past meeting minutes +- [ ] [Project board](https://github.com/orgs/finos/projects/78/views/13) walkthrough +- [ ] ... +- [ ] AOB, Q&A & Adjourn (5mins) + +## Untracked attendees +- Fullname, Affiliation, (optional) GitHub username +- ... diff --git a/.github/ISSUE_TEMPLATE/minutes_security.md b/.github/ISSUE_TEMPLATE/minutes_security.md new file mode 100644 index 00000000..aee6ab97 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/minutes_security.md @@ -0,0 +1,41 @@ +--- + +name: Security WG Meeting Minutes +about: To track Common Cloud Controls meeting agenda and attendance +title: MM/DD/YYYY All Hands Meeting Minutes +labels: + - meeting + - security +assignees: 'mlysaght2017' + +--- + +## Date + +MM/DD/YYYY - (X)am ET / (Y)pm UK + +- [Join Zoom Meeting](https://zoom.us/j/99521272221) +- Meeting ID: 995 2127 2221 +- Passcode: 128200 +- [Copy this meeting to your calendar](calendar.finos.org) +- [Find your local number](https://zoom.us/u/aUVBvM9h) + +## Meeting notices + +- FINOS **Project leads** are responsible for observing the FINOS guidelines for [running project meetings](https://community.finos.org/docs/governance/meeting-procedures/). Project maintainers can find additional resources in the [FINOS Maintainers Cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet). +- **All participants** in FINOS project meetings are subject to the [LF Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) and all other [FINOS policies](https://community.finos.org/docs/governance/#policies). +- FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions. +- FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available. + +## Agenda +- [ ] Convene & roll call (5mins) +- [ ] Display [FINOS Antitrust Policy summary slide](https://community.finos.org/Compliance-Slides/Antitrust-Compliance-Slide.pdf) +- [ ] Review Meeting Notices (see above) +- [ ] Approve past meeting minutes +- [ ] [Project board](https://github.com/orgs/finos/projects/78/views/7) walkthrough +- [ ] ... +- [ ] AOB, Q&A & Adjourn (5mins) + +## Untracked attendees +- Fullname, Affiliation, (optional) GitHub username +- ... diff --git a/.github/ISSUE_TEMPLATE/minutes_taxonomy.md b/.github/ISSUE_TEMPLATE/minutes_taxonomy.md new file mode 100644 index 00000000..f3b69fb2 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/minutes_taxonomy.md @@ -0,0 +1,41 @@ +--- + +name: Taxonomy WG Meeting Minutes +about: To track Common Cloud Controls meeting agenda and attendance +title: MM/DD/YYYY All Hands Meeting Minutes +labels: + - meeting + - taxonomy +assignees: 'smendis-scottlogic' + +--- + +## Date + +MM/DD/YYYY - (X)am ET / (Y)pm UK + +- [Join Zoom Meeting](https://zoom.us/j/994109603410) +- Meeting ID: 941 0960 3410 +- Passcode: 353234 +- [Copy this meeting to your calendar](calendar.finos.org) +- [Find your local number](https://zoom.us/u/ab9zAHYy5T) + +## Meeting notices + +- FINOS **Project leads** are responsible for observing the FINOS guidelines for [running project meetings](https://community.finos.org/docs/governance/meeting-procedures/). Project maintainers can find additional resources in the [FINOS Maintainers Cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet). +- **All participants** in FINOS project meetings are subject to the [LF Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), the [FINOS Community Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct) and all other [FINOS policies](https://community.finos.org/docs/governance/#policies). +- FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions. +- FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available. + +## Agenda +- [ ] Convene & roll call (5mins) +- [ ] Display [FINOS Antitrust Policy summary slide](https://community.finos.org/Compliance-Slides/Antitrust-Compliance-Slide.pdf) +- [ ] Review Meeting Notices (see above) +- [ ] Approve past meeting minutes +- [ ] [Project board](https://github.com/orgs/finos/projects/78/views/2) walkthrough +- [ ] ... +- [ ] AOB, Q&A & Adjourn (5mins) + +## Untracked attendees +- Fullname, Affiliation, (optional) GitHub username +- ... diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml new file mode 100644 index 00000000..cc81d1a5 --- /dev/null +++ b/.github/workflows/stale.yml @@ -0,0 +1,33 @@ +# This workflow warns and then closes issues and PRs that have had no activity for a specified amount of time. +# +# You can adjust the behavior by modifying this file. +# For more information, see: +# https://github.com/actions/stale +name: Mark stale issues and pull requests + +on: + schedule: + - cron: '18 22 * * *' + +jobs: + stale: + + runs-on: ubuntu-latest + permissions: + issues: write + pull-requests: write + + steps: + - uses: actions/stale@v5 + with: + repo-token: ${{ secrets.GITHUB_TOKEN }} + stale-issue-label: stale + stale-pr-label: stale + labels-to-remove-when-unstale: stale + days-before-stale: 30 + days-before-close: 7 + exempt-issue-labels: longstanding issue + stale-issue-message: This issue will be closed as stale in 7 days. Please update this issue if it is still needed. + stale-pr-message: This issue will be closed as stale in 7 days. If this issue is blocked, please tag or assign the appropriate party to move this forward. + close-issue-message: Closed as stale. An update may reopen this issue. + close-pr-message: Closed as stale. An update may reopen this PR. diff --git a/Readme.md b/Readme.md index 3048c79c..0a899c7a 100644 --- a/Readme.md +++ b/Readme.md @@ -2,65 +2,106 @@ -FINOS Common Cloud Controls (FINOS CCC) is the codename for an open standard project, originally proposed by Citi and currently incubating in FINOS, to describe consistent controls for compliant public cloud deployments in the financial services sector. +## What Is It? + +FINOS Common Cloud Controls (FINOS CCC) is an open standard project that describes consistent controls for compliant public cloud deployments in the financial services (FS) sector. This standard is a collaborative project which aims to develop a unified set of cybersecurity, resiliency, and compliance controls for common services across the major cloud service providers (CSPs). -You can read more and register your interest on [finos.org/common-cloud-controls-project](https://www.finos.org/common-cloud-controls-project). +## What Are The Benefits? -## FINOS CSLA Needed to Participate in Common Cloud Controls +#### 💯 Defining Best Practices Around Cloud Security -All FINOS Common Cloud Controls participants are required to sign a FINOS [Community Specification Contributor License Agreement](https://github.com/finos/standards-project-blueprint/blob/main/governance-documents/Getting%20Started.md#best-practices) before joining project calls and collaborating in working groups. +> CCC aims to standardize cloud security controls for the banking sector, providing a common set of controls that CSPs can implement to meet the requirements of FS firms. As multiple FS firms are involved in the project, effort is shared, the controls will be representative of the sector as a whole, and be more robust than any one firm could develop on its own. -Please visit [participants.md](participants.md) and raise a Pull Request by adding your `name`, `organisation` and `enrollment date` to the markdown file. +#### 🎯 One Target For CSPs To Conform To -Raising a Pull Request on [participants.md](participants.md) will automatically take you through the Linux Foundation EasyCLA process for signing the FINOS [CSCLA](https://github.com/finos/standards-project-blueprint/blob/main/governance-documents/Getting%20Started.md#best-practices). +> If all FS firms specify their own cloud infrastructure requirements, CSPs will have to conform to multiple standards. CCC aims to provide a single target for CSPs to conform to. -Email help@finos.org if you require further help. +#### 🎒 Sharing The Burden Of A Common Definition + +> CCC aims to reduce the burden of compliance for CSPs by providing a common definition of controls which they can adopt. As CCC controls are specified in a cloud-agostic way, CSPs can implement them in a way that is consistent with their own infrastructure, while delivering services that FS firms understand and trust. + +#### 🧭 A Path Towards Common Implementation + +> FINOS sister project, [Compliant Financial Infrastructure](https://github.com/finos/compliant-financial-infrastructure) aims to be a downstream implementation of the CCC controls standard. In tandem with CCC, this will provide FS firms with a one-stop shop for secure cloud infrastructure deployment. + +#### 🥇 A Path Towards Certification + +> It is envisaged that eventually, CCC will offer _certification_ for CSPs who conform to the standard. + +## How Does It Work? + +The CCC project is in **incubation** at the moment but aims to deliver its first standards in 2024. The project is split into 6 working groups, each with a specific focus: + +- **Communications / All Hands**: Focused on the overall project communications and community engagement. +- **Security** - Working to specify the security controls and threats that will be covered by the standard. +- **Community Structure** - Focused on the governance and structure of the CCC project. +- **Duplication Reduction** - Focused on ensuring that the CCC standard does not duplicate existing standards. +- **Taxonomy** - Focused on defining the taxonomy of cloud services that will be covered by the standard. +- **Delivery** - Focused on the delivery of the CCC standard for use downstream by FS firms and CSPs. + +Work is done in the open, with all meetings and decisions documented in the project GitHub repository. ## Get Involved with FINOS Common Cloud Controls There are several ways to contribute to FINOS Common Cloud Controls. -### Join FINOS CCC Project Meetings -FINOS Common Cloud Controls meets over Zoom and you can find future agendas and previous meetings below. +### 1. Join FINOS CCC Project Meetings + +The CCC project is split into 6 working groups in the CCC project which meet on a fortnightly basis: -- **FINOS Common Cloud Controls - Project All Hands** - [First Thursday of Each Month](https://github.com/finos/common-cloud-controls/issues?q=is%3Aissue+is%3Aopen+label%3Ameeting+label%3A%22All+Working+Groups%22) -- **OSCAL Representation of FINOS CCC** - [Second Thursday of Each Month](https://github.com/finos/common-cloud-controls/issues?q=is%3Aissue+is%3Aopen+label%3Ameeting+label%3A%22OSCAL+Representation+of+FINOS+CCC%22) -- **Engage with MITRE Threat Catalogue** - [Third Thursday of Each Month](https://github.com/finos/common-cloud-controls/issues?q=is%3Aissue+is%3Aopen+label%3Ameeting+label%3A%22Engage+with+MITRE+Threat+Catalogue%22) -- **Define Cloud Services Taxonomy** - [Fourth Thursday of each Month](https://github.com/finos/common-cloud-controls/issues?q=is%3Aissue+is%3Aopen+label%3A%22Define+Cloud+Services+Taxonomy%22+label%3Ameeting) +| Working Group | When | Chair | Mailing List | +| --- | --- | --- | --- | +| [Security](/docs/governance/working-groups/security/charter.md) | 4PM UK, 1st and 3rd Thursday each month | @mlysaght2017 | [ccc-security](mailto:ccc-security+subscribe@lists.finos.org) | +| [Delivery](/docs/governance/working-groups/delivery/charter.md) | 4:30PM UK, 1st and 3rd Thursday each month | @damienjburks | [ccc-delivery](mailto:ccc-delivery+subscribe@lists.finos.org) | +| [Communications / All Hands](/docs/governance/working-groups/communications/charter.md) | 5PM UK, 1st and 3rd Thursday each month | @Alexstpierrework | [ccc-communications](mailto:ccc-communications+subscribe@lists.finos.org) | +| [Taxonomy](/docs/governance/working-groups/taxonomy/charter.md) | 4:30PM UK, 2nd and 4th Thursday each month | @smendis-scottlogic | [ccc-taxonomy](mailto:ccc-taxonomy+subscribe@lists.finos.org) | +| [Community Structure](/docs/governance/working-groups/community-structure/charter.md) | 5PM UK, 2nd and 4th Thursday each month | @sshiells-scottlogic | [ccc-structure](mailto:ccc-structure+subscribe@lists.finos.org) | +| [Duplication Reduction](/docs/governance/working-groups/duplication-reduction/charter.md) | 5:30PM UK, 2nd and 4th Thursday each month | @jared-lambert | [ccc-duplication](mailto:ccc-duplication-reduction@lists.finos.org) | -Alternatively, find the next meeting on the [FINOS Community Calendar](https://finos.org/calendar) and browse [Past Meeting Minutes in GitHub](https://github.com/finos/common-cloud-controls/labels/meeting). +Find the next meeting on the [FINOS Community Calendar](https://finos.org/calendar) and browse [Past Meeting Minutes in GitHub](https://github.com/finos/common-cloud-controls/labels/meeting). + +### 2. Join the FINOS Common Cloud Controls Mailing Lists + +FINOS Common Cloud Controls communications are conducted through the ccc-participants@lists.finos.org mailing list. Simply email [ccc-participants+subscribe@lists.finos.org](mailto: ccc-participants+subscribe@lists.finos.org) to join. + + +### 3. Raise a FINOS Common Cloud Controls GitHub Issue + +FINOS Common Cloud Controls is maintained and run through GitHub. Simply [Raise a GitHub Issue](https://github.com/finos/common-cloud-controls/issues/new/choose) to ask questions or make suggestions. + +### FINOS CSLA Needed to Participate in Common Cloud Controls + +All FINOS Common Cloud Controls participants are required to sign a FINOS [Community Specification Contributor License Agreement](https://github.com/finos/standards-project-blueprint/blob/main/governance-documents/Getting%20Started.md#best-practices) before joining project calls and collaborating in working groups. + +Please visit [participants.md](participants.md) and raise a Pull Request by adding your `name`, `organisation` and `enrollment date` to the markdown file. + +Raising a Pull Request on [participants.md](participants.md) will automatically take you through the Linux Foundation EasyCLA process for signing the FINOS [CSCLA](https://github.com/finos/standards-project-blueprint/blob/main/governance-documents/Getting%20Started.md#best-practices). + +Email help@finos.org if you require further help. -### Join the FINOS Common Cloud Controls Mailing List -FINOS Common Cloud Controls communications are conducted through the ccc-participants@lists.finos.org mailing list. Simply email [ccc-participants@lists.finos.org](mailto:ccc-participants@lists.finos.org) to join. +### FINOS Code of Conduct -### Raise a FINOS Common Cloud Controls GitHub Issue +Participants of FINOS standards projects should follow the FINOS Code of Conduct, which can be found at: -FINOS Common Cloud Controls is maintained and run through GitHub. Simply [Raise a GitHub Issue](https://github.com/finos/common-cloud-controls/issues/new/choose) to ask questions or make suggestions. +## Governance -## FINOS CCC Project Maintainers +### FINOS CCC Steering Committee -FINOS Common Cloud Controls is maintained by FINOS members and the wider open source in finance community. +The CCC Steering Committee is the governing body of the CCC project, providing decision-making and oversight pertaining to the CCC project bylaws, sub-organizations, and financial planning. The Steering Committee also defines the project values and structure. [Documented here](docs/governance/steering/charter.md). -The following are the FINOS CCC maintainers, the firms they represent and the maintainer working group alignment. +| Name | Representing | Seat | +| -------------------- | -------------- | --------- | +| Jon Meadows | Citi | FSI | +| Oli Bage | LSEG | FSI | +| Simon Zhang | BMO | FSI | +| Paul Stevenson | Morgan Stanley | FSI | +| Robert Griffiths | Scott Logic | Community | +| Eddie Knight | Sonatype | Community | +| Adrian Hammond | Red Hat | Community | -| FINOS CCC Maintainer | Representing | FINOS CCC Working Group | -| -------------------- | -------------- | ------------------------------------------- | -| Jonathan Meadows | Citi | OSCAL Representation of CCC | -| Jason Nelson | Citi | Engage with MITRE Threat Catalogue | -| Mark Rushing | Citi | Define Cloud Services Taxonomy | -| Moe Matar | Citi | Define Cloud Services Taxonomy | -| Anna Selyugina | Goldman Sachs | Engage with MITRE & Cloud Services Taxonomy | -| Paul Stevenson | Morgan Stanley | Cloud Services Taxonomy & OSCAL Representation of CCC | -| Simon Zhang | BMO | Define Cloud Services Taxonomy | -| Adrian Hammond | Red Hat | Define Cloud Services Taxonomy | -| Naseer Mohammad | Google | Engage with MITRE Threat Catalogue | -| Valentin Mihai | Google | Engage with MITRE Threat Catalogue & OSCAL Representation of CCC| -| Rachel Kim | Google | OSCAL Representation of CCC | -| Raj Krishnamurthy | Compliance Cow | Engage with MITRE Threat Catalogue | -| Vicente Herrera | Control Plane | Define Cloud Services Taxonomy | -| Michaela Iorga | NIST | OSCAL Representation of CCC | +@robmoffat is the current [FINOS Point of Contact](docs/governance/finos-poc.md) for the CCC project. ## License diff --git a/docs/CCC-Kick-Off-Deck-3rd-Aug-2023/CCC-Kick-Off-Deck-3rd-Aug-2023.pdf b/docs/formation/CCC-Kick-Off-Deck-3rd-Aug-2023.pdf similarity index 100% rename from docs/CCC-Kick-Off-Deck-3rd-Aug-2023/CCC-Kick-Off-Deck-3rd-Aug-2023.pdf rename to docs/formation/CCC-Kick-Off-Deck-3rd-Aug-2023.pdf diff --git a/docs/Citi-Contributed-White-Paper/Financial-Services-Common-Cloud-Controls-Standard-v1.0-(for publication).pdf b/docs/formation/Financial-Services-Common-Cloud-Controls-Standard-v1.0.pdf similarity index 100% rename from docs/Citi-Contributed-White-Paper/Financial-Services-Common-Cloud-Controls-Standard-v1.0-(for publication).pdf rename to docs/formation/Financial-Services-Common-Cloud-Controls-Standard-v1.0.pdf diff --git a/docs/formation/bootstrap.md b/docs/formation/bootstrap.md new file mode 100644 index 00000000..f8c3c808 --- /dev/null +++ b/docs/formation/bootstrap.md @@ -0,0 +1,42 @@ +# Governance Bootstrap + +In March 2024, the CCC community identified a need for improved organizational structure to better enable contributions to the standard. + +This improvement work is being done in three phases, detailed below. + +Because this work includes the creation of strict charters and limitations on future change, it will only happen this way once. All subsequent changes must follow steps outlined in the respective group charters. + +# Phase 1 — Governance Bootstrapping + +The first, and most important step, is to create a charter and assign members to the top level organizational unit: the Steering Committee. This must be done through a consensus of the most active CCC participants from financial service institutions, with an opportunity for input from the entire community. + +Process: + +1. A proposed charter was presented on an off-calendar call +1. The greater community was notified via ccc-participants+subscribe@lists.finos.org +1. A feedback period was held for two (2) weeks, during which time feedback was incorporated from more than 10 community members +1. A consensus was achieved in an off-calendar call at the end of the feedback period +1. Additional fixes were incorporated for polish prior to merging + +# Phase 2 — Inaugural Steering Committee Appointments + +As the official election process inherently depends on an extant committee, the initial bootstrapping of the committee requires an appointing authority. + +Process: + +1. The greater community will be invited via ccc-participants+subscribe@lists.finos.org to self-nominate themselves by commenting on [PR #150](https://github.com/finos/common-cloud-controls/issues/150). +1. Reminders to self-nominate will be made in the next two community meetings, and _ad hoc_ as needed. +1. The FINOS Technical Oversight Committee (TOC) will present a list of eligible nominees to the FINOS Board of Directors during their next upcoming meeting. +1. Upon validation of eligibility and community support, the TOC and Board will formalize the nominations and the README will be subsequently updated to reflect said changes. + +# Phase 3 — Organizational Bootstrapping + +The Steering Committee (SC) will self-organize to define the community structure, document the processes surrounding it, and launch the inaugural community groups. The goal is to have this proccess quickly completed so that the subsequent groups are free to begin their work. + +Following the procedure set out in the SC charter: + +1. The SC will determine their exact scope of work and set a meeting cadence for the bootstrapping phase. +1. The SC will define and document the intended community structure, including all group types, member roles, and accountability structure. +1. The SC will set the charters for any inaugural groups, then appoint leadership as needed. +1. The SC will operate at a heightened awareness for the next two months, seeking to iterate on the community organizational structure and/or support community groups as needed. +1. Once established, community groups should self-organize according to their respective charters. diff --git a/docs/governance/community-groups.md b/docs/governance/community-groups.md new file mode 100644 index 00000000..0d762b18 --- /dev/null +++ b/docs/governance/community-groups.md @@ -0,0 +1,39 @@ +# Common Cloud Controls Community Structure + +The CCC community is organized into a structure that enables contributors from diverse backgrounds to collaborate on developing the Common Cloud Controls (CCC) standards. This structure ensures efficient governance, clear guidance for contributors, and effective management of the project's technical and non-technical aspects. + +All community group participants must strictly adhere to the the [FINOS Code of Conduct]. + +## Steering Committee + +The **Steering Committee (SC)** is the ultimate governance body of the CCC project, responsible for strategic oversight, financial planning, defining the project's values, high-level decision-making, and coordination with the FINOS TOC or Board. It also handles the overall project structure and delegation of responsibilities. + +While the [SC] is made of experts in the field of cybersecurity, it is intended to be a facilitator and overseer of excellent decision-making, rather than a technical decision-maker itself. + +Steering Committee membership is presented in the [README.md] of the main CCC repo. + +Review the [Steering Committee Charter] for more information. + +## Working Groups + +A working group (WG) is a subset of the community that has been chartered by the steering committee to accomplish or deliver within a specific scope. + +WGs are formed based on the needs identified by the [SC], following any applicable guidelines set forth by the Community Structure WG. + +## Community Governance + +The CCC community adheres to a transparent and open governance model. Decisions are made through consensus or vote, depending on the relevant group charter. + +Non-technical issues or high-level design decisions may be escalated to the [SC] if a decision or conflict is not resolved in a timely manner (relative to the time-sensitivity of the issue). + +Technical issues should be resolved by the relevant community group. Failure to resolve technical issues may be escalated to the [SC] for guidance on finding a resolution. + +## Changes to the Community Structure + +Changes to the community structure can be proposed through pull requests. All changes must be approved in accordance with the relevant group charter. + +--- + +[FINOS Code of Conduct]: +[Steering Committee Charter]: +[SC]: <#steering-committee> diff --git a/docs/governance/community-guidelines/README.md b/docs/governance/community-guidelines/README.md new file mode 100644 index 00000000..f4ac4b49 --- /dev/null +++ b/docs/governance/community-guidelines/README.md @@ -0,0 +1,22 @@ +# Community Guidelines + +Guidelines are formal recommendations to the community provided as structured outputs from the Community Structure [WG]. While these guidelines have not been approved by the [SC] as official community policy, it is strongly advised that each [WG] follow the recommendations. + +This directory will contain all guidelines recommended. + +## Adding or Modifying a Guideline + +- Changes can be suggested by anyone by raising a PR and notifying the Community Structure [WG] using the mailing list for consideration. +- Then the members of the Community Structure [WG] should discuss this issue in their [WG] meetings and approve the PR for it to become a recommendation. + +## Upgrading a Recommendation to become a Policy + +In order for a guideline to become a policy a [SC], they must be put forward for a [vote] by a [SC] member sponsor. + +1. A pull request should be made by the [SC] sponsor to move the guideline into the [Policies] directory. +2. The [SC] sponsor should call a [SC] [vote] and if approved by the majority the PR can be merged and the recommendation is now a policy. + +[Policies]: <../community-policies> +[vote]: <../steering/charter.md#voting> +[SC]: <../../community-groups.md#steering-committee> +[WG]: <../../community-groups.md#working-groups> \ No newline at end of file diff --git a/docs/governance/community-guidelines/communication.md b/docs/governance/community-guidelines/communication.md new file mode 100644 index 00000000..e82c00b3 --- /dev/null +++ b/docs/governance/community-guidelines/communication.md @@ -0,0 +1,42 @@ +# Communication + +This document is a [community guideline]. + +## Mailing Lists + +- A mailing list should be used as the main means of distributing written communications for all activities related to the CCC Project. +- Mailing lists should be requested for a [WG] by the sponsoring SteerCo member upon passage of the charter vote. + +## Meetings + +### FINOS Hosted Meetings + +All meetings hosted by FINOS are expected to follow FINOS Anti-Trust policies. + +Any meeting published on the public calendar must additionally adhere to a strict agenda, maintain public meeting minutes on this GitHub repo, and display the FINOS Anti-Trust slide at the beginning of the session. + +**IMPORTANT:** Any adjustments/cancellations to any FINOS hosted meetings MUST be coordinated with the [FINOS Point of Contact]. + +### SteerCo Reporting Meetings + +- Quarterly reporting meetings hosted by the [SC] should be attended by all [WG] leads or an appropriate delegate. +- These meetings will feature updates from each [WG] regarding the progress against their charter, followed by Q&A with the [SC]. Anyone may join to observe. +- These meetings should be hosted by FINOS and listed on the FINOS Calendar. + +### Recurring [WG] Meetings + +- A [WG] may choose to hold recurring meetings to provide a dedicated space for discussion of [WG]-specific activities. +- If a [WG] decides to have recurring [WG] meetings, then the details of the meeting should be published to members of the [WG] using the corresponding mailing list. +- If these meetings are hosted by FINOS they must follow the guidance for [FINOS hosted meetings](#finos-hosted-meetings). +- If these meetings are NOT hosted by FINOS then where practical, these meetings should have notes or minutes published to the rest of the [WG]. + +### Ad hoc [WG] Meetings + +- Ad hoc meetings between [WG] members can be scheduled between group members at their own discretion. +- If these meetings are hosted by FINOS they must follow the guidance for [FINOS hosted meetings](#finos-hosted-meetings). +- If these meetings are NOT hosted by FINOS then any noteworthy decisions or outcomes should be communicated back to the wider [WG] via the mailing list. + +[SC]: <../community-groups.md#steering-committee> +[WG]: <../community-groups.md#working-groups> +[community guideline]: <./README.md> +[FINOS Point of Contact]: <../finos-poc.md> \ No newline at end of file diff --git a/docs/governance/community-guidelines/meetings.md b/docs/governance/community-guidelines/meetings.md new file mode 100644 index 00000000..440fa78e --- /dev/null +++ b/docs/governance/community-guidelines/meetings.md @@ -0,0 +1,56 @@ +# Communication + +This document is a [community guideline]. + +## Chairing Meetings + +It is the responsiblity of the [WG] lead to chair the meetings for their [WG]. + +In the event the [WG] lead is unable to attend the meeting they should appoint an appropriate delegate from within the [WG] to chair the meeting in their absence. If there are no appropriate delegates for the [WG] then the [FINOS Point of Contact] can be contacted to see if they can chair the meeting. + +In the event there are no suitable people to chair the meeting then the meeting should be cancelled. + +### Responsibilities of the Chair + +The Chair of the meeting is responsible for: + +- Opening the Zoom Call: Start the meeting and admit participants. +- Minutes and Attendance: Ensure someone is taking minutes and that attendees log their attendance by commenting on the issue. +- Agenda Adherence: Ensure the meeting follows the agenda. +- Closing the Meeting: Conclude the meeting. + +## Meeting Agendas + +### Agenda Items + +The [WG] lead is responsible for creating an agenda for each meeting. The [WG] lead can seek input from other [WG] members via the mailing list. Alternatively, members can proactively suggest items by reaching out to the [WG] lead. + +### Creating the agenda + +To create a meeting agenda you can create a new issue in the CCC project on GitHub and selecting the `Common Cloud Controls Meeting Minutes` template. + +Update the issue with the correct date/time and add the [WG] name to the end of the issue title. + +Update the issue with the correct zoom details. + +Fill in the agenda items for the meeting, taking care not to delete any of the items predefined by the template. + +Add the `Meeting` label to the issue. + +## Meeting Minutes + +Minutes can be added as a comment to the corresponding GitHub issue. + +Consider circulating the minutes via the mailing list to increase visibility within the [WG]. + +## Post Meeting Housekeeping + +Once minutes are added to the GitHub issue, close the issue. + +## Cancelling a Meeting + +In the event that a meeting needs to be cancelled then the [FINOS Point of Contact] should be notified as soon as possible. The cancellation should also be communicated via the mailing list for the [WG]. + +[WG]: <../community-groups.md#working-groups> +[FINOS Point of Contact]: <../finos-poc.md> +[community guideline]: <./README.md> \ No newline at end of file diff --git a/docs/governance/community-guidelines/member-roles.md b/docs/governance/community-guidelines/member-roles.md new file mode 100644 index 00000000..bd912fd6 --- /dev/null +++ b/docs/governance/community-guidelines/member-roles.md @@ -0,0 +1,152 @@ +# Member Roles + +Everyone is welcome to contribute through discussion, issues, and pull requests. + +The following are roles and additional responsibilities that a person may recieve in the community. + +| Role | Responsibilities | Requirements | Defined by | +| ----- | ---------------- | ------------ | ------- | +| Member | Active contributor in the community, assist on community calls, give input on proposals | Sponsored by 2 reviewers after multiple contributions to the project | GitHub FINOS `ccc-members` Group Member | +| Approver | Review contributions from other members | History of quality reviews and authorship in a particular space | [CODEOWNERS] entry for specific files or directories | +| WG Lead | Set direction and priorities for a working group (WG) | Demonstrated responsibility and excellent technical judgement for the subproject | [CODEOWNERS] entry for all files or directories relating to the [WG] | + +## All New & Established Contributors + +Anyone attending a CCC meeting, event, or contributing in any way will be expected to follow the [Linux Foundation Code of Conduct]. + +New contributors should be welcomed to the community by existing members, helped with pull request (PR) +workflow, and directed to relevant documentation and communication channels. + +Established community members of **all roles** are expected to demonstrate technical and/or writing ability in their contributions, +adherence to the principles of the project, and familiarity with project organization +(roles, policies, procedures, conventions, etc). Role-specific expectations, responsibilities, +and eligibility requirements are enumerated below. + +## Member + +Members are continuously active contributors within the community. They can have issues or PRs +assigned to them and assist or scribe on community calls. + +**Defined by:** GitHub FINOS `ccc-members` Group Member + +### Eligibility Requirements + +- Enabled two-factor authentication on their GitHub account +- Actively contributing to 1 or more [WG] in the past three (3) months. +- Have made **multiple contributions** to the project or community, enough to + demonstrate an **ongoing and long-term commitment** to the project. +- Subscribed to the [community mail group] +- Applied, sponsored, and approved for member status. + 1. Open an pull request against the CCC repo [`members.md`](members.md): + - The PR description should contain a list or summary of your work on the project to date. + 2. Sponsoring reviewers mark the PR as ready to merge: + - Must be sponsored by 2 approvers from 2 employers. + - Sponsors must have close project interactions with the prospective member + (such as in PR review, proposal creation, coordinating on issues, etc.) + 3. Once your sponsors have approved, your request will be merged by the appropriate party within 14 days. + +### Definition of Contributions + +Contributions are meaningful engagements that advance the goals of the community. +These include, but are not limited to: + +- Submittion of impactful pull requests that are subsequently merged into the project's + repositories. +- Additive participation in discussions on issues, pull requests, or community forums + like mailing lists, Slack channels, or meetings. +- Contribution to design proposals or reviews. +- Assistance given in community management and organization, such as event planning or + managing community tools and resources. + +### Responsibilities and Privileges + +- Responsive to issues and PRs assigned to them. +- Participate actively in at least one [WG]. +- Scribe on community calls when necessary. +- Can have issues and PRs assigned to them. +- Can be invited to review and advise on PR approvals. +- Participation publicly documented in [`members.md`](members.md). + +## Approver + +Approvers review contributions from members and have a history of quality reviews +and authorship in a specific domain. + +Approvers are able to block or approve code contributions. Approval is focused on +holistic acceptance of a contribution including: backwards / forwards +compatibility, adhering to all conventions, subtle performance and +correctness issues, interactions with other parts of the system, and so forth. + +**Defined by:** [CODEOWNERS] entry or GitHub Team for a specific scope. + +### Requirements + +- Active _Member_ of the project for at least 3 months. +- History of quality reviews and contributions within a specific scope. +- Appointed by a [WG] Lead. + - Appointer may create a PR to add appointee to the [CODEOWNERS] file **OR** an issue requesting the appointee's addition to a GitHub Team for the appropriate scope. + - The PR/issue must remain open for seven (7) days to gather feedback, or until + all active approvers have responded, whichever is first. + - Any current approver may request changes or reject the appointment. + - Objections may be made for any reason, with or without public explanation. + - Objection appeals to the Steering Committee may be made by the appointer. + - **Note:** Adjustments to an approver's scope must follow this same process. + +### Responsibilities and Privileges + +- Provide thorough and practical reviews of contributions from other members. +- Ensure contributions meet the project's conventions and quality standards. +- May approve and merge PRs from other members, or block PRs with requests for changes. +- Adhere to the general responsibilities of a member. + +## WG Lead + +WG Leads set direction and priorities for a working group, demonstrating responsibility +and excellent technical judgement for the subproject. + +**Defined by:** [CODEOWNERS] entry for all files or directories relating to the [WG] **and** GitHub Team for the respective working group. + +### Requirements + +- Demonstrated responsibility and excellent technical judgement for the [WG] topic as an + _Approver_ for at least (3) months. +- Appointed by a [SC] vote. + - A [SC] sponsor must create a PR to update [`members.md`](members.md) with the new appointment. + - Extending [CODEOWNERS] scope for an individual must follow the approver nomination process. + - When appointment is confirmed, the sponsor must work with a repo admin to add appointee to the appropriate GitHub team(s) +- Adhere to relevant [community groups] guidelines, such as: + - Follow the corresponding [WG] Charter + - Ensure the proper execution of [WG] meetings + - Represent the [WG] in relevant accountability meetings, or delegate an eligible representative + +### Responsibilities and Privileges + +- Set direction and priorities for a WG, ensuring consistent progress. +- Present the [WG] status and progress to the rest of the community. +- Adhere to the general responsibilities of an _Approver_. + +## Inactive Members + +A core principle in maintaining a healthy community is encouraging active +participation. It is inevitable that people's focuses will change over time and +they are not expected to be actively contributing forever. + +Inactive members are those who carry an aforementioned role or title within CCC +with **zero** qualifying contributions in the preceding 6 months. + +Inactive members will be removed from their roles and will need to re-engage with the +community and go through the aforementioned processes again to regain their status. + +Specific group charters may specify a shorter period for their roles. + +--- + +[Linux Foundation Code of Conduct]: +[CODEOWNERS]: +[community mail group]: +[membership template]: +[Steering Committee]: <../steering/charter.md> +[community groups]: <../community-groups.md> + +[SC]: <../../community-groups.md#steering-committee> +[WG]: <../../community-groups.md#working-groups> \ No newline at end of file diff --git a/docs/governance/community-guidelines/proposing-working-group.md b/docs/governance/community-guidelines/proposing-working-group.md new file mode 100644 index 00000000..8aafd773 --- /dev/null +++ b/docs/governance/community-guidelines/proposing-working-group.md @@ -0,0 +1,14 @@ +# Proposing a Working Group + +To propose a new working group complete the items in the check list below: + +- Create a PR with a draft charter which follows this [template](./templates/charter.md). +- Find a [SC] member to sponsor the [WG]. +- The proposal must include the name of the [WG] Lead. +- The [SC] sponsor will call for a [vote] on the new [WG] when it is ready. +- If the proposal receives a majority [vote], it is immediately considered active and responsible to act according to its charter. +- After the [SC] has approved the [WG], the sponsor should promptly request a mailing list for the [WG] by contacting . The mailing list should use the naming convention `ccc-[wg-name]@lists.finos.org`. + +[WG]: <../../community-groups.md#working-groups> +[SC]: <../../community-groups.md#steering-committee> +[vote]: <../steering/charter.md#voting> diff --git a/docs/governance/community-guidelines/templates/charter.md b/docs/governance/community-guidelines/templates/charter.md new file mode 100644 index 00000000..c853ee72 --- /dev/null +++ b/docs/governance/community-guidelines/templates/charter.md @@ -0,0 +1,71 @@ +# Charter + +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) <*name of the working group*>. + +## Table of Contents + +1. [Mission](#mission) +2. [Approach & Responsibilities](#approach--responsibilities) + - [Output / Deliverables](#output--deliverables) +3. [Out of Scope](#out-of-scope) +4. [Meeting Cadence](#meeting-cadence) +5. [Governance](#governance) + - [Membership](#membership) + - [Changes](#changes) + - [Meeting Cadence](#meeting-cadence) + - [Changes](#changes) + +## Mission + +<*The mission of the working group and its high level role within the CCC project.*> + +## Approach & Responsibilities + +This group will: + +- <*A list detailing how this group will work, and things this group will be responsible for.*> + +### Output / Deliverables + +The following artifacts will be created and stored in the project GitHub repo: + +- <*A list of outputs / deliverables the working group should produce.*> + +## Out of Scope + +The following activities will not be performed by this group: + +- <*An explicit list of the items that do not fall within in the scope of this group's responsibility.*> + +## Governance + +This [WG] will remain compliant with all applicable community [policies]. At the guidance of the WG Lead, this group will seek to implement [recommendations] set forth by the Community Structure WG. + +<* Note:*** Refer to [Community Organization](../recommendations/community-organisation.md#roles-definition-for-a-working-group) for more information about WG composition. *> + +### Membership + +The membership structure of this working group: + +- WG Lead: <*name of the WG lead*> +- SC Sponsor: <*name of the SteerCo member who sponsored formation or continuation of this group*> + +### Sub-Groups + +- This group <*is or is not*> authorized to create independent sub-groups. <*Any additional details*> + +### Meetings & Communication + +- This working group will use the mail group for regular communications. +- <*Specify the types of meetings this working group will have in order to discuss the working group specific matters and their frequency*> (Please refer to [meetings](../recommendations/communication.md#meetings) for more information). +- <*Specify the types of meetings this working group will have to collaborate with other CCC working groups and their frequency*>. +- A group member should represent this [WG] on any calls scheduled by the [SC] for participation by the full CCC project community. + +### Changes + +Any functional changes to this charter must be approved through a majority vote by the [SC]. Minor changes such as formatting may be merged upon approval from any [SC] member. + +[WG]: <../../community-groups.md#working-groups> +[SC]: <../../community-groups.md#steering-committee> +[policies]: <../../community-policies/README.md> +[recommendations]: <../../community-recommendations/README.md> \ No newline at end of file diff --git a/docs/governance/community-policies/README.md b/docs/governance/community-policies/README.md new file mode 100644 index 00000000..b525e7d4 --- /dev/null +++ b/docs/governance/community-policies/README.md @@ -0,0 +1,14 @@ +# Community Policies + +Policies are rules which have been proposed by the Community Structure [WG] and which have been approved by [SC] to govern the operation of the CCC community. + +All [WG] charters should contain a reference to these policies, with a commitment to adhere to any policies that apply to that group's circumstance. This contrasts with [community-guidelines], which are recommendations that the community is strongly advised to consider. + +This directory will contain the latest version of all policies that must be adhered to for a [WG] to retain its charter. + +## Adding or Modifying a Policy + +Policies may be created or modified by a [vote] of the [SC] at any time, following the same process as [Upgrading a Recommendation to become a Policy](../community-guidelines/README.md/#upgrading-a-recommendation-to-become-a-policy). + +[SC]: <../../community-groups.md#steering-committee> +[vote]: <../steering/charter.md#voting> diff --git a/docs/governance/finos-poc.md b/docs/governance/finos-poc.md new file mode 100644 index 00000000..2e2a70a0 --- /dev/null +++ b/docs/governance/finos-poc.md @@ -0,0 +1,16 @@ +# FINOS Point-of-Contact (POC) + +Most administative tasks around FINOS projects are performed by [FINOS Help](help@finos.org), such as changing mailing lists, meeting cadence, tool support etc. + +CCC is currently a FINOS strategic initiative and as such as an appointed POC. This role is responsible for: + +1. Representing the project to the FINOS community. +2. Helping with CCC marketing, recruitment and promotion. +3. General advice around open source governance and community management. +4. Project administration tasks where necessary. +5. Engaging with other parts of the FINOS / LF organisation, including board-level reporting. + +The FINOS POC is responsible to the FINOS Board-appointed CCC Executive sponsors, who can set direction for the FINOS involvement in CCC as a strategic initiative, apart from the general CCC community goals. The FINOS POC is therefore also responsible for: + +1. Representing the interests of the CCC Executive sponsors to the project. +2. Attempting to action executive sponsors requests where possible. diff --git a/docs/governance/steering/charter.md b/docs/governance/steering/charter.md new file mode 100644 index 00000000..3ca904e8 --- /dev/null +++ b/docs/governance/steering/charter.md @@ -0,0 +1,181 @@ +# Common Cloud Controls Steering Committee Charter + +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) Steering Committee. + +## Mission + +The CCC Steering Committee is the governing body of the CCC project, providing decision-making and oversight pertaining to the CCC project bylaws, sub-organizations, and financial planning. The Steering Committee also defines the project values and structure. + +## Approach + +* Adapt the role and structure of the Steering Committee to meet the ongoing needs of the project. +* Responsibilities not explicitly delegated to other parties[2](#footnote2) through their respective charters reside with the Steering Committee. +* All management[1](#footnote1) responsibilities should be delegated to other parties[2](#footnote2). +* All technical responsibilities should be delegated to working groups. The Steering Committee should not retain any technical responsibilities itself. +* The steering committee will hold a public community call no less than once per quarter to provide updates to stakeholders regarding all CCC efforts. + +## Direct responsibilities of the Steering Committee + +The following responsibilities belong directly to the Steering Committee. + +* Define, evolve, and defend the non-technical vision / mission and the values of the project. +* Delegate ownership of, responsibility for, and authority over areas of the project to specific entities[2](#footnote2). +* Charter and refine policy for defining new community groups[3](#footnote3), and establish transparency and accountability policies for such groups. +* Appoint leadership for chartered community groups. +* Enforce charters for community groups[3](#footnote3) to ensure ongoing positive standing, or decomission any groups not in good standing. +* Define and evolve project and group[3](#footnote3) governance structures and policies[4](#footnote4). +* Act as a final non-technical escalation point for any CCC community group or technical effort. +* Decide who is a standing member on the CCC project, and what privileges that entails. +* Control and delegate access to and establish processes regarding project resources[5](#footnote5). +* Coordinate with FINOS regarding usage of the CCC brand and deciding which things can be called "Common Cloud Controls," as well as how that mark can be used in relation to other efforts or vendors. +* Request funds and other support from FINOS (e.g. marketing, press, etc). +* Interface with the FINOS Staff point of contact as needed for guidance and accountability. + +## Non-responsibilities of the Steering Committee + +* Technical decision-making. +* Chartering, approval, or oversight of any sub-groups created by Steering-chartered community groups (those which are authorized to do so within their charter). +* Files and resources outside of: + - the CCC project README.md + - Steering Committee governance documentation + +## FINOS Point of Contact + +In addition to general foundation support given to projects, the Steering Committee will have an assigned point of contact. This should be tracked in the same documentation as the list of current Steering Commmittee members. + +## Membership + +### Composition + +The Steering Committee is composed of seven (7) members and shall always be considered this size regardless of temporary vacancies, for the purpose of voting majority and supermajority considerations. + +**Reserved Seats —** Four (4) seats on the committee are reserved for FINOS members from financial services institutions. These seats may not be occupied by more than one individual from the same institution[6](#footnote6). In the event that a committee member occupying an FSI seat undergoes a change of employment, they may retain their seat while in noncompliance for 30 calendar days before it is automatically considered vacant. + +**Community Seats —** Three (3) seats on the committee are not reserved, and may be filled by any community member from any organization. + +### Elections + +Every year, the Steering Committee holds a general election for open seats. + +Our [election policy] document covers the details for how this works. + +### Vacancies + +In the event of a resignation or other loss of an elected committee member, the next most preferred candidate from the previous election will be offered the seat. A maximum of one (1) committee member may be selected this way between elections. + +In case this fails to fill the seat, a special election for that position will be held as soon as possible. + +[Eligible voters] from the most recent election will vote in the special election (eligibility will not be redetermined at the time of the special election). + +A committee member elected in a special election will serve out the remainder of the term for the person they are replacing, regardless of the length of that remainder. + +### Removal + +A committee member may remove themselves or be removed through the following processes. + +#### Resignation + +If a committee member chooses not to continue in their role, for whatever self-elected reason, they must notify the full committee in writing. + +#### No confidence + +A Steering Committee member may be removed by an affirmative vote of a **_three-quarters supermajority of the [fixed membership of the committee](#composition)_**. + +The call for a vote of no confidence will happen in a public Steering Committee meeting and must be documented as a GitHub issue in the repository. + +The call for a vote of no confidence must be made by a current member of the committee and must be seconded by another current member. The committee member who calls for the vote must include on the issue a statement which provides context on the reason for the vote. + +Once a vote of no confidence has been called, the committee will notify the community through the CCC mailing list. + +This notification will include: + +* a link to the aforementioned GitHub issue +* the statement providing context on the reason for the vote + +There will be a period of two (2) weeks for members of the community to reach out to Steering Committee members to provide feedback. + +Community members may provide feedback by the following methods: + +* comment on the GitHub issue +* send an email to the Steering Committee private mailing list + - the mailing list will be launched and linked here after the first phase of bootstraping is complete +* send a message to individual committee members + +After this feedback period, Steering Committee members must vote on the issue within 48 hours. + +If the vote of no confidence is passed, the member in question will be immediately removed from the committee. + +## Voting + +In the course of the committee's operations, members will be expected to vote on all decisions made within the body's purview. + +These votes may be called on agreed-upon platforms by the committee, such as: + +* a pull request +* an issue +* a Steering Committee [meeting](#meetings) +* a mailing list + +For public business, the vote must be captured on an issue or pull request. + +### Routine business + +Unless otherwise specified by a process, the requirement for passing a vote is a **_majority of the [fixed membership of the committee](#composition)_**. + +### Abstention + +For any self-elected reason, members of the committee may decide to abstain from a vote. + +Abstaining members will only be considered as contributing to quorum, in the event that a vote is called in a meeting. + +## Meetings + +Steering Committee members are generally expected to attend every meeting. + +### Quorum + +We use the following guidelines to determine whether we have reached quorum and are able to proceed with a meeting: + +- Quorum **to meet** is a **_majority of the [fixed membership of the committee](#composition)_**. +- Quorum **to vote in a meeting** is a **_two-thirds supermajority of the [fixed membership of the committee](#composition)_**. + +## Inclusive Leadership Training + +Members of the committee must take the [Inclusive Open Source Community Orientation] course +in support of our community values. Members are required to report completion of the course as part of on-boarding within 30 days from the date of their appointment. + +## Changes + +Committee members may propose a change to this document through the following process: + +- Post a pull request to this repository describing the change. +- Call a public vote for the nearest acceptable business day four (4) weeks after initial + introduction of the change. A vote may be scheduled earlier if all committee members consent. +- The change is accepted if three-quarters of the committee members vote in favor. +- The pull request is merged or closed. + +## Attribution + +This document was adapted from the Kubernetes Steering Committee Charter [afb3858]. + +## Footnotes + +1: Decisions and work pertaining to the daily operations of the project. + +2: Such as individuals and [community groups]. + +3: Community groups include Special Interest Groups, Working Groups, and Committees. + +4: This includes the process for contributors to become maintainers or reviewers. + +5: Including repositories, artifact repositories, build and test infrastructure, web sites and their domains, blogs, social-media accounts, etc. + +6: When determining organizational affiliation, operationally interconnected organizations should be considered a single entity for the purpose of this rule. + +--- + +[election policy]: /elections.md +[Eligible voters]: /elections.md#eligibility-for-voting +[Inclusive Open Source Community Orientation]: https://training.linuxfoundation.org/training/inclusive-open-source-community-orientation-lfc102/ +[afb3858]: https://github.com/kubernetes/steering/blob/afb3858/charter.md +[Steering Committee private mailing list]: !TODO! \ No newline at end of file diff --git a/docs/governance/steering/elections.md b/docs/governance/steering/elections.md new file mode 100644 index 00000000..59406fe1 --- /dev/null +++ b/docs/governance/steering/elections.md @@ -0,0 +1,125 @@ +# Common Cloud Controls (CCC) Steering Committee Elections + +This document outlines the process for steering committee elections. + +## Eligibility + +Restrictions on candidacy and voting are in place to ensure that the CCC project is led by individuals who are highly trusted, impactful, and currently active in the community. + +### Eligibility for voting + +In order to be eligible for voting, an individual must: + +- Be an FINOS Member[1](#footnote1) who had a substantial contribution to the CCC project within 12 months prior to their nomination. Contributions include GitHub events like creating issues, creating PRs, reviewing PRs, commenting on issues, etc. +- Be an appointed or elected member of one or more active [community groups] within 4 months prior to their nomination. +- Demonstrate expertise in any subfield of cybersecurity, or general working experience in cybersecurity for financial services, within 2 years prior to their nomination. + +_It is the responsibility of the steering committee to refine these criteria prior to each election, including setting the number of required contributions, and adding any additional committee memberships that include eligibility._ + +### Eligibility for candidacy + +In order to be eligible for candidacy, an individual must: + +* Be eligible for voting in the current Steering Committe election. +* Accept a nomination or self-nominate. +* Be endorsed by another party from their own employer. +* Be endorsed by at least one eligible voter from a financial institution who is + not the candidate's employer. + +In the event that multiple candidates from the same employer are nominated for a reserved seat, only the candidate with the most votes will be selected. + +Refer to the [elections procedure] for more information about how to nominate and endorse candidates in any CCC election. + +### Eligibility for Nomination and Endorsement + +Any FINOS member may nominate as many people as they wish to. We recommend that you validate the eligibility of your candidate prior to nomination. + +[Eligible voters](#eligibility-for-voting) may endorse nominees or campaign as they see fit. + +## Terms and Election Cycles + +Steering committee members are elected to serve a two (2) year term. Members can serve two (2) consecutive terms and a lifetime of four (4) terms. Terms that result in less than or equal to one (1) year served are exempt. + +Election cycles are scheduled such that roughly half of the seats come up for re-election each year for purposes of continuity. The exact number of seats alternates between three (3) and four (4). + +### Bootstrap Election + +In the [bootstrap] process (which does not follow the guidelines set forth here) four (4) seats will be allocated for 364-day terms, to stagger all future elections. The committee will be responsible for self-allocation of these seats. + +### Emeritus Term + +Members of the steering committee who complete a term will graduate to becoming Emeritus members of the steering committee upon vacating their seat. This confers honor on the recipient, acknowledging the significant contributions they have made to the project. Emeritus members have no binding vote, and no expectation of continued participation in steering committee affairs. + +## Election Schedule and Operation + +After the [bootstrap] election, the steering committee is responsible for the appointment of election officers to operate the election and circulate an exact election timeline to the community. The steering committee should provide the election officer with a desired timeline based on current community needs. + +For example: + +- End of July + - Election officers + - Voter eligibility criteria + - Election preparation +- September + - Nomination period and election +- October + - Conclusion of Election + - Results announced at first community meeting after the election concludes + +The election officers will choose exact dates for each step and propose the final schedule to the Steering Committee. + +### Nomination and Election Procedure + +Nominations will be made using the _Nomination_ GitHub Issue template. + +Elections will be held using an online preference election system which supports Condorcet elections. The most preferred candidates will be elected to the open seats. + +### Election Officer Eligibility + +The steering committee should choose multiple election officers using the following criteria, so as to promote healthy rotation and diversity: + +- Each individual must be eligible to vote. +- Each individual must have been a FINOS member for at least one year. +- At least one election officer should have served before. +- Each officer should come from a different employer. +- Each officer can be relied upon to follow the [election procedure]. + +History of election officers: + +|Year|Officers| +|---|---| +| 2024 | TBD | + +## Steering Committee and Election Officer Recusal + +Currently serving steering committee members and the appointed election officers +pledge to recuse themselves from any form of electioneering, including +campaigning, nominating, or endorsing. Violations of this pledge should lead to +a vote of no confidence in the offending party. + +Steering committee members _may_ ask other contributors to consider running, +and they _may_ vote, so long as this information is kept private. + +Steering committee members who intend to run for re-election _may_ +self-nominate but are otherwise expected to adhere to this recusal. + +## Attribution + +This document was adapted from the Kubernetes Steering Committee Elections document [afb3858]. + +## Footnotes + +1: A FINOS Member in this context is any individual who is employed by a FINOS member organization. FINOS Staff and non-members are excluded from participation by design, to encourage proper participation and representation from the diverse community of FINOS Members. + +--- + +[community groups]: ./community.md + +[Condorcet]: https://en.wikipedia.org/wiki/Condorcet_method + +[election procedure]: #election-procedure + +[bootstrap]: https://github.com/CCC/community/tree/master/docs/formation/bootstrap.md +[elections]: https://github.com/CCC/community/tree/master/docs/governance/elections.md + +[afb3858]: https://github.com/kubernetes/steering/blob/afb3858/elections.md diff --git a/docs/governance/working-groups/communications/charter.md b/docs/governance/working-groups/communications/charter.md new file mode 100644 index 00000000..f27bb738 --- /dev/null +++ b/docs/governance/working-groups/communications/charter.md @@ -0,0 +1,74 @@ +# Communications Working Group Charter + +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) Communications [WG] + +## Table of Contents + +1. [Mission](#mission) +2. [Approach & Responsibilities](#approach--responsibilities) + - [Output / Deliverables](#output--deliverables) +3. [Out of Scope](#out-of-scope) +4. [Meeting Cadence](#meeting-cadence) +5. [Governance](#governance) + - [Membership](#membership) + - [Changes](#changes) + - [Meeting Cadence](#meeting-cadence) + - [Changes](#changes) + +## Mission + +The mission of the [WG] is to develop communications frameworks to identify problems within the CCC community, organize resolution efforts, and communicate solutions and benefits. + +## Approach & Responsibilities + +This group will: + +- Maintain a public-facing explanation of the problem this project addresses, the solutions it provides, and the value created by those solutions +- Maintain and distribute a user-feedback mechanism for all project outputs +- Parse and publish user feedback for project consideration +- Maintain a project roadmap detailing upcoming user-impacting changes planned by each WG +- Communicate any roadmap changes to users and stakeholders +- Communicate all information regarding project releases provided by the Delivery WG +- When applicable, publicly communicate how user feedback has been integrated into a project release + +### Output / Deliverables + +The following items will be maintained in the project repository: + +- Public-facing Project Roadmap +- Marketing collateral such as graphics and website code +- Community engagement guides +- De-personalized end-user requirements and requests (through GitHub issues) + +## Out of Scope + +- Determining the priority or relevance of a feature request +- Spontaneous inquiries from the community, ranging from implementation specifics to interactions on social media platforms + +## Governance + +This [WG] will remain compliant with all applicable community policies. At the guidance of the WG Lead, this group will seek to implement recommendations set forth by the Community Structure WG. + +### Membership + +The membership structure of this working group: + +- **WG Lead:** Alex St. Pierre +- **SteerCo Sponsor:** Eddie Knight +- This group is not authorized to create independent sub-groups. + +## Meeting Cadence + +- This [WG] will use the mail group for routine communications. +- A formal bi-weekly meeting will be created on the FINOS community calendar as a space to gather end-user feedback, address community inquiries, and act as an entry point for new contributors. +- A group member should represent this [WG] on any calls scheduled by the [SC] for participation by the full CCC project community. + +### Changes + +Any functional changes to this charter must be approved through a majority vote by the [SC]. Minor changes such as formatting may be merged upon approval from any [SC] member. + +[WG]: <../../community-groups.md#working-groups> +[SC]: <../../community-groups.md#steering-committee> +[Community Structure WG]: <../community-structure/charter.md> +[policies]: <../../community-policies/README.md> +[guidelines]: <../../community-guidelines/README.md> diff --git a/docs/governance/working-groups/community-structure/charter.md b/docs/governance/working-groups/community-structure/charter.md new file mode 100644 index 00000000..82c54fcd --- /dev/null +++ b/docs/governance/working-groups/community-structure/charter.md @@ -0,0 +1,61 @@ +# Community Structure Working Group + +This [WG] facilitates the structure and governance design for the Common Cloud Controls project community. + +## Mission + +The mission of the Community Structure [WG] is to establish robust, scalable, and efficient frameworks for the governance and operation of all community [WG]s within the CCC. + +By designing clear guidelines and structures, this group ensures consistency and facilitates effective collaboration across the entire community. It acts as a central body to guide the formation and operation of other [WG]s, helping them align with the overarching goals of the CCC. + +## Approach + +- Work closely with community members and stakeholders to gather insights and requirements +- Maintain open and transparent communication channels for all WG activities and decisions +- Adapt processes and guidelines as necessary to meet the evolving needs of the community +- Ensure all decisions and guidelines are well-documented and accessible to the community +- Strive for representation from diverse community segments when forming recommendations + +## Responsibilities + +- Propose and maintain community policies and guidelines +- Provide advice and support to WGs +- Interface with FINOS team to implement repository controls + +### Output / Deliverables + +This group should, at minimum, create and maintain the following items in the project GitHub repository. + +- Community organization strategy, including: + - Group Naming conventions + - Limitations + - Formation Processes +- Community Group Charter Policy, including: + - Charter Format & Contents + - Proposal Policy +- Writing Conventions / Style Guide + +## Out of Scope + +This [WG] is not responsible for approving proposed policies or ensuring compliance with policies. + +To reduce unilateral authority from either this group or the [SC], all policy proposals should come from this group and be finalized through a vote from the [SC]. + +## Membership + +The membership structure of this [WG], including roles and responsibilities, must adhere to the latest recommendations from the Community Structure [WG]. + +Where recommendations do note yet exist on a topic, this [WG] should follow guidance from the CCC [SC]. + +## Community Cadence + +A member of this [WG] should be present on for any calls scheduled by the [SC] for participation by the full CCC community, such as quarterly [SC] calls. + +This [WG] will use the mail group for regular communications. + +## Changes + +Changes to this charter must be approved through a majority vote by the [SC]. + +[SC]: <../../community-groups.md#steering-committee> +[WG]: <../../community-groups.md#working-groups> diff --git a/docs/governance/working-groups/delivery/charter.md b/docs/governance/working-groups/delivery/charter.md new file mode 100644 index 00000000..57e76896 --- /dev/null +++ b/docs/governance/working-groups/delivery/charter.md @@ -0,0 +1,84 @@ +# Delivery Working Group Charter + +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) Delivery [WG]. + +## Table of Contents + +1. [Mission](#mission) +2. [Approach & Responsibilities](#approach--responsibilities) + - [Output / Deliverables](#output--deliverables) +3. [Out of Scope](#out-of-scope) +4. [Meeting Cadence](#meeting-cadence) +5. [Governance](#governance) + - [Membership](#membership) + - [Changes](#changes) + - [Meeting Cadence](#meeting-cadence) + - [Changes](#changes) + +## Mission + +This [WG] defines and maintains the delivery process for the Common Cloud Controls project deliverables. + +The mission of the Delivery [WG] is to establish and maintain robust communication channels, ensuring openness and clarity in all activities and decisions related to outputs and deliverables. We aim to curate a comprehensive repository of community outputs slated for release, diligently managing version control and devising optimal strategies for content dissemination. + +By coordinating with fellow [WG]'s, we endeavor to synchronize release efforts, while meticulously defining and adhering to a structured release schedule, fostering efficiency and coherence in our endeavors. + +## Approach & Responsibilities + +This group will: + +- Maintain open and transparent communication channels for all WG activities and decisions in regard to outputs/deliverables +- Define and document standards related to how content is organized in the repository +- Document standards for how all project artifacts reference eachother, such as control identifiers +- Create and maintain automation related to acceptance of content proposed to the project repository +- Maintain a list of all community outputs that need to be released +- Determine and document project best practices for versioning and releasing content +- Maintain a version controlled process for releasing content +- Collaborate with other [WG]s to coordinate releases +- Define and maintain a release strategy and schedule (whether it be biweekly, monthly, etc.) +- Coordinate with the [Communications WG] regarding upcoming releases + +### Output / Deliverables + +The following artifacts will be created and stored in the project GitHub repo: + +- Documentation of the project's comprehensive release strategy +- Documentation of the project's content format and hygiene standards +- Automation related to the acceptance and management of content proposed to the project repository +- Automation related to release of version-controlled project artifacts +- Release artifacts corresponding to any version-controlled outputs from the project + +## Out of Scope + +The following activities will not be performed by this group: + +- Technicial work that does not pertain to a release or repo content format +- Public-facing communications + +## Governance + +This [WG] will remain compliant with all applicable community [policies]. At the guidance of the WG Lead, this group will seek to implement [recommendations] set forth by the [Community Structure WG]. + +### Membership + +The membership structure of this working group: + +- WG Lead: Damien Burks +- SC Sponsor: Eddie Knight +- This group is not authorized to create independent sub-groups. + +### Meeting Cadence + +* This working group will use the mail group for regular communications. +* A group member should represent this [WG] on any calls scheduled by the [SC] for participation by the full CCC project community. + +### Changes + +Any functional changes to this charter must be approved through a majority vote by the [SC]. Minor changes such as formatting may be merged upon approval from any [SC] member. + +[WG]: <../../community-groups.md#working-groups> +[SC]: <../../community-groups.md#steering-committee> +[policies]: <../../community-policies/README.md> +[recommendations]: <../../community-recommendations/README.md> +[Communications WG]: <../communications/charter.md> +[Community Structure WG]: <../communications/charter.md> diff --git a/docs/governance/working-groups/duplication-reduction/charter.md b/docs/governance/working-groups/duplication-reduction/charter.md new file mode 100644 index 00000000..59486ba4 --- /dev/null +++ b/docs/governance/working-groups/duplication-reduction/charter.md @@ -0,0 +1,77 @@ +# Duplication Reduction Working Group Charter + +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) Duplication Reduction [WG]. + +## Table of Contents + +1. [Mission](#mission) +2. [Approach & Responsibilities](#approach--responsibilities) + - [Output / Deliverables](#output--deliverables) +3. [Out of Scope](#out-of-scope) +4. [Meeting Cadence](#meeting-cadence) +5. [Governance](#governance) + - [Membership](#membership) + - [Changes](#changes) + - [Meeting Cadence](#meeting-cadence) + - [Changes](#changes) + +## Mission + +This [WG] facilitates the research of existing frameworks for the Common Cloud Controls project community through evaluation of tools, assets, and partners that exist in the cloud controls space that can help reduce the effort required to meet the overall CCC goals for the CCC contributors and consumers. + +Efforts from this group will ensure that the CCC efforts do not duplicate pre-existing standards, and instead are net new contributions to the broader ecosystem aligned to the specific needs of the financial services industry. + +## Approach + +This group will: + +- Identify existing resources that we should investigate for use toward various CCC [WG] goals, including tools, approaches, or frameworks. +- Develop a set of principles and goals to consider for evaluating resources +- Evaluate each resource's ability to meet project goals +- Idenitfy how each resource can help achieve a goal, in a way that can serve as a starting point or reference for other [WG]s +- Document research that has been done on each resource +- Provide a clear set of what's missing from existing frameworks such as NIST, ISO, OSCAL, and MITRE, with how the work being done in CCC augments or improves these systems +- Collaborate with the [Community Structure WG] to create new [recommendations] or policies regarding the use of specific resources, with links to documented research and reasoning +- Provide advice and support related to duplicative efforts to all [WG]s + +### Output / Deliverables + +The following items will be maintained by this [WG] in the project repository: + +- Resource Overview Document +- Featured Resources Guides +- Resource Evaluation Guide + +## Out of Scope + +The following activities will not be performed by this group: + +- Integrating resources into project workflows or outputs +- Ensuring compliance with [recommendations] or [policies] + +## Governance + +This [WG] will remain compliant with all applicable community [policies]. At the guidance of the WG Lead, this group will seek to implement [recommendations] approved by the [Community Structure WG]. + +### Membership + +The membership structure of this working group: + +- WG Lead: Jared Lambert +- SC Sponsor: Eddie Knight +- This group is not authorized to create independent sub-groups + +### Meeting Cadence + +* This working group will use the mail group for regular communications. +* A group member should represent this [WG] on any calls scheduled by the [SC] for participation by the full CCC project community. + +### Changes + +Any functional changes to this charter must be approved through a majority vote by the [SC]. Minor changes such as formatting may be merged upon approval from any [SC] member. + +[WG]: <../../community-groups.md#working-groups> +[SC]: <../../community-groups.md#steering-committee> +[Community Structure WG]: <../community-structure/charter.md> +[policies]: <../../community-policies/README.md> +[recommendations]: <../../community-recommendations/README.md> diff --git a/docs/governance/working-groups/security/charter.md b/docs/governance/working-groups/security/charter.md new file mode 100644 index 00000000..df06406c --- /dev/null +++ b/docs/governance/working-groups/security/charter.md @@ -0,0 +1,85 @@ +# Security Working Group Charter + +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) Security [WG]. + +## Table of Contents + +1. [Mission](#mission) +2. [Approach & Responsibilities](#approach--responsibilities) + - [Output / Deliverables](#output--deliverables) +3. [Out of Scope](#out-of-scope) +4. [Meeting Cadence](#meeting-cadence) +5. [Governance](#governance) + - [Membership](#membership) + - [Changes](#changes) + - [Meeting Cadence](#meeting-cadence) + - [Changes](#changes) + +## Mission + +This [WG] defines how a threat-informed control catalog can be used to assess the security of the common cloud services defined by the CCC services taxonomy working group. + +The mission of the Security [WG] is to develop, maintain, and enhance a comprehensive threat-informed security control catalog specifically tailored to the CCC cloud services taxonomy. As part of the mission, the working group will explore how existing catalogs, knowledge bases and assessment frameworks can be leveraged to assess the security posture of CCC-relevant cloud services and ensure alignment with industry standards and best practices. + +## Approach & Responsibilities + +This group will: + +- Collaborate with the [Duplication Reduction WG] to evaluate existing security controls catalogs, threat knowledge bases, risk-based assessments, assessment formats, and testing procedures +- Define and maintain effective measures to mitigate identified threats relative to the CCC services taxonomy +- Collaborate with industry experts, security researchers, and cloud service providers to ensure the accuracy and relevance of the project approaches and outputs +- Regularly update and expand the catalogs, assessment methodologies, and exploration of existing control catalogs to reflect evolving threats, emerging technologies, and best practices in cloud security +- Collaborate with the [Delivery WG] to determine an appropriate release process and cadence +- Review and incorporate relevant feedback gathered by the [Communications WG] from the community and end users + +### Output / Deliverables + +The following artifacts will be created and stored in the project GitHub repo: + +- Catalog of security threats for each cloud service type +- Catalog of security controls for each cloud service type + +## Out of Scope + +The following activities will not be performed by this group: + +- Technicial work that does not pertain to the development of its deliverables. +- Public-facing communications outside of the project repository + +## Governance + +This [WG] will remain compliant with all applicable community [policies]. At the guidance of the WG Lead, this group will seek to implement [recommendations] set forth by the Community Structure WG. + +### Membership + +The membership structure of this working group: + +- WG Lead: Michael Anthony Lysaght +- SC Sponsor: Jonathan Meadows + +### Sub-Groups + +This group **is** authorized to create independent sub-groups. + +This may be done by modifying this document to include a link to the relevant sub-group charter. Such modifications require PR approval from the WG Lead and one [SC] member. + +The following [WG] have been chartered by and are accountable to this group: + +- None + +### Meeting & Communications + +- This working group will use the mail group for regular communications. +- This group will host an informal [WG] meeting no less than once every three (3) weeks, excluding November and December. +- The WG Lead or their delegate must present verbal or written updates to the [SC] at its regular public meetings. + +### Changes + +Any functional changes to this charter must be approved through a majority vote by the [SC]. Minor changes such as formatting may be merged upon approval from any [SC] member. + +[WG]: <../../community-groups.md#working-groups> +[SC]: <../../community-groups.md#steering-committee> +[policies]: <../../community-policies/README.md> +[Communications WG]: <../communications/charter.md> +[Delivery WG]: <../delivery/charter.md> +[recommendations]: <../../community-recommendations/README.md> \ No newline at end of file diff --git a/docs/governance/working-groups/taxonomy/charter.md b/docs/governance/working-groups/taxonomy/charter.md new file mode 100644 index 00000000..96cb5cf2 --- /dev/null +++ b/docs/governance/working-groups/taxonomy/charter.md @@ -0,0 +1,78 @@ +# Taxonomy Working Group Charter + +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) Taxonomy [WG]. + +## Table of Contents + +1. [Mission](#mission) +2. [Approach & Responsibilities](#approach--responsibilities) + - [Output / Deliverables](#output--deliverables) +3. [Out of Scope](#out-of-scope) +4. [Governance](#governance) + - [Membership](#membership) + - [Sub-Groups](#sub-groups) + - [Meeting & Communication](#meeting--communication) + - [Changes](#changes) + +## Mission + +The mission of the Taxonomy [WG] is to define and maintain a comprehensive taxonomy of service(s) offered by the cloud hyperscalers. This initiative aims to establish a standardized nomenclature and attributes for common service categories such as VMs, Storage, and Networking. By creating this uniform taxonomy, the WG will facilitate the application of a set of controls across various cloud provider implementations, addressing common risks and promoting broader applicability of the CCC project's resources. + +## Approach & Responsibilities + +- Identify common cloud service categories, prioritizing those most commonly used within financial service institutions +- Create and maintain an index of all common service categories each organized by common categorical delineations +- Create and maintain a list of descriptions for the minimum viable features of each service category +- Create and maintain an asset describing the ways to test the presence of each feature for a service +- Ensure all artifacts comply with requirements documented by the [Delivery WG] prior to release +- Collaborate with [Delivery WG] to publish each release on the agreed schedule +- Collaborate with the [Communications WG] to incorporate user feedback into the development cycle + +### Output / Deliverables + +The following artifacts will be created and stored in the project GitHub repo: + +- Index of common service categories +- List of feature descriptions for each service in the index +- Test descriptions for each feature on each service + +## Out of Scope + +The following activities will not be performed by this group: + +- Working on assets related to cybersecurity topics +- Public-facing communications +- Tracking cloud vendor support of service features + +## Governance + +This [WG] will remain compliant with all applicable community [policies]. At the guidance of the WG Lead, this group will seek to implement [recommendations] set forth by the [Community Structure WG]. + +### Membership + +The membership structure of this working group. + +- **WG Lead:** Sonali Mendis +- **SC Sponsor:** Robert Griffiths + +### Sub-Groups + +- This group is not authorized to create independent sub-groups. + +### Meeting & Communication + +- This working group will use the mail group for regular communications. +- This group will host an informal recurring WG meeting every two weeks, with possible interferences on global holidays. +- The WG Lead or their delegate must present verbal or written updates to the [SC] at its regular public meetings. + +### Changes + +Any functional changes to this charter must be approved through a majority vote by the [SC]. Minor changes such as formatting may be merged upon approval from any [SC] member. + +[WG]: <../../community-groups.md#working-groups> +[SC]: <../../community-groups.md#steering-committee> +[policies]: <../../community-policies/README.md> +[recommendations]: <../../community-recommendations/README.md> +[Communications WG]: <../communications/charter.md> +[Community Structure WG]: <../communications/charter.md> +[Delivery WG]: <../delivery/charter.md> \ No newline at end of file diff --git a/docs/training/Readme.md b/docs/training/Readme.md deleted file mode 100644 index b91b1f7a..00000000 --- a/docs/training/Readme.md +++ /dev/null @@ -1,6 +0,0 @@ -# Training Docs - -## Links - -- [OSCAL](https://github.com/finos/common-cloud-controls/tree/main/docs/oscal.md) - diff --git a/src/oscal/Readme.md b/docs/training/oscal/examples/Readme.md similarity index 100% rename from src/oscal/Readme.md rename to docs/training/oscal/examples/Readme.md diff --git a/build/Makefile b/docs/training/oscal/examples/build/Makefile similarity index 100% rename from build/Makefile rename to docs/training/oscal/examples/build/Makefile diff --git a/src/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option1.json b/docs/training/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option1.json similarity index 100% rename from src/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option1.json rename to docs/training/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option1.json diff --git a/src/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option2.json b/docs/training/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option2.json similarity index 100% rename from src/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option2.json rename to docs/training/oscal/examples/catalog/json/OSCAL_CCC_Catalog_option2.json diff --git a/src/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option1.xml b/docs/training/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option1.xml similarity index 100% rename from src/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option1.xml rename to docs/training/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option1.xml diff --git a/src/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option2.xml b/docs/training/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option2.xml similarity index 100% rename from src/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option2.xml rename to docs/training/oscal/examples/catalog/xml/OSCAL_CCC_Catalog_option2.xml diff --git a/src/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option1.yaml b/docs/training/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option1.yaml similarity index 100% rename from src/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option1.yaml rename to docs/training/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option1.yaml diff --git a/src/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option2.yaml b/docs/training/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option2.yaml similarity index 100% rename from src/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option2.yaml rename to docs/training/oscal/examples/catalog/yaml/OSCAL_CCC_Catalog_option2.yaml diff --git a/docs/training/oscal.md b/docs/training/oscal/oscal.md similarity index 100% rename from docs/training/oscal.md rename to docs/training/oscal/oscal.md diff --git a/participants.md b/participants.md index dcab5d89..df33f242 100644 --- a/participants.md +++ b/participants.md @@ -21,7 +21,14 @@ Below is the list of [participants](governance-documents/5._Governance.md#1roles - Vicente Herrera Garcia, Control Plane, Date of enrolment: NOV/09/2023 - Rowan Baker, ControlPlane, Nov/10/2023 - Henry Mortimer, ControlPlane, JAN/26/2024 - +- Joshua Isted, Scott Logic, MAR/06/2024 +- Zeal Somani, JupiterOne, Mar/7/2024 +- Michael Lysaght, Citi, Mar/07/2024 +- Damien Burks, Citi, MAR/07/2024 +- Jared Lambert, Microsoft, APR/01/2024 +- Eric Peeters, Weaver, JUN/12/2024 +- Ivan Mladjenovic, Scott Logic, JUN/28/2024 +- Dave Ogle, Scott Logic, JUN/28/2024 ## How to enroll as a participant In order to enroll as a participant in the Common Cloud Controls project, please submit a Pull Request to this [participants](#participants) file listing your name, organization, and date of enrollment, by following the steps described below. diff --git a/src/control-catalog/behave_tests/storage/object/ccc.os.c2/steps/ccc_os_c2.py b/src/control-catalog/behave_tests/storage/object/ccc.os.c2/steps/ccc_os_c2.py index 7fa8bd04..9504840b 100644 --- a/src/control-catalog/behave_tests/storage/object/ccc.os.c2/steps/ccc_os_c2.py +++ b/src/control-catalog/behave_tests/storage/object/ccc.os.c2/steps/ccc_os_c2.py @@ -74,12 +74,13 @@ def gcp_upload_obj_with_untrusted_key(context): if kms_key_id is not None: break - bucket = storage.Bucket(context.storage_client, STORAGE_BUCKET_NAME) - bucket.blob(BUCKET_OBJ_NAME, kms_key_name=kms_key_id).upload_from_string( - "Hello, World" - ) - time.sleep(10) # Sleep for 10 seconds - + try: + bucket = storage.Bucket(context.storage_client, STORAGE_BUCKET_NAME) + bucket.blob(BUCKET_OBJ_NAME, kms_key_name=kms_key_id).upload_from_string( + "Hello, World" + ) + except Exception as err: + context.gcp_publish_error = str(err) @then("the AWS request should be denied") def validate_request_denied(context):