diff --git a/.config/.markdownlint.yaml b/.config/.markdownlint.yaml new file mode 100644 index 00000000..41542ad8 --- /dev/null +++ b/.config/.markdownlint.yaml @@ -0,0 +1,249 @@ +# Default state for all rules +default: true + +# Path to configuration file to extend +extends: null + +# MD001/heading-increment : Heading levels should only increment by one level at a time : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md001.md +MD001: true + +# MD003/heading-style : Heading style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md003.md +MD003: + # Heading style + style: "consistent" + +# MD004/ul-style : Unordered list style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md004.md +MD004: + # List style + style: "consistent" + +# MD005/list-indent : Inconsistent indentation for list items at the same level : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md005.md +MD005: true + +# MD007/ul-indent : Unordered list indentation : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md007.md +MD007: + # Spaces for indent + indent: 2 + # Whether to indent the first level of the list + start_indented: false + # Spaces for first level indent (when start_indented is set) + start_indent: 2 + +# MD009/no-trailing-spaces : Trailing spaces : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md009.md +MD009: + # Spaces for line break + br_spaces: 2 + # Allow spaces for empty lines in list items + list_item_empty_lines: false + # Include unnecessary breaks + strict: false + +# MD010/no-hard-tabs : Hard tabs : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md010.md +MD010: + # Include code blocks + code_blocks: true + # Fenced code languages to ignore + ignore_code_languages: [] + # Number of spaces for each hard tab + spaces_per_tab: 1 + +# MD011/no-reversed-links : Reversed link syntax : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md011.md +MD011: true + +# MD012/no-multiple-blanks : Multiple consecutive blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md012.md +MD012: + # Consecutive blank lines + maximum: 1 + +# MD013/line-length : Line length : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md013.md +MD013: false + +# MD014/commands-show-output : Dollar signs used before commands without showing output : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md014.md +MD014: true + +# MD018/no-missing-space-atx : No space after hash on atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md018.md +MD018: true + +# MD019/no-multiple-space-atx : Multiple spaces after hash on atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md019.md +MD019: true + +# MD020/no-missing-space-closed-atx : No space inside hashes on closed atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md020.md +MD020: true + +# MD021/no-multiple-space-closed-atx : Multiple spaces inside hashes on closed atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md021.md +MD021: true + +# MD022/blanks-around-headings : Headings should be surrounded by blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md +MD022: + # Blank lines above heading + lines_above: 1 + # Blank lines below heading + lines_below: 1 + +# MD023/heading-start-left : Headings must start at the beginning of the line : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md023.md +MD023: true + +# MD024/no-duplicate-heading : Multiple headings with the same content : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md024.md +MD024: + siblings_only: true + +# MD025/single-title/single-h1 : Multiple top-level headings in the same document : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md025.md +MD025: + # Heading level + level: 1 + # RegExp for matching title in front matter + front_matter_title: "^\\s*title\\s*[:=]" + +# MD026/no-trailing-punctuation : Trailing punctuation in heading : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md026.md +MD026: + # Punctuation characters + punctuation: ".,;:!。，；：！" + +# MD027/no-multiple-space-blockquote : Multiple spaces after blockquote symbol : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md027.md +MD027: true + +# MD028/no-blanks-blockquote : Blank line inside blockquote : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md028.md +MD028: true + +# MD029/ol-prefix : Ordered list item prefix : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md029.md +MD029: + # List style + style: "one_or_ordered" + +# MD030/list-marker-space : Spaces after list markers : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md030.md +MD030: + # Spaces for single-line unordered list items + ul_single: 1 + # Spaces for single-line ordered list items + ol_single: 1 + # Spaces for multi-line unordered list items + ul_multi: 1 + # Spaces for multi-line ordered list items + ol_multi: 1 + +# MD031/blanks-around-fences : Fenced code blocks should be surrounded by blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md031.md +MD031: + # Include list items + list_items: true + +# MD032/blanks-around-lists : Lists should be surrounded by blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md032.md +MD032: true + +# MD033/no-inline-html : Inline HTML : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md033.md +MD033: + # Allowed elements + allowed_elements: ["a", "img", "sup"] + +# MD034/no-bare-urls : Bare URL used : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md034.md +MD034: false + +# MD035/hr-style : Horizontal rule style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md035.md +MD035: + # Horizontal rule style + style: "consistent" + +# MD036/no-emphasis-as-heading : Emphasis used instead of a heading : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md036.md +MD036: + # Punctuation characters + punctuation: ".,;:!?。，；：！？" + +# MD037/no-space-in-emphasis : Spaces inside emphasis markers : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md037.md +MD037: true + +# MD038/no-space-in-code : Spaces inside code span elements : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md038.md +MD038: true + +# MD039/no-space-in-links : Spaces inside link text : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md039.md +MD039: true + +# MD040/fenced-code-language : Fenced code blocks should have a language specified : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md040.md +MD040: + # List of languages + allowed_languages: [] + # Require language only + language_only: false + +# MD041/first-line-heading/first-line-h1 : First line in a file should be a top-level heading : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md041.md +MD041: + # Heading level + level: 1 + # RegExp for matching title in front matter + front_matter_title: "^\\s*title\\s*[:=]" + +# MD042/no-empty-links : No empty links : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md042.md +MD042: true + +# MD043/required-headings : Required heading structure : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md043.md +MD043: false + +# MD044/proper-names : Proper names should have the correct capitalization : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md044.md +MD044: + # List of proper names + names: [] + # Include code blocks + code_blocks: true + # Include HTML elements + html_elements: true + +# MD045/no-alt-text : Images should have alternate text (alt text) : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md045.md +MD045: true + +# MD046/code-block-style : Code block style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md046.md +MD046: + # Block style + style: "consistent" + +# MD047/single-trailing-newline : Files should end with a single newline character : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md047.md +MD047: true + +# MD048/code-fence-style : Code fence style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md048.md +MD048: + # Code fence style + style: "consistent" + +# MD049/emphasis-style : Emphasis style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md049.md +MD049: + # Emphasis style + style: "consistent" + +# MD050/strong-style : Strong style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md050.md +MD050: + # Strong style + style: "consistent" + +# MD051/link-fragments : Link fragments should be valid : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md051.md +MD051: true + +# MD052/reference-links-images : Reference links and images should use a label that is defined : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md052.md +MD052: + # Include shortcut syntax + shortcut_syntax: false + +# MD053/link-image-reference-definitions : Link and image reference definitions should be needed : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md053.md +MD053: + # Ignored definitions + ignored_definitions: + - "//" + +# MD054/link-image-style : Link and image style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md054.md +MD054: + # Allow autolinks + autolink: true + # Allow inline links and images + inline: true + # Allow full reference links and images + full: true + # Allow collapsed reference links and images + collapsed: true + # Allow shortcut reference links and images + shortcut: true + # Allow URLs as inline links + url_inline: true + +# MD055/table-pipe-style : Table pipe style : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md055.md +MD055: + # Table pipe style + style: "consistent" + +# MD056/table-column-count : Table column count : https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md056.md +MD056: true \ No newline at end of file diff --git a/.config/.prettierrc b/.config/.prettierrc new file mode 100644 index 00000000..63d46591 --- /dev/null +++ b/.config/.prettierrc @@ -0,0 +1,12 @@ +{ + "printWidth": 10000, + "overrides": [ + { + "files": "*.md", + "options": { + "parser": "markdown" + } + } + ] + } + \ No newline at end of file diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 541dd010..6c9447cf 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -6,8 +6,7 @@ # # 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 +/* @finos/ccc-wg-community-structure # ######## @@ -15,27 +14,27 @@ # # 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 +/.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 +/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 +/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 # ######## @@ -43,7 +42,7 @@ 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 +/services @finos/ccc-wg-taxonomy # ######## @@ -55,12 +54,19 @@ services @finos/ccc-wg-taxonomy # ######## +######## +# +# Resource selection guidance and justifications must be reviewed by the Duplication Reduction WG +/docs/resources/ @finos/ccc-wg-duplication-reduction +# +######## + ######## # # 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 +/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/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md index 686ed9e0..703dbf4e 100644 --- a/.github/CODE_OF_CONDUCT.md +++ b/.github/CODE_OF_CONDUCT.md @@ -1,5 +1,5 @@ -# FINOS Code of Conduct - -Contributors to FINOS standards projects should follow the FINOS Code of Conduct, which can be found at [https://community.finos.org/docs/governance/code-of-conduct](https://community.finos.org/docs/governance/code-of-conduct). - -For issues or inquires, please contact [legal@linuxfoundation.org](mailto:legal@linuxfoundation.org). +# FINOS Code of Conduct + +Contributors to FINOS standards projects should follow the FINOS Code of Conduct, which can be found at [https://community.finos.org/docs/governance/code-of-conduct](https://community.finos.org/docs/governance/code-of-conduct). + +For issues or inquires, please contact [legal@linuxfoundation.org](mailto:legal@linuxfoundation.org). diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 4e533d77..bb477748 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -1,85 +1,85 @@ -# Community Specification Contribution Policy 1.0 - -This document provides the contribution policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Additional or alternate contribution policies may be adopted and documented by the Working Group. - -## 1. Contribution Guidelines. - -This Working Group accepts contributions via pull requests. The following section outlines the process for merging contributions to the specification - -**1.1. Issues.** Issues are used as the primary method for tracking anything to do with this specification Working Group. - -**1.1.1. Issue Types.** There are three types of issues (each with their own corresponding label): - -**1.1.1.1. Discussion.** These are support or functionality inquiries that we want to have a record of for future reference. Depending on the discussion, these can turn into "Spec Change" issues. - -**1.1.1.2. Proposal.** Used for items that propose a new ideas or functionality that require a larger discussion. This allows for feedback from others before a specification change is actually written. All issues that are proposals should both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a "Spec Change" and does not require a milestone. - -**1.1.1.3. Spec Change:** These track specific spec changes and ideas until they are complete. They can evolve from "Proposal" and "Discussion" items, or can be submitted individually depending on the size. Each spec change should be placed into a milestone. - -## 2. Issue Lifecycle. - -The issue lifecycle is mainly driven by the Maintainer. All issue types follow the same general lifecycle. Differences are noted below. - -**2.1. Issue Creation.** - -**2.2. Triage.** - -o The Editor in charge of triaging will apply the proper labels for the issue. This includes labels for priority, type, and metadata. - -o (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that proposals are prefaced with "Proposal". - -**2.3. Discussion.** - -o "Spec Change" issues should be connected to the pull request that resolves it. - -o Whoever is working on a "Spec Change" issue should either assign the issue to themselves or make a comment in the issue saying that they are taking it. - -o "Proposal" and "Discussion" issues should stay open until resolved. - -**2.4. Issue Closure.** - -## 3. How to Contribute a Patch. - -The Working Group uses pull requests to track changes. To submit a change to the specification: - -**3.1 Fork the Repo, modify the Specification to Address the Issue.** - -**3.2. Submit a Pull Request.** - -## 4. Pull Request Workflow. - -The next section contains more information on the workflow followed for Pull Requests. - -**4.1. Pull Request Creation.** - -o We welcome pull requests that are currently in progress. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a pull request is a work in progress, it should be prefaced with "WIP: [title]". You should also add the wip label Once the pull request is ready for review, remove "WIP" from the title and label. - -o It is preferred, but not required, to have a pull request tied to a specific issue. There can be circumstances where if it is a quick fix then an issue might be overkill. The details provided in the pull request description would suffice in this case. - -**4.2. Triage** - -o The Editor in charge of triaging will apply the proper labels for the issue. This should include at least a size label, a milestone, and awaiting review once all labels are applied. - -**4.3. Reviewing/Discussion.** - -o All reviews will be completed using the review tool. - -o A "Comment" review should be used when there are questions about the spec that should be answered, but that don't involve spec changes. This type of review does not count as approval. - -o A "Changes Requested" review indicates that changes to the spec need to be made before they will be merged. - -o Reviewers should update labels as needed (such as needs rebase). - -o When a review is approved, the reviewer should add LGTM as a comment. - -o Final approval is required by a designated Editor. Merging is blocked without this final approval. Editors will factor reviews from all other reviewers into their approval process. - -**4.4. Responsive.** Pull request owner should try to be responsive to comments by answering questions or changing text. Once all comments have been addressed, the pull request is ready to be merged. - -**4.5. Merge or Close.** - -o A pull request should stay open until a Maintainer has marked the pull request as approved. - -o Pull requests can be closed by the author without merging. - -o Pull requests may be closed by a Maintainer if the decision is made that it is not going to be merged. +# Community Specification Contribution Policy 1.0 + +This document provides the contribution policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Additional or alternate contribution policies may be adopted and documented by the Working Group. + +## 1. Contribution Guidelines. + +This Working Group accepts contributions via pull requests. The following section outlines the process for merging contributions to the specification + +**1.1. Issues.** Issues are used as the primary method for tracking anything to do with this specification Working Group. + +**1.1.1. Issue Types.** There are three types of issues (each with their own corresponding label): + +**1.1.1.1. Discussion.** These are support or functionality inquiries that we want to have a record of for future reference. Depending on the discussion, these can turn into "Spec Change" issues. + +**1.1.1.2. Proposal.** Used for items that propose a new ideas or functionality that require a larger discussion. This allows for feedback from others before a specification change is actually written. All issues that are proposals should both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a "Spec Change" and does not require a milestone. + +**1.1.1.3. Spec Change:** These track specific spec changes and ideas until they are complete. They can evolve from "Proposal" and "Discussion" items, or can be submitted individually depending on the size. Each spec change should be placed into a milestone. + +## 2. Issue Lifecycle. + +The issue lifecycle is mainly driven by the Maintainer. All issue types follow the same general lifecycle. Differences are noted below. + +**2.1. Issue Creation.** + +**2.2. Triage.** + +o The Editor in charge of triaging will apply the proper labels for the issue. This includes labels for priority, type, and metadata. + +o (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that proposals are prefaced with "Proposal". + +**2.3. Discussion.** + +o "Spec Change" issues should be connected to the pull request that resolves it. + +o Whoever is working on a "Spec Change" issue should either assign the issue to themselves or make a comment in the issue saying that they are taking it. + +o "Proposal" and "Discussion" issues should stay open until resolved. + +**2.4. Issue Closure.** + +## 3. How to Contribute a Patch. + +The Working Group uses pull requests to track changes. To submit a change to the specification: + +**3.1 Fork the Repo, modify the Specification to Address the Issue.** + +**3.2. Submit a Pull Request.** + +## 4. Pull Request Workflow. + +The next section contains more information on the workflow followed for Pull Requests. + +**4.1. Pull Request Creation.** + +o We welcome pull requests that are currently in progress. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a pull request is a work in progress, it should be prefaced with "WIP: [title]". You should also add the wip label Once the pull request is ready for review, remove "WIP" from the title and label. + +o It is preferred, but not required, to have a pull request tied to a specific issue. There can be circumstances where if it is a quick fix then an issue might be overkill. The details provided in the pull request description would suffice in this case. + +**4.2. Triage** + +o The Editor in charge of triaging will apply the proper labels for the issue. This should include at least a size label, a milestone, and awaiting review once all labels are applied. + +**4.3. Reviewing/Discussion.** + +o All reviews will be completed using the review tool. + +o A "Comment" review should be used when there are questions about the spec that should be answered, but that don't involve spec changes. This type of review does not count as approval. + +o A "Changes Requested" review indicates that changes to the spec need to be made before they will be merged. + +o Reviewers should update labels as needed (such as needs rebase). + +o When a review is approved, the reviewer should add LGTM as a comment. + +o Final approval is required by a designated Editor. Merging is blocked without this final approval. Editors will factor reviews from all other reviewers into their approval process. + +**4.4. Responsive.** Pull request owner should try to be responsive to comments by answering questions or changing text. Once all comments have been addressed, the pull request is ready to be merged. + +**4.5. Merge or Close.** + +o A pull request should stay open until a Maintainer has marked the pull request as approved. + +o Pull requests can be closed by the author without merging. + +o Pull requests may be closed by a Maintainer if the decision is made that it is not going to be merged. diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 00000000..780ae3a4 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,31 @@ +--- +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/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index 4d166298..17b73655 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -1,20 +1,21 @@ --- name: "\U0001F680 Feature Request" about: "I have a suggestion (and may want to implement it \U0001F642)!" -title: '' -labels: '' -assignees: '' - +title: "" +labels: "" +assignees: "" --- ## Feature Request ### Description of Problem: -...what *problem* are you trying to solve that the project doesn't currently solve? -...please resist the temptation to describe your request in terms of a solution. Job Story form ("When [triggering condition], I want to [motivation/goal], so I can [outcome].") can help ensure you're expressing a problem statement. +...what _problem_ are you trying to solve that the project doesn't currently solve? + +...please resist the temptation to describe your request in terms of a solution. Job Story form ("When [triggering condition], I want to [motivation/goal], so I can [outcome].") can help ensure you're expressing a problem statement. ### Potential Solutions: + ...clearly and concisely describe what you want to happen. Add any considered drawbacks. ... if you've considered alternatives, clearly and concisely describe those too. diff --git a/.github/ISSUE_TEMPLATE/minutes_all-hands-comms.md b/.github/ISSUE_TEMPLATE/minutes_all-hands-comms.md index a56092f8..688b09a1 100644 --- a/.github/ISSUE_TEMPLATE/minutes_all-hands-comms.md +++ b/.github/ISSUE_TEMPLATE/minutes_all-hands-comms.md @@ -1,19 +1,18 @@ --- - 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: +labels: - meeting - communications -assignees: 'alexstpierrework' +assignees: "alexstpierrework" projects: - finos/18 --- ## Date -MM/DD/YYYY - (X)am ET / (Y)pm UK +MM/DD/YYYY - 12:00 ET / 17:00 UK - [Join Zoom Meeting](https://zoom.us/j/94416168360) - Meeting ID: 944 1616 8360 @@ -29,8 +28,9 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - 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) +- [ ] 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 @@ -38,5 +38,6 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - [ ] AOB, Q&A & Adjourn (5mins) ## Untracked attendees + - Fullname, Affiliation, (optional) GitHub username - ... diff --git a/.github/ISSUE_TEMPLATE/minutes_community-structure.md b/.github/ISSUE_TEMPLATE/minutes_community-structure.md index 8e5c8554..fb1ef9ed 100644 --- a/.github/ISSUE_TEMPLATE/minutes_community-structure.md +++ b/.github/ISSUE_TEMPLATE/minutes_community-structure.md @@ -1,18 +1,16 @@ --- - name: Community Structure WG Meeting Minutes about: To track Common Cloud Controls meeting agenda and attendance -title: MM/DD/YYYY All Hands Meeting Minutes -labels: +title: MM/DD/YYYY Community Structure Minutes +labels: - meeting - community structure -assignees: 'sshiells-scottlogic' - +assignees: "sshiells-scottlogic" --- ## Date -MM/DD/YYYY - (X)am ET / (Y)pm UK +MM/DD/YYYY - 12:00 ET / 17:00 UK - [Join Zoom Meeting](https://zoom.us/j/99708793584) - Meeting ID: 997 0879 3584 @@ -28,8 +26,9 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - 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) +- [ ] 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/12) walkthrough @@ -37,5 +36,6 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - [ ] AOB, Q&A & Adjourn (5mins) ## Untracked attendees + - Fullname, Affiliation, (optional) GitHub username - ... diff --git a/.github/ISSUE_TEMPLATE/minutes_delivery.md b/.github/ISSUE_TEMPLATE/minutes_delivery.md index 5dd7deae..89d1c1e8 100644 --- a/.github/ISSUE_TEMPLATE/minutes_delivery.md +++ b/.github/ISSUE_TEMPLATE/minutes_delivery.md @@ -1,18 +1,16 @@ --- - name: Delivery WG Meeting Minutes about: To track Common Cloud Controls meeting agenda and attendance -title: MM/DD/YYYY All Hands Meeting Minutes -labels: +title: MM/DD/YYYY Delivery Meeting Minutes +labels: - meeting - delivery -assignees: 'damienjburks' - +assignees: "damienjburks" --- ## Date -MM/DD/YYYY - (X)am ET / (Y)pm UK +MM/DD/YYYY - 11:30 ET / 16:30 UK - [Join Zoom Meeting](https://zoom.us/j/93010138669) - Meeting ID: 930 1013 8669 @@ -28,8 +26,9 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - 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) +- [ ] 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 @@ -37,5 +36,6 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - [ ] 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 index bb0e470e..1e1e2546 100644 --- a/.github/ISSUE_TEMPLATE/minutes_duplication-reduction.md +++ b/.github/ISSUE_TEMPLATE/minutes_duplication-reduction.md @@ -1,18 +1,16 @@ --- - 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: +title: MM/DD/YYYY Duplication Reduction Meeting Minutes +labels: - meeting - duplication reduction -assignees: 'jared-lambert' - +assignees: "jared-lambert" --- ## Date -MM/DD/YYYY - (X)am ET / (Y)pm UK +MM/DD/YYYY - 12:30 ET / 17:30 UK - [Join Zoom Meeting](https://zoom.us/j/94109603410) - Meeting ID: 941 0960 3410 @@ -28,8 +26,9 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - 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) +- [ ] 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 @@ -37,5 +36,6 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - [ ] 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 index aee6ab97..68b94922 100644 --- a/.github/ISSUE_TEMPLATE/minutes_security.md +++ b/.github/ISSUE_TEMPLATE/minutes_security.md @@ -1,18 +1,16 @@ --- - name: Security WG Meeting Minutes about: To track Common Cloud Controls meeting agenda and attendance -title: MM/DD/YYYY All Hands Meeting Minutes -labels: +title: MM/DD/YYYY Security Meeting Minutes +labels: - meeting - security -assignees: 'mlysaght2017' - +assignees: "mlysaght2017" --- ## Date -MM/DD/YYYY - (X)am ET / (Y)pm UK +MM/DD/YYYY - 11:00 ET / 16:00 UK - [Join Zoom Meeting](https://zoom.us/j/99521272221) - Meeting ID: 995 2127 2221 @@ -28,8 +26,9 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - 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) +- [ ] 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 @@ -37,5 +36,6 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - [ ] 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 index f3b69fb2..6256f667 100644 --- a/.github/ISSUE_TEMPLATE/minutes_taxonomy.md +++ b/.github/ISSUE_TEMPLATE/minutes_taxonomy.md @@ -1,18 +1,16 @@ --- - name: Taxonomy WG Meeting Minutes about: To track Common Cloud Controls meeting agenda and attendance -title: MM/DD/YYYY All Hands Meeting Minutes -labels: +title: MM/DD/YYYY Taxonomy Meeting Minutes +labels: - meeting - taxonomy -assignees: 'smendis-scottlogic' - +assignees: "smendis-scottlogic" --- ## Date -MM/DD/YYYY - (X)am ET / (Y)pm UK +MM/DD/YYYY - 11:30 ET / 16:30 UK - [Join Zoom Meeting](https://zoom.us/j/994109603410) - Meeting ID: 941 0960 3410 @@ -28,8 +26,9 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - 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) +- [ ] 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 @@ -37,5 +36,6 @@ MM/DD/YYYY - (X)am ET / (Y)pm UK - [ ] AOB, Q&A & Adjourn (5mins) ## Untracked attendees + - Fullname, Affiliation, (optional) GitHub username - ... diff --git a/.github/ISSUE_TEMPLATE/support_question.md b/.github/ISSUE_TEMPLATE/support_question.md index 2acc2998..e6bc6789 100644 --- a/.github/ISSUE_TEMPLATE/support_question.md +++ b/.github/ISSUE_TEMPLATE/support_question.md @@ -1,10 +1,9 @@ --- name: "\U0001F917 Support Question" about: "If you have a question about configuration, usage, etc. \U0001F4AC" -title: '' -labels: '' -assignees: '' - +title: "" +labels: "" +assignees: "" --- ## Support Question diff --git a/.github/workflows/format-check.yml b/.github/workflows/format-check.yml new file mode 100644 index 00000000..52e5be72 --- /dev/null +++ b/.github/workflows/format-check.yml @@ -0,0 +1,23 @@ +name: "Format Check" + +on: + workflow_call: + +jobs: + prettier-fmt-check: + runs-on: ubuntu-latest + + steps: + - name: Checkout repository + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: '16' + + - name: Install Prettier + run: npm install --save-dev prettier + + - name: Check formatting with Prettier + run: npx prettier --check "**/*.md" --config ./.config/.prettierrc \ No newline at end of file diff --git a/.github/workflows/links.yml b/.github/workflows/links.yml new file mode 100644 index 00000000..24e60b21 --- /dev/null +++ b/.github/workflows/links.yml @@ -0,0 +1,20 @@ +name: Links + +on: + workflow_call: + +jobs: + link-checker: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Link Checker + id: lychee + uses: lycheeverse/lychee-action@v1 + with: + args: --base . --verbose --no-progress './**/*.md' + output: lychee/results.md + token: ${{ secrets.GITHUB_TOKEN }} + # Don't fail action on broken links + fail: false diff --git a/.github/workflows/linting-check.yml b/.github/workflows/linting-check.yml new file mode 100644 index 00000000..7d5c47f5 --- /dev/null +++ b/.github/workflows/linting-check.yml @@ -0,0 +1,23 @@ +name: Lint Check + +on: + workflow_call: + +jobs: + markdown-lint: + runs-on: ubuntu-latest + + steps: + - name: Checkout repository + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: "16" + + - name: Install markdownlint-cli + run: npm install -g markdownlint-cli + + - name: Run markdownlint + run: markdownlint '**/*.md' --config ./.config/.markdownlint.yaml \ No newline at end of file diff --git a/.github/workflows/pr_workflow.yaml b/.github/workflows/pr_workflow.yaml new file mode 100644 index 00000000..6f6ea937 --- /dev/null +++ b/.github/workflows/pr_workflow.yaml @@ -0,0 +1,23 @@ +name: "PR Workflow" + +on: + pull_request: + workflow_dispatch: + +jobs: + run-format-check: + uses: ./.github/workflows/format-check.yml + permissions: + pull-requests: write + contents: read + + run-linting-check: + uses: ./.github/workflows/linting-check.yml + permissions: + pull-requests: write + + link-checker: + uses: ./.github/workflows/links.yml + permissions: + pull-requests: write + contents: read diff --git a/.github/workflows/stale_meeting.yml b/.github/workflows/stale_meeting.yml new file mode 100644 index 00000000..0d593d70 --- /dev/null +++ b/.github/workflows/stale_meeting.yml @@ -0,0 +1,24 @@ +name: Auto Close Stale Meeting Issues + +on: + schedule: + - cron: '18 22 * * *' + +jobs: + close-stale-meeting: + runs-on: ubuntu-latest + permissions: + issues: write + pull-requests: write + steps: + - uses: actions/stale@v5 + with: + days-before-issue-stale: 13 + days-before-issue-close: 1 # Marked as stale the day before closing + stale-issue-label: "stale_meeting" + stale-issue-message: "This issue is stale because it has been open for 13 days with no activity." + close-issue-message: "This issue was closed because it has been inactive for 14 days." + days-before-pr-stale: -1 + days-before-pr-close: -1 + only-labels: "meeting" + repo-token: ${{ secrets.GITHUB_TOKEN }} diff --git a/.gitignore b/.gitignore index 25b40beb..9e086742 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,5 @@ # Name of default directory for oscal-cli build/oscal-cli # VS Code -.DS_Store \ No newline at end of file +.DS_Store +.vscode \ No newline at end of file diff --git a/Governance.md b/Governance.md index 3704cc98..1bedb666 100644 --- a/Governance.md +++ b/Governance.md @@ -1,49 +1,49 @@ -# Community Specification Governance Policy 1.0 - -This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group and must adhere to the requirements in this document. - -## 1. Roles. - -Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group. - -**1.1. Maintainer.** “Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the Working Group. Maintainers are also responsible for determining consensus and coordinating appeals. Each Working Group will designate one or more Maintainer for that Working Group. A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants. - -**1.2. Participants.** “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License. - -## 2. Decision Making. - -**2.1. Consensus-Based Decision Making.** Working Groups make decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Maintainer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections. The Maintainer will document evidence of consensus in accordance with these requirements. - -**2.2. Appeal Process.** Decisions may be appealed be via a pull request or an issue, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time. - -## 3. Ways of Working. - -Inspired by [ANSI’s Essential Requirements for Due Process](https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf), Community Specification Working Groups must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community Specifications. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus. - -**3.1. Openness.** Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required. - -**3.2. Lack of Dominance.** The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints. - -**3.3. Balance.** The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance. - -**3.4. Coordination and Harmonization.** Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards. - -**3.5. Consideration of Views and Objections.** Prompt consideration shall be given to the written views and objections of all Participants. - -**3.6. Written procedures.** This governance document and other materials documenting the Community Specification development process shall be available to any interested person. - -## 4. Specification Development Process. - -**4.1. Pre-Draft.** Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group. The Maintainer will designate each submission as a “Pre-Draft” document. - -**4.2. Draft.** Each Pre-Draft document of a Working Group must first be Approved to become a” Draft Specification”. Once the Working Group approves a document as a Draft Specification, the Draft Specification becomes the basis for all going forward work on that specification. - -**4.3. Working Group Approval.** Once a Working Group believes it has achieved the objectives for its specification as described in the Scope, it will Approve that Draft Specification and progress it to “Approved Specification” status, such status to be effective forty-five days following such Approval. The Maintainer will update the NOTICES.MD file to indicate both the Approval of the Draft Specification and the date upon which its “Approved Specification” status will be effective which shall in no case be earlier than forty-five days following the date the Notices.md file was updated. - -**4.4. Publication and Submission.** Upon the designation of a Draft Specification as an Approved Specification, the Maintainer will publish the Approved Specification in a manner agreed upon by the Working Group Participants (i.e., Working Group Participant only location, publicly available location, Working Group maintained website, Working Group member website, etc.). The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available under. - -**4.5. Submissions to Standards Bodies.** No Draft Specification or Approved Specification may be submitted to another standards development organization without Working group Approval. Upon reaching Approval, the Maintainer will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions. - -## 5. Non-Confidential, Restricted Disclosure. - -Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group. +# Community Specification Governance Policy 1.0 + +This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group and must adhere to the requirements in this document. + +## 1. Roles + +Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group. + +**1.1. Maintainer.** “Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the Working Group. Maintainers are also responsible for determining consensus and coordinating appeals. Each Working Group will designate one or more Maintainer for that Working Group. A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants. + +**1.2. Participants.** “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License. + +## 2. Decision Making + +**2.1. Consensus-Based Decision Making.** Working Groups make decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Maintainer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections. The Maintainer will document evidence of consensus in accordance with these requirements. + +**2.2. Appeal Process.** Decisions may be appealed be via a pull request or an issue, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time. + +## 3. Ways of Working + +Inspired by [ANSI’s Essential Requirements for Due Process](https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf), Community Specification Working Groups must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community Specifications. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus. + +**3.1. Openness.** Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required. + +**3.2. Lack of Dominance.** The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints. + +**3.3. Balance.** The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance. + +**3.4. Coordination and Harmonization.** Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards. + +**3.5. Consideration of Views and Objections.** Prompt consideration shall be given to the written views and objections of all Participants. + +**3.6. Written procedures.** This governance document and other materials documenting the Community Specification development process shall be available to any interested person. + +## 4. Specification Development Process + +**4.1. Pre-Draft.** Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group. The Maintainer will designate each submission as a “Pre-Draft” document. + +**4.2. Draft.** Each Pre-Draft document of a Working Group must first be Approved to become a” Draft Specification”. Once the Working Group approves a document as a Draft Specification, the Draft Specification becomes the basis for all going forward work on that specification. + +**4.3. Working Group Approval.** Once a Working Group believes it has achieved the objectives for its specification as described in the Scope, it will Approve that Draft Specification and progress it to “Approved Specification” status, such status to be effective forty-five days following such Approval. The Maintainer will update the NOTICES.MD file to indicate both the Approval of the Draft Specification and the date upon which its “Approved Specification” status will be effective which shall in no case be earlier than forty-five days following the date the Notices.md file was updated. + +**4.4. Publication and Submission.** Upon the designation of a Draft Specification as an Approved Specification, the Maintainer will publish the Approved Specification in a manner agreed upon by the Working Group Participants (i.e., Working Group Participant only location, publicly available location, Working Group maintained website, Working Group member website, etc.). The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available under. + +**4.5. Submissions to Standards Bodies.** No Draft Specification or Approved Specification may be submitted to another standards development organization without Working group Approval. Upon reaching Approval, the Maintainer will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions. + +## 5. Non-Confidential, Restricted Disclosure + +Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group. diff --git a/Notices.md b/Notices.md index 789f1cdb..bb6c2ef3 100644 --- a/Notices.md +++ b/Notices.md @@ -1,57 +1,57 @@ -# Notices - -## Code of Conduct - -Contributors to FINOS standards projects should follow the FINOS Code of Conduct, which can be found at [https://community.finos.org/docs/governance/code-of-conduct](https://community.finos.org/docs/governance/code-of-conduct). - -For issues or inquires, please contact [legal@linuxfoundation.org](mailto:legal@linuxfoundation.org). - -## License Acceptance - -Per Community Specification License 1.0 Section 2.1.3.3, Licensees may indicate their acceptance of the Community Specification License by issuing a pull request to this file, including the Licensee’s name, authorized individuals' names, and repository system identifier (e.g. GitHub ID), and specification version. - -A Licensee may consent to accepting the current Community Specification License version or any future version of the Community Specification License by indicating "or later" after their specification version. - ---------------------------------------------------------------------------------- - -Licensee’s name: - -Authorized individual and system identifier: - -Specification version: - ---------------------------------------------------------------------------------- - -## Withdrawals - -Name of party withdrawing: - -Date of withdrawal: - ---------------------------------------------------------------------------------- - -## Exclusions - -This section includes any Exclusion Notices made against a Draft Deliverable or Approved Deliverable as set forth in the Community Specification Development License. Each Exclusion Notice must include the following information: - -- Name of party making the Exclusion Notice: - -- Name of patent owner: - -- Specification: - -- Version number: - -**For issued patents and published patent applications:** - - (i) patent number(s) or title and application number(s), as the case may be: - - (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. - -**For unpublished patent applications must provide either:** - - (i) the text of the filed application; or - - (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. - ------------------------------------------------------------------------------------------ +# Notices + +## Code of Conduct + +Contributors to FINOS standards projects should follow the FINOS Code of Conduct, which can be found at [https://community.finos.org/docs/governance/code-of-conduct](https://community.finos.org/docs/governance/code-of-conduct). + +For issues or inquires, please contact [legal@linuxfoundation.org](mailto:legal@linuxfoundation.org). + +## License Acceptance + +Per Community Specification License 1.0 Section 2.1.3.3, Licensees may indicate their acceptance of the Community Specification License by issuing a pull request to this file, including the Licensee’s name, authorized individuals' names, and repository system identifier (e.g. GitHub ID), and specification version. + +A Licensee may consent to accepting the current Community Specification License version or any future version of the Community Specification License by indicating "or later" after their specification version. + +--- + +Licensee’s name: + +Authorized individual and system identifier: + +Specification version: + +--- + +## Withdrawals + +Name of party withdrawing: + +Date of withdrawal: + +--- + +## Exclusions + +This section includes any Exclusion Notices made against a Draft Deliverable or Approved Deliverable as set forth in the Community Specification Development License. Each Exclusion Notice must include the following information: + +- Name of party making the Exclusion Notice: + +- Name of patent owner: + +- Specification: + +- Version number: + +**For issued patents and published patent applications:** + + (i) patent number(s) or title and application number(s), as the case may be: + + (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. + +**For unpublished patent applications must provide either:** + + (i) the text of the filed application; or + + (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. + +--- diff --git a/Readme.md b/Readme.md index 0a899c7a..acdc0b96 100644 --- a/Readme.md +++ b/Readme.md @@ -1,6 +1,10 @@ + + [![FINOS - Incubating](https://cdn.jsdelivr.net/gh/finos/contrib-toolbox@master/images/badge-incubating.svg)](https://finosfoundation.atlassian.net/wiki/display/FINOS/Incubating) - + + +CCC Logo ## What Is It? @@ -8,25 +12,27 @@ FINOS Common Cloud Controls (FINOS CCC) is an open standard project that describ 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). +[Download the FINOS CCC Primer Here](./docs/training/FINOS-CCC-Primer-June-2024.pdf) + ## What Are The Benefits? -#### 💯 Defining Best Practices Around Cloud Security +### 💯 Defining Best Practices Around Cloud Security > 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. -#### 🎯 One Target For CSPs To Conform To +### 🎯 One Target For CSPs To Conform To > 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. -#### 🎒 Sharing The Burden Of A Common Definition +### 🎒 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 +### 🧭 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 +### 🥇 A Path Towards Certification > It is envisaged that eventually, CCC will offer _certification_ for CSPs who conform to the standard. @@ -51,21 +57,20 @@ There are several ways to contribute to FINOS Common Cloud Controls. The CCC project is split into 6 working groups in the CCC project which meet on a fortnightly basis: -| 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) | +| 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) | 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. - +FINOS Common Cloud Controls communications are conducted through the mailing list. Simply email [ccc-participants+subscribe@lists.finos.org](mailto: ) to join. ### 3. Raise a FINOS Common Cloud Controls GitHub Issue @@ -79,7 +84,7 @@ Please visit [participants.md](participants.md) and raise a Pull Request by addi 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. +Email if you require further help. ### FINOS Code of Conduct @@ -91,15 +96,15 @@ Participants of FINOS standards projects should follow the FINOS Code of Conduct 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). -| 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 | +| 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 | @robmoffat is the current [FINOS Point of Contact](docs/governance/finos-poc.md) for the CCC project. diff --git a/Scope.md b/Scope.md index ee8baaca..f2078c59 100644 --- a/Scope.md +++ b/Scope.md @@ -1,5 +1,5 @@ -# Scope - -[Include a detailed description of this Working Group’s Scope. This Scope is important as it establishes the bounds of each contributor's and licensee's patent commitment. For guidance on drafting an appropriate Scope, you may find [ISO's guidance (see page 5)](https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/how-to-write-standards.pdf "ISO How To Write Standards Guide") helpful. - -Any changes of Scope are not retroactive. +# Scope + +[Include a detailed description of this Working Group’s Scope. This Scope is important as it establishes the bounds of each contributor's and licensee's patent commitment. For guidance on drafting an appropriate Scope, you may find [ISO's guidance (see page 5)](https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/how-to-write-standards.pdf "ISO How To Write Standards Guide") helpful. + +Any changes of Scope are not retroactive. diff --git a/docs/formation/bootstrap.md b/docs/formation/bootstrap.md index f8c3c808..736fa823 100644 --- a/docs/formation/bootstrap.md +++ b/docs/formation/bootstrap.md @@ -6,30 +6,30 @@ 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 +## 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. The greater community was notified via 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 +## 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. The greater community will be invited via 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 +## 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. diff --git a/docs/governance/community-groups.md b/docs/governance/community-groups.md index 0d762b18..20eaac69 100644 --- a/docs/governance/community-groups.md +++ b/docs/governance/community-groups.md @@ -34,6 +34,6 @@ Changes to the community structure can be proposed through pull requests. All ch --- -[FINOS Code of Conduct]: -[Steering Committee Charter]: -[SC]: <#steering-committee> +[FINOS Code of Conduct]: https://www.finos.org/code-of-conduct +[Steering Committee Charter]: steering/charter.md +[SC]: #steering-committee diff --git a/docs/governance/community-guidelines/README.md b/docs/governance/community-guidelines/README.md index f4ac4b49..16148af1 100644 --- a/docs/governance/community-guidelines/README.md +++ b/docs/governance/community-guidelines/README.md @@ -16,7 +16,7 @@ In order for a guideline to become a policy a [SC], they must be put forward for 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 +[Policies]: ../community-policies +[vote]: ../steering/charter.md#voting +[SC]: ../../community-groups.md#steering-committee +[WG]: ../../community-groups.md#working-groups diff --git a/docs/governance/community-guidelines/communication.md b/docs/governance/community-guidelines/communication.md index e82c00b3..f3c94e5f 100644 --- a/docs/governance/community-guidelines/communication.md +++ b/docs/governance/community-guidelines/communication.md @@ -11,7 +11,7 @@ This document is a [community guideline]. ### FINOS Hosted Meetings -All meetings hosted by FINOS are expected to follow FINOS Anti-Trust policies. +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. @@ -25,7 +25,7 @@ Any meeting published on the public calendar must additionally adhere to a stric ### Recurring [WG] Meetings -- A [WG] may choose to hold recurring meetings to provide a dedicated space for discussion of [WG]-specific activities. +- 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]. @@ -36,7 +36,7 @@ Any meeting published on the public calendar must additionally adhere to a stric - 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 +[SC]: ../community-groups.md#steering-committee +[WG]: ../community-groups.md#working-groups +[community guideline]: ./README.md +[FINOS Point of Contact]: ../finos-poc.md diff --git a/docs/governance/community-guidelines/content-standards-and-practices/README.md b/docs/governance/community-guidelines/content-standards-and-practices/README.md index 3446ca5e..ad9de4d5 100644 --- a/docs/governance/community-guidelines/content-standards-and-practices/README.md +++ b/docs/governance/community-guidelines/content-standards-and-practices/README.md @@ -27,6 +27,6 @@ This directory will contain the content development standards and practices, whe Feedback on these policies is vital for continuous improvement. If you have suggestions or updates, please communicate this to the [Delivery WG]. Do note that new policies and standards 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> -[Delivery WG]: <../working-groups/delivery/ \ No newline at end of file +[SC]: ../../community-groups.md#steering-committee +[vote]: ../steering/charter.md#voting +[Delivery WG]: ../working-groups/delivery diff --git a/docs/governance/community-guidelines/content-standards-and-practices/markdown/formatting-guidelines.md b/docs/governance/community-guidelines/content-standards-and-practices/markdown/formatting-guidelines.md index 7f8d4ef9..7a6e9bd5 100644 --- a/docs/governance/community-guidelines/content-standards-and-practices/markdown/formatting-guidelines.md +++ b/docs/governance/community-guidelines/content-standards-and-practices/markdown/formatting-guidelines.md @@ -36,4 +36,4 @@ This section of this document contains a list of rules that are enabled for this Adhering to these formatting guidelines and using `prettier` will help ensure that our Markdown documents are not only consistent but also maintain a high standard of quality and readability. Regular use of `prettier` will streamline the document creation process, making it easier for everyone to produce well-formatted documentation. -[WG]: <../../community-groups.md#working-groups> \ No newline at end of file +[WG]: ../../community-groups.md#working-groups diff --git a/docs/governance/community-guidelines/content-standards-and-practices/markdown/linting-guidelines.md b/docs/governance/community-guidelines/content-standards-and-practices/markdown/linting-guidelines.md index 936ec1e9..46db916d 100644 --- a/docs/governance/community-guidelines/content-standards-and-practices/markdown/linting-guidelines.md +++ b/docs/governance/community-guidelines/content-standards-and-practices/markdown/linting-guidelines.md @@ -73,4 +73,4 @@ This section of this document contains a list of rules that are enabled for this Following these Markdown linting guidelines will help maintain a standard style across all our documents. Consistent formatting not only improves readability but also creates a professional appearance for all our communications. We encourage all contributors to adhere to these practices to ensure clarity and uniformity in our documentation. -[WG]: <../../community-groups.md#working-groups> \ No newline at end of file +[WG]: ../../community-groups.md#working-groups diff --git a/docs/governance/community-guidelines/meetings.md b/docs/governance/community-guidelines/meetings.md index 440fa78e..63950c00 100644 --- a/docs/governance/community-guidelines/meetings.md +++ b/docs/governance/community-guidelines/meetings.md @@ -51,6 +51,6 @@ Once minutes are added to the GitHub issue, close the issue. 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 +[WG]: ../community-groups.md#working-groups +[FINOS Point of Contact]: ../finos-poc.md +[community guideline]: ./README.md diff --git a/docs/governance/community-guidelines/member-roles.md b/docs/governance/community-guidelines/member-roles.md index bd912fd6..967a7361 100644 --- a/docs/governance/community-guidelines/member-roles.md +++ b/docs/governance/community-guidelines/member-roles.md @@ -1,24 +1,24 @@ # Member Roles -Everyone is welcome to contribute through discussion, issues, and pull requests. +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] | +| 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) +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 +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. @@ -38,16 +38,16 @@ assigned to them and assist or scribe on community calls. - 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. + - The PR description should contain a list or summary of your work on the project to date. + 1. 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.) + 1. 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. +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 @@ -72,7 +72,7 @@ These include, but are not limited to: 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 +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. @@ -131,22 +131,19 @@ 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 +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 +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 +[Linux Foundation Code of Conduct]: https://events.linuxfoundation.org/about/code-of-conduct/ +[CODEOWNERS]: https://github.com/finos/common-cloud-controls/blob/main/CODEOWNERS +[community mail group]: mailto:ccc-participants+subscribe@finos.org +[community groups]: ../community-groups.md +[SC]: ../../community-groups.md#steering-committee +[WG]: ../../community-groups.md#working-groups diff --git a/docs/governance/community-guidelines/proposing-working-group.md b/docs/governance/community-guidelines/proposing-working-group.md index 8aafd773..87a81362 100644 --- a/docs/governance/community-guidelines/proposing-working-group.md +++ b/docs/governance/community-guidelines/proposing-working-group.md @@ -9,6 +9,6 @@ To propose a new working group complete the items in the check list below: - 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> +[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 index c853ee72..d5b62a46 100644 --- a/docs/governance/community-guidelines/templates/charter.md +++ b/docs/governance/community-guidelines/templates/charter.md @@ -1,6 +1,6 @@ # Charter -This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) <*name of the working group*>. +This document outlines the mission, scope, and objectives of the Common Cloud Controls (CCC) <_name of the working group_>. ## Table of Contents @@ -8,64 +8,66 @@ This document outlines the mission, scope, and objectives of the Common Cloud Co 2. [Approach & Responsibilities](#approach--responsibilities) - [Output / Deliverables](#output--deliverables) 3. [Out of Scope](#out-of-scope) -4. [Meeting Cadence](#meeting-cadence) -5. [Governance](#governance) +4. [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.*> +<_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.*> +- <_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: +The following artifacts will be created and stored in the project GitHub repo: -- <*A list of outputs / deliverables the working group should produce.*> +- <_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.*> +- <_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. *> + + +<\* 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*> +- 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*> +- 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*>. +- <_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 +[WG]: ../../community-groups.md#working-groups +[SC]: ../../community-groups.md#steering-committee +[policies]: ../../community-policies/README.md +[recommendations]: ../../community-recommendations/README.md diff --git a/docs/governance/community-policies/README.md b/docs/governance/community-policies/README.md index b525e7d4..98c38168 100644 --- a/docs/governance/community-policies/README.md +++ b/docs/governance/community-policies/README.md @@ -10,5 +10,5 @@ This directory will contain the latest version of all policies that must be adhe 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> +[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 index 2e2a70a0..bab763dc 100644 --- a/docs/governance/finos-poc.md +++ b/docs/governance/finos-poc.md @@ -4,13 +4,13 @@ Most administative tasks around FINOS projects are performed by [FINOS Help](hel 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. +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. +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 index 3ca904e8..c8ae7a78 100644 --- a/docs/governance/steering/charter.md +++ b/docs/governance/steering/charter.md @@ -4,38 +4,38 @@ This document outlines the mission, scope, and objectives of the Common Cloud Co ## 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. +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. +- 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. +- 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: +- 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 @@ -89,17 +89,17 @@ Once a vote of no confidence has been called, the committee will notify the comm This notification will include: -* a link to the aforementioned GitHub issue -* the statement providing context on the reason for the vote +- 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 +- 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 +- send a message to individual committee members After this feedback period, Steering Committee members must vote on the issue within 48 hours. @@ -111,10 +111,10 @@ In the course of the committee's operations, members will be expected to vote on 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 +- 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. @@ -142,14 +142,14 @@ We use the following guidelines to determine whether we have reached quorum and ## 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. +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 +- 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. @@ -178,4 +178,7 @@ This document was adapted from the Kubernetes Steering Committee Charter [afb385 [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 index 59406fe1..f434575d 100644 --- a/docs/governance/steering/elections.md +++ b/docs/governance/steering/elections.md @@ -1,6 +1,6 @@ # Common Cloud Controls (CCC) Steering Committee Elections -This document outlines the process for steering committee elections. +This document outlines the process for steering committee [elections]. ## Eligibility @@ -20,10 +20,10 @@ _It is the responsibility of the steering committee to refine these criteria pri 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 +- 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. @@ -44,7 +44,7 @@ Election cycles are scheduled such that roughly half of the seats come up for re ### 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. +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 @@ -60,9 +60,9 @@ For example: - Election officers - Voter eligibility criteria - Election preparation -- September +- September - Nomination period and election -- October +- October - Conclusion of Election - Results announced at first community meeting after the election concludes @@ -72,7 +72,7 @@ The election officers will choose exact dates for each step and propose the fina 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. +[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 @@ -82,13 +82,13 @@ The steering committee should choose multiple election officers using the follow - 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]. +- Each officer can be relied upon to follow the [election procedure]. -History of election officers: +History of election officers: -|Year|Officers| -|---|---| -| 2024 | TBD | +| Year | Officers | +| ---- | -------- | +| 2024 | TBD | ## Steering Committee and Election Officer Recusal @@ -114,12 +114,8 @@ This document was adapted from the Kubernetes Steering Committee Elections docum --- [community groups]: ./community.md - [Condorcet]: https://en.wikipedia.org/wiki/Condorcet_method - -[election procedure]: #election-procedure - +[election procedure]: #nomination-and-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 index f27bb738..d23c02fe 100644 --- a/docs/governance/working-groups/communications/charter.md +++ b/docs/governance/working-groups/communications/charter.md @@ -30,7 +30,7 @@ This group will: - 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: @@ -47,7 +47,7 @@ The following items will be maintained in 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. +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 @@ -67,8 +67,7 @@ The membership structure of this working group: 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> +[WG]: ../../community-groups.md#working-groups +[SC]: ../../community-groups.md#steering-committee +[Community Structure WG]: ../community-structure/charter.md +[policies]: ../../community-policies/README.md diff --git a/docs/governance/working-groups/community-structure/charter.md b/docs/governance/working-groups/community-structure/charter.md index 82c54fcd..be5acf99 100644 --- a/docs/governance/working-groups/community-structure/charter.md +++ b/docs/governance/working-groups/community-structure/charter.md @@ -4,7 +4,7 @@ This [WG] facilitates the structure and governance design for the Common Cloud C ## 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. +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. @@ -43,7 +43,7 @@ To reduce unilateral authority from either this group or the [SC], all policy pr ## Membership -The membership structure of this [WG], including roles and responsibilities, must adhere to the latest recommendations from the Community Structure [WG]. +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]. @@ -57,5 +57,5 @@ This [WG] will use the mail group for regular co 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> +[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 index 57e76896..10af68aa 100644 --- a/docs/governance/working-groups/delivery/charter.md +++ b/docs/governance/working-groups/delivery/charter.md @@ -69,16 +69,16 @@ The membership structure of this working group: ### 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. +- 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> +[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 index 59486ba4..ddd365e0 100644 --- a/docs/governance/working-groups/duplication-reduction/charter.md +++ b/docs/governance/working-groups/duplication-reduction/charter.md @@ -21,7 +21,7 @@ This [WG] facilitates the research of existing frameworks for the Common Cloud C 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 +## Approach & Responsibilities This group will: @@ -29,7 +29,7 @@ This group will: - 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 +- 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 @@ -63,15 +63,15 @@ The membership structure of this working group: ### 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. +- 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> +[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 index df06406c..b9f4c0ba 100644 --- a/docs/governance/working-groups/security/charter.md +++ b/docs/governance/working-groups/security/charter.md @@ -8,11 +8,9 @@ This document outlines the mission, scope, and objectives of the Common Cloud Co 2. [Approach & Responsibilities](#approach--responsibilities) - [Output / Deliverables](#output--deliverables) 3. [Out of Scope](#out-of-scope) -4. [Meeting Cadence](#meeting-cadence) -5. [Governance](#governance) +4. [Governance](#governance) - [Membership](#membership) - [Changes](#changes) - - [Meeting Cadence](#meeting-cadence) - [Changes](#changes) ## Mission @@ -31,12 +29,12 @@ This group will: - 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 threats for each cloud service type - Catalog of security controls for each cloud service type ## Out of Scope @@ -59,7 +57,7 @@ The membership structure of this working group: ### Sub-Groups -This group **is** authorized to create independent 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. @@ -77,9 +75,9 @@ The following [WG] have been chartered by and are accountable to this group: 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 +[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 diff --git a/docs/governance/working-groups/taxonomy/charter.md b/docs/governance/working-groups/taxonomy/charter.md index 96cb5cf2..70dfe7ab 100644 --- a/docs/governance/working-groups/taxonomy/charter.md +++ b/docs/governance/working-groups/taxonomy/charter.md @@ -13,7 +13,7 @@ This document outlines the mission, scope, and objectives of the Common Cloud Co - [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. @@ -69,10 +69,10 @@ The membership structure of this working group. 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 +[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 diff --git a/docs/resources/frameworks/MITRE ATT&CK.md b/docs/resources/frameworks/MITRE ATT&CK.md new file mode 100644 index 00000000..1e4cb289 --- /dev/null +++ b/docs/resources/frameworks/MITRE ATT&CK.md @@ -0,0 +1,23 @@ +# MITRE ATT&CK + +In recent years, the MITRE ATT&CK framework has emerged as a crucial tool for organizations looking to enhance their cybersecurity posture, particularly in cloud environments. Unlike traditional control catalogs such as NIST 800-53 or the Cloud Security Alliance Cloud Controls Matrix (CSA CCM), MITRE ATT&CK offers a unique and valuable perspective that complements these existing frameworks. Here’s why MITRE ATT&CK is instrumental in conducting threat-informed assessments of controls for cloud services: + +## Comprehensive Threat Coverage + +MITRE ATT&CK provides a comprehensive framework that catalogs and categorizes adversarial tactics, techniques, and procedures (TTPs) based on real-world observations. Unlike control catalogs, which focus primarily on preventive or detective controls, ATT&CK details how adversaries operate at each stage of an attack lifecycle. This approach allows organizations to understand not only what controls to implement but also how to detect and respond to potential threats effectively. Additionally, traditional control catalogs like NIST 800-53 or CSA CCM provide essential guidelines, but they often lack granularity in addressing specific adversary tactics and techniques. This gap leaves organizations vulnerable to sophisticated cyber threats that exploit cloud infrastructures. + +## Emphasis on Adversary Behavior + +While NIST 800-53 and CSA CCM offer robust control frameworks, they may not always address the specific tactics adversaries employ to compromise cloud services. MITRE ATT&CK fills this gap by focusing on adversary behavior, providing a more proactive and realistic assessment of security controls. By aligning controls with known TTPs, organizations can prioritize investments in defenses that directly mitigate the tactics most likely to be used against them. + +## Continuous Improvement and Adaptability + +One of the strengths of MITRE ATT&CK is its dynamic nature. It is continuously updated based on ongoing research, contributions from the cybersecurity community, and new threat intelligence. This agility ensures that organizations are equipped with the latest insights into emerging threats and can adapt their security strategies accordingly. In contrast, traditional control catalogs may not evolve as rapidly or comprehensively in response to changing threat landscapes. + +## Industry Adoption and Standardization + +MITRE ATT&CK has gained widespread adoption across industries, becoming a de facto standard for describing and categorizing cyber threats. Its popularity stems from its practical utility in enhancing threat visibility, improving incident response capabilities, and supporting security operations. Many organizations, including leading cloud service providers, integrate ATT&CK into their threat detection tooling and threat intelligence programs to enhance their defensive strategies. + +## Integration with Existing Frameworks + +MITRE ATT&CK is designed to complement rather than replace existing control frameworks like NIST 800-53 or CSA CCM. By integrating ATT&CK with these frameworks, organizations can achieve a more holistic view of their security posture. ATT&CK helps bridge the gap between theoretical controls and real-world threat scenarios, offering actionable insights that enhance the effectiveness of existing security controls. diff --git a/docs/resources/readme.md b/docs/resources/readme.md new file mode 100644 index 00000000..a323e869 --- /dev/null +++ b/docs/resources/readme.md @@ -0,0 +1,38 @@ +# Resource Overview and Approach + +## Approach + +In developing CCC, we desire to reuse existing resources from other projects, such as frameworks, toolkits, documentation, or workflows. This can save time and effort, avoid duplication of work, and ensure consistency and quality across the project. However, reusing resources also requires some planning and coordination, as well as finding those best practices. In this section, we will provide guidance on resources we recommend and our reasoning behind them. + +Our approach is to break down the core deliverables being investigated by CCC into functional areas, then identify any potentially reusable content in each area. Once we’ve identified potential content, we will evaluate it for suitability by looking at its relevance, quality, and overall compatibility. It is likely that in some areas, no suitable content exists, where we will recommend that CCC invest directly. + +As we decompose the CCC project into these functional areas where duplication may exist, we think about it as a series of steps: + +1. **Service Taxonomy** – Provides a common set of cloud agnostic service definitions and attributes which we can refer to when discussing controls. These are mapped to the specific cloud provider services. For example, Virtual Machines is our common name for Amazon Elastic Cloud Compute, Azure Virtual Machines, and Google Compute Engine. +2. **Threats** – We evaluate a set of threats against the common service taxonomy, to understand the risks to be mitigated by the required controls. For example, an attacker may intercept traffic to a VM. +3. **Controls** – Once the threats are known, we map a set of controls to mitigate each of the threats. For example, all traffic to a VM must be encrypted. +4. **Evidence** – Finally, to consider a given cloud provider service to be compliant, a required set of evidence must be programmatically verified. For example, a policy X enforces network encryption on VMs. + +## Overview + +We summarize our recommendations against each of these areas: + +### Service Taxonomy + +One of the key goals of CCC, is to ensure that the controls are provider agnostic and enable portability between cloud providers. It is apparent that in order to do this, we must be able to work against a common taxonomy of services. +On first glance, it seems that there must be a common library of these, and we have investigated portability standards such as ISO/IEC 19941:2017, or more service specific standards such as OVF from DMTF. However, to date we have been unable to find a clear, comprehensive, and open common mapping. Therefore, our current recommendation in this space is to invest directly in a taxonomy provided by CCC. Future efforts may be spent to further evaluate this space. + +### Threats + +Many threat libraries exist today, but few are as widely adopted in financial services as the MITRE ATT&CK Framework. We seek to align with existing open industry best practices, and therefore are recommending MITRE ATT&CK be used as our base threat library. Read more about this reasoning here. + +### Controls + +Many existing control catalogs exist today, and this is a space with a diverse adoption landscape. We desire to use a controls framework that has broad adoption, is global, and will provide a wealth of mappings to both threat libraries and cloud provider evidence. + +NIST 800-53 is our top pick in this space and is our recommended control framework. + +### Evidence + +When it comes to evidence, our focus is on the format and retrieval strategies to be used. We desire formats that are commonly adopted by practitioners, and generally available from service providers. +The OSCAL format is a leading industry standard that meets these needs and is our current recommendation. diff --git a/docs/training/FINOS-CCC-Primer-June-2024.pdf b/docs/training/FINOS-CCC-Primer-June-2024.pdf new file mode 100644 index 00000000..5ef4570b Binary files /dev/null and b/docs/training/FINOS-CCC-Primer-June-2024.pdf differ diff --git a/docs/training/Readme.md b/docs/training/Readme.md new file mode 100644 index 00000000..5de442dd --- /dev/null +++ b/docs/training/Readme.md @@ -0,0 +1,7 @@ +# Training Docs + +## Links + +- [OSCAL](https://github.com/finos/common-cloud-controls/tree/main/docs/oscal/oscal.md) +- [Markdown Linting and Formatting - End User Guide](./lint_format_user_guide.md) +- [FINOS CCC Primer](./FINOS-CCC-Primer-June-2024.pdf) diff --git a/docs/training/lint_format_user_guide.md b/docs/training/lint_format_user_guide.md new file mode 100644 index 00000000..5e5e1c09 --- /dev/null +++ b/docs/training/lint_format_user_guide.md @@ -0,0 +1,75 @@ +# Markdown Linting and Formatting - End User Guide + +## Purpose + +This document provides a comprehensive guide for contributors to install and configure `markdownlint-cli` and `prettier` in Visual Studio Code (VSCode). These tools are essential for maintaining consistent markdown formatting and ensuring adherence to markdown style guidelines in your project. By following this guide, you will be able to: + +- Install `markdownlint-cli` and `prettier` as development dependencies in your project. +- Set up the necessary VSCode extensions for enhanced markdown editing. +- Reference configuration files for seamless integration with VSCode, ensuring that your markdown files are automatically linted and formatted. + +## Prerequisites + +Before you begin, please ensure you have Node.js installed. You can download it from [nodejs.org](https://nodejs.org/). + +## Installation Steps + +### Step 1: Installing Linter and Formatter + +1. Open your terminal. +2. Navigate to your project directory. +3. Run the following commands to install `markdownlint-cli` and `prettier` as development dependencies: + + ```bash + npm install -g markdownlint-cli prettier + ``` + +### Step 2: Install VSCode Extensions + +1. Open VSCode. +2. Go to the Extensions view by clicking on the Extensions icon in the Activity Bar on the side of the window or by pressing `Ctrl+Shift+X`. +3. Search for and install the following extensions: + - **Markdownlint** (by David Anson) + - **Prettier - Code formatter** (by Prettier) + +### Step 3: Configure `markdownlint` and `prettier` + +## Configuring VSCode + +### Reference Configuration Files in VSCode + +1. Open the Command Palette by pressing `Ctrl+Shift+P`. +2. Type `Preferences: Open Workspace Settings (JSON)` and select it. +3. Add the following configurations to your `settings.json` file to reference your config files: + + ```json + { + // Markdown & Prettier Configuration File + "editor.defaultFormatter": "esbenp.prettier-vscode", + "[markdown]": { + "editor.defaultFormatter": "esbenp.prettier-vscode" + }, + "markdownlint.config": { + "extends": "./.config/.markdownlint.yaml" + }, + "prettier.configPath": "./.config/.prettierrc" + } + ``` + +## Installation Verification + +1. Open a Markdown file in your project. +2. Save the file to trigger `prettier` formatting, or manually trigger it by pressing `Shift + Alt + F`. +3. Run the following command in your terminal to lint your Markdown files: + + ```bash + markdownlint-cli '**/*.md' --config ./.config/.markdownlint.yaml + ``` + + > **NOTE**: Ensure there are no linting errors or warnings. If so, please reach out to the [Delivery WG]. + +Thanks for reading. At this point, you have now successfully installed and configured `markdownlint-cli` and `prettier` in VSCode. + +If you have any issues, please do not hesistate to reach out to the [Delivery WG] for more assistance. + +[Delivery WG]: ../governance/working-groups/delivery/charter.md diff --git a/docs/training/oscal/examples/Readme.md b/docs/training/oscal/examples/Readme.md index 3f7ee24d..b68fbc6c 100644 --- a/docs/training/oscal/examples/Readme.md +++ b/docs/training/oscal/examples/Readme.md @@ -1,6 +1,6 @@ # OSCAL Examples -This directory contains OSCAL examples in XML, JSON, and YAML formats based on [the latest OSCAL stable release](github.com/usnistgov/OSCAL/releases/latest). The intention of those examples is to explore best ways of representing the Cloud Common Controls and associate data that supports the assessement process FINOS is establishing. +This directory contains OSCAL examples in XML, JSON, and YAML formats based on [the latest OSCAL stable release](github.com/usnistgov/OSCAL/releases/latest). The intention of those examples is to explore best ways of representing the Cloud Common Controls and associate data that supports the assessement process FINOS is establishing. The examples provided have been validated using the `oscal-cli` tool. For more information about the tool, please visit [NIST's oscal-cli repository](https://github.com/usnistgov/oscal-cli). NIST reserves the right to stop maintaining the tool at any time in the future, so the long term used of the tool needs to be decided with care. As of 02/09/2024, the version of `oscal-cli` is v1.0.3 and it implements OSCAL v1.1.2. A simple Makefile is also provided and can be invoked to install the `oscal-cli` tool in any local clone, in the [../../build/oscal-cli](../../build/oscal-cli) sub-directory. The .gitignore file is used to ignore committing the tool to the repository. A pipeline could use the Makefile to accomplish similar installation and artifacts' validation or conversion between formats. @@ -8,7 +8,7 @@ If desired, in the future, the Makefile can be invoked by a CI/CD pipeline to au The structure and contents of the examples directory are as follows: -- [examples](./examples): This directory contains sample OSCAL content organized by OSCAL models. +- [examples](./examples): This directory contains sample OSCAL content organized by OSCAL models. - [examples/catalog](./examples/catalog): This directory contains sample OSCAL content organized by OSCAL models. - [examples/catalog/xml](./examples/catalog/xml): XML representations of the OSCAL CCC catalog examples. - [examples/catalog/json](./examples/catalog/json): JSON representations of the OSCAL CCC catalog examples. @@ -17,6 +17,7 @@ The structure and contents of the examples directory are as follows: Different formats of the same content have been regenerated with the `oscal-cli` tool for consistency and accuracy of the data represented. OSCAL models provide sufficient flexibility to adept their use to the employed risk management process. It is not sufficient to represent the information in valid OSCAL format if the way data is captured in OSCAL does not support the employed risk management process and targeted compliance reporting. For example: -- [ ] is it sufficient to assess and report the status of the logical controls, or -- [ ] is it expected to include in the reports which threat mitigations are addressed, and + +- [ ] is it sufficient to assess and report the status of the logical controls, or +- [ ] is it expected to include in the reports which threat mitigations are addressed, and - [ ] map each mitigation to the identified threat(s) per each category the threat belongs to. diff --git a/docs/training/oscal/oscal.md b/docs/training/oscal/oscal.md index 48d8268c..72791077 100644 --- a/docs/training/oscal/oscal.md +++ b/docs/training/oscal/oscal.md @@ -1,18 +1,17 @@ # Training Docs - OSCAL -| Link | Description | Notes | -| ---- | ----------- | ----- | -| [NIST: OSCAL website](https://www.nist.gov/oscal) | Official OSCAL website | | -| [OSCAL Instructional Videos, Presentations, and Blogs](https://pages.nist.gov/OSCAL/learn/presentations/) | NIST Link to OSCAL Instructional Videos, Presentations, and Blogs | | -| [Security Automation Simplified via NIST OSCAL: We're Not in Kansas Anymore](https://www.youtube.com/watch?v=eP8K7piU5UQ) | RSA 2018 video explaining catalogs and profiles | Video is 5 years old, so may be out of date in places. | -| [NIST OSCAL GitHub (public)](https://www.github.com/usnistgov/OSCAL) | NIST OSCAL GitHub repository | | -| [OSCAL lobby on Gitter](https://gitter.im/usnistgov-OSCAL/Lobby) | Chat channel with the community | **STRONGLY RECOMMENDED** for engaging with the OSCAL community | -| [3rd Annual OSCAL Workshop (recorded)](https://pages.nist.gov/OSCAL/learn/presentations/oscal-workshop-2022-03/) | Recorded videos from 2022 workshop | Also available [here](https://www.nist.gov/news-events/events/2022/03/3rd-open-security-controls-assessment-language-oscal-workshop) | -| [4th Annual OSCAL Conference (recorded)](https://www.nist.gov/news-events/events/2023/05/4th-open-security-controls-assessment-language-oscal-conference-and) | Recorded conference, including CNCF presentation | CNCF presentation is last on the agenda | -| [Blog](https://www.nist.gov/blogs/cybersecurity-insights/foundation-interoperable-and-portable-security-automation-revealed) | NIST Cybersecurity Insights Blog | | -| [OSCAL Adopters' Mini Workshop Series](https://csrc.nist.gov/Projects/open-security-controls-assessment-language/oscal-adopters-workshops) | Workshop series for OSCAL adopters | Opened primarily to community members to present OSCAL adoption | -| [An OSCAL 101 (Educational) Workshop Series](https://csrc.nist.gov/Projects/open-security-controls-assessment-language/oscal-education-workshops) | Educational workshop series | One recording missing; will be redone | -| [OSCAL Catalog Tutorial](https://pages.nist.gov/OSCAL/learn/tutorials/control/basic-catalog/) | Tutorial on OSCAL catalogs | Based on 2 ISO/IEC 27002 controls | -| [SP 800-53 example explained](https://pages.nist.gov/OSCAL/resources/concepts/layer/control/catalog/sp800-53rev5-example/) | Explanation of SP 800-53 example | | -| [IBM Trestle](https://github.com/IBM/compliance-trestle) | Tooling for managing OSCAL documents | Claims to provide human-friendly management and transformation of OSCAL documents | - +| Link | Description | Notes | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | +| [NIST: OSCAL website](https://www.nist.gov/oscal) | Official OSCAL website | | +| [OSCAL Instructional Videos, Presentations, and Blogs](https://pages.nist.gov/OSCAL/learn/presentations/) | NIST Link to OSCAL Instructional Videos, Presentations, and Blogs | | +| [Security Automation Simplified via NIST OSCAL: We're Not in Kansas Anymore](https://www.youtube.com/watch?v=eP8K7piU5UQ) | RSA 2018 video explaining catalogs and profiles | Video is 5 years old, so may be out of date in places. | +| [NIST OSCAL GitHub (public)](https://www.github.com/usnistgov/OSCAL) | NIST OSCAL GitHub repository | | +| [OSCAL lobby on Gitter](https://gitter.im/usnistgov-OSCAL/Lobby) | Chat channel with the community | **STRONGLY RECOMMENDED** for engaging with the OSCAL community | +| [3rd Annual OSCAL Workshop (recorded)](https://pages.nist.gov/OSCAL/learn/presentations/oscal-workshop-2022-03/) | Recorded videos from 2022 workshop | Also available [here](https://www.nist.gov/news-events/events/2022/03/3rd-open-security-controls-assessment-language-oscal-workshop) | +| [4th Annual OSCAL Conference (recorded)](https://www.nist.gov/news-events/events/2023/05/4th-open-security-controls-assessment-language-oscal-conference-and) | Recorded conference, including CNCF presentation | CNCF presentation is last on the agenda | +| [Blog](https://www.nist.gov/blogs/cybersecurity-insights/foundation-interoperable-and-portable-security-automation-revealed) | NIST Cybersecurity Insights Blog | | +| [OSCAL Adopters' Mini Workshop Series](https://csrc.nist.gov/Projects/open-security-controls-assessment-language/oscal-adopters-workshops) | Workshop series for OSCAL adopters | Opened primarily to community members to present OSCAL adoption | +| [An OSCAL 101 (Educational) Workshop Series](https://csrc.nist.gov/Projects/open-security-controls-assessment-language/oscal-education-workshops) | Educational workshop series | One recording missing; will be redone | +| [OSCAL Catalog Tutorial](https://pages.nist.gov/OSCAL/learn/tutorials/control/basic-catalog/) | Tutorial on OSCAL catalogs | Based on 2 ISO/IEC 27002 controls | +| [SP 800-53 example explained](https://pages.nist.gov/OSCAL/resources/concepts/layer/control/catalog/sp800-53rev5-example/) | Explanation of SP 800-53 example | | +| [IBM Trestle](https://github.com/IBM/compliance-trestle) | Tooling for managing OSCAL documents | Claims to provide human-friendly management and transformation of OSCAL documents | diff --git a/participants.md b/participants.md index 2fdcfb60..bc6d2917 100644 --- a/participants.md +++ b/participants.md @@ -1,7 +1,9 @@ # Participants enrolled in the Common Cloud Controls project + Below is the list of [participants](governance-documents/5._Governance.md#1roles) in the {standard_name}, who have committed to the [Community Specification Contributor License Agreement](governance-documents/0._CS_Contributor_License_Agreement.md). ## Participants + - Name, organization, Date of enrollment: MMM/DD/YYYY - Euthyme Ziogas, Scott Logic, SEP/14/2023 - Emily Fox, Red Hat, SEPT/14/2023 @@ -14,7 +16,7 @@ Below is the list of [participants](governance-documents/5._Governance.md#1roles - Rachel Kim, Google, 09/22/2023 - Mitch Hibbs, Symphony, Date of enrollment: Oct/05/2023 - Charlotte Hayes, Scott Logic, Oct/19/2023 -- Steven Shiells, Scott Loigc: Oct/19/2023 +- Steven Shiells, Scott Loigc: Oct/19/2023 - Andrés Vega, Messier 42 (M42), Oct/24/2023 - Ian Miell, Container Solutions, Oct/26/2023 - Aaron Sutton, Google, Date of enrollment: NOV/07/2023 @@ -31,41 +33,32 @@ Below is the list of [participants](governance-documents/5._Governance.md#1roles - Dave Ogle, Scott Logic, JUN/28/2024 - Leroy Abikhui, LSEG, Jul/16/2024 - Chris Plank, Natwest, JUL/17/2024 +- Ted Newman, NatWest Group, JUL/17/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. - -_:question:Please email help@finos.org if you encounter issues or have questions._ - -**Step 1. Go to the [participants](#participants) file** and make sure you are signed into your github account - -**Step 2. Click on the :pen: icon at the top right of the the [participants](#participants) file** - -[](https://user-images.githubusercontent.com/51138318/151390328-00e6ac68-6069-493e-b536-d329fa9cc51e.png) - -**Step 3. Add your name** to the "Participants" section - -[](https://user-images.githubusercontent.com/51138318/151390531-78b82963-f5af-42a7-be27-b3010c343795.png) -**Step 4.** **Commit your changes.** Scroll to the bottom of the page and click on the green "Commit changes" button - -[](https://user-images.githubusercontent.com/51138318/151390757-69ca6d4a-8972-4134-9239-caf02d8fb105.png) +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. -**Step 5. Create a Pull Request** to request that the changes you made to the [participants](#participants) file be added to the "main" branch of the https://github.com/finos/{project slug} repository +1. Go to the [participants](#participants) file and make sure you are signed into your github account -**Step 5.1. Click on "Pull Request" in the GitHub navigation bar** +1. Click on the :pen: icon at the top right of the the [participants](#participants) file + [Participants Image 1](https://user-images.githubusercontent.com/51138318/151390328-00e6ac68-6069-493e-b536-d329fa9cc51e.png) -[](https://user-images.githubusercontent.com/51138318/151392066-eea01c80-1722-4545-8eb3-6a5e09fe8a5e.png) - -**Step 5.2. Click on the green "Compare & pull request" button** +1. Add your name to the "Participants" section + [Participants Image 2](https://user-images.githubusercontent.com/51138318/151390531-78b82963-f5af-42a7-be27-b3010c343795.png) -[](https://user-images.githubusercontent.com/51138318/151392480-86b526ec-53c2-47ef-8807-d9442f3f4d04.png) - -**Step 5.3. Choose a title for your Pull Request, add your name and the project name, and then click on "Create Pull Request"** +1. Commit your changes and scroll to the bottom of the page and click on the green "Commit changes" button. + [Commit Changes Image](https://user-images.githubusercontent.com/51138318/151390757-69ca6d4a-8972-4134-9239-caf02d8fb105.png) -[](https://user-images.githubusercontent.com/51138318/151393034-bde9e089-6b75-4829-9f7e-f7c2f20dcef1.png) +1. Create a Pull Request to request that the changes you made to the [participants](#participants) file be added to the "main" branch of the < repository -_:question:Please email help@finos.org if you encounter issues or have questions._ + 1. Click on "Pull Request" in the GitHub navigation bar + [Opening PR](https://user-images.githubusercontent.com/51138318/151392066-eea01c80-1722-4545-8eb3-6a5e09fe8a5e.png) + 1. Click on the green "Compare & pull request" button + [Compare PR](https://user-images.githubusercontent.com/51138318/151392480-86b526ec-53c2-47ef-8807-d9442f3f4d04.png) + 1. Choose a title for your Pull Request, add your name and the project name, and then click on "Create Pull Request" + [Creating PR Title](https://user-images.githubusercontent.com/51138318/151393034-bde9e089-6b75-4829-9f7e-f7c2f20dcef1.png) +> **NOTE**: _:question:Please email if you encounter issues or have questions._ diff --git a/services/common-cloud-services.md b/services/common-cloud-services.md index 19251dfa..c2d3cf6c 100644 --- a/services/common-cloud-services.md +++ b/services/common-cloud-services.md @@ -10,19 +10,18 @@ The Service Taxonomy column MUST be present and MUST NOT be null or empty. Primary purpose and the core functionality covered by the Service Taxonomy -| Service Taxonomy | Description | -| -------- | ---------- | -| Compute Services | Virtual computing, container services, batch operations, serverless functions, high-performance computing | -| Storage Services | Storage for structured and unstructured data in the forms of objects, blobs queues, etc | -| Database Services | Database platforms and services that allow for storage and querying of data. | -| Application Integrations | Event buses, message broker services, message queues and various notification services | -| Networking Service | Networking and content delivery related services | -| Analytics | Daata processing, analytics, and visualization capabilities. | -| AI and Machine Learning | Artificial Intelligence and Machine Learning related technologies. | -| Security and Identity Services | Access and Authorization management, creation and control of encryption keys, provisioning of SSL/TLS certificates, secret management | -| Management and Governance Services | Services including logging, monitoring, tracing, debugging, audit trails, cost optimizing | -| Developer Tools | SDK, CLI, CI/CD tools, etc. | - +| Service Taxonomy | Description | +| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | +| Compute Services | Virtual computing, container services, batch operations, serverless functions, high-performance computing | +| Storage Services | Storage for structured and unstructured data in the forms of objects, blobs queues, etc | +| Database Services | Database platforms and services that allow for storage and querying of data. | +| Application Integrations | Event buses, message broker services, message queues and various notification services | +| Networking Service | Networking and content delivery related services | +| Analytics | Daata processing, analytics, and visualization capabilities. | +| AI and Machine Learning | Artificial Intelligence and Machine Learning related technologies. | +| Security and Identity Services | Access and Authorization management, creation and control of encryption keys, provisioning of SSL/TLS certificates, secret management | +| Management and Governance Services | Services including logging, monitoring, tracing, debugging, audit trails, cost optimizing | +| Developer Tools | SDK, CLI, CI/CD tools, etc. | ## References diff --git a/services/compute-services.md b/services/compute-services.md index 83ae63b2..7bb26fd4 100644 --- a/services/compute-services.md +++ b/services/compute-services.md @@ -1,6 +1,6 @@ # Compute Services -Compute services in the context of cloud computing refer to the resources and capabilities provided by cloud service providers to run and manage applications, workloads, and virtualized computing environments in a scalable, flexible, and cost-effective manner. These services enable users to provision, configure, and manage virtual servers, containers, serverless functions, and other computing resources without the need for physical hardware procurement or management. +Compute services in the context of cloud computing refer to the resources and capabilities provided by cloud service providers to run and manage applications, workloads, and virtualized computing environments in a scalable, flexible, and cost-effective manner. These services enable users to provision, configure, and manage virtual servers, containers, serverless functions, and other computing resources without the need for physical hardware procurement or management. ## Types of Compute Services @@ -17,7 +17,7 @@ Virtual machines are virtualized instances of computer hardware that emulate phy Examples: - **AWS**: Amazon Elastic Compute Cloud (EC2) -- **Azure**: Virtual Machines +- **Azure**: Virtual Machines - **Google Cloud**: Compute Engine Read more about [Virtual Machines](compute/virtual-machines/taxonomy.md) @@ -42,7 +42,7 @@ Examples: ### Batch Processing -Batch processing services enable users to execute large-scale, parallelizable computing tasks, such as data processing, analytics, and batch jobs. These services automatically allocate and manage compute resources to execute batch jobs efficiently and cost-effectively. Users can specify job requirements, dependencies, and scheduling preferences to optimize job execution. +Batch processing services enable users to execute large-scale, parallelizable computing tasks, such as data processing, analytics, and batch jobs. These services automatically allocate and manage compute resources to execute batch jobs efficiently and cost-effectively. Users can specify job requirements, dependencies, and scheduling preferences to optimize job execution. Examples: @@ -58,4 +58,4 @@ Examples: - **AWS**: AWS IoT Greengrass and AWS Outposts - **Azure**: Azure IoT Edge -- **Google Cloud**: Google Cloud IoT Edge \ No newline at end of file +- **Google Cloud**: Google Cloud IoT Edge diff --git a/services/compute/virtual-machines/taxonomy.md b/services/compute/virtual-machines/taxonomy.md index 42f21e20..0832d156 100644 --- a/services/compute/virtual-machines/taxonomy.md +++ b/services/compute/virtual-machines/taxonomy.md @@ -6,41 +6,41 @@ use in financial services ecosystems. ## Taxonomy -| Taxonomy ID | Feature | Description | -| ----------- | ------- | ----------- | -| CCC-030101 | Instance Types - General Computing | Providing a range of instance types with different specifications for CPU and memory. | -| CCC-030102 | Instance Types - Storage Optimised | Providing instance types with storage optimization features including high-speed I/O capabilities, disk types, and high capacities. | -| CCC-030103 | Instance Types - GPU Optimised | Providing instance types tailored specifically for GPU-intensive workloads. | -| CCC-030104 | Instance Types - Network Optimised | Providing instance types equipped with a range of networking capabilities, including options for high-bandwidth connections, low-latency networking, and the ability to attach multiple or redundant network interfaces. | -| CCC-030105 | Instance Types - Dynamic Performance | Providing "burstable" instances for intermittent workloads that accumulate credits during periods of low usage which can be used to burst above baseline performance when needed. | -| CCC-030106 | Operating System Options | A selection of operating systems for virtual machine instances. | -| CCC-030107 | Ephemeral Storage | Temporary storage available to the VM which is lost when the instance is stopped or terminated. | -| CCC-030108 | High Availability | Ensuring high availability of virtual machine instances through redundancy and multiple (availability) zones within a region. | -| CCC-030109 | Identity and Access Management | Implementing identity and access management features such as key pairs, JIT and MFA to control user access to virtual machine instances. | -| CCC-030110 | Monitoring and Logging | Offering monitoring and logging capabilities to track performance metrics, user access and security events. | -| CCC-030111 | Backup and Restore | Providing backup and disaster recovery solutions for virtual machine instances and associated data, including snapshot-based backups, incremental backups, and point-in-time recovery. | -| CCC-030112 | Encryption at Rest | Encrypting data stored by virtual machine instances to protect against unauthorized access. | -| CCC-030113 | Patch Management | Offering patch management services and compatibility with third party patch management tools to keep virtual machine instances up to date with security patches and updates. | -| CCC-030114 | Isolated Secure Environments | Providing an isolated "enclave" within a virtual machine for processing encrypted and/or sensitive data, with support for custom key management infrastructure. | -| CCC-030115 | Nested Virtualization | Allowing the creation of virtual machines within virtual machines. | -| CCC-030116 | Container Support | Offering support for running containers within virtual machine instances for containerized applications. | -| CCC-030117 | Instance Metadata | Providing metadata about virtual machine instances for configuration and management purposes. | -| CCC-030118 | Instance Lifecycle Events | Offering features for managing the lifecycle and state of virtual machine instances, including starting, stopping, pausing, and restarting instances as needed. | -| CCC-030119 | Instance Snapshots | Creation of snapshots of virtual machine instances to capture and preserve state and data for backup and cloning purposes. | -| CCC-030120 | Instance Templates | Offering templates for provisioning virtual machine instances with pre-configured images, instance types and network configurations. | -| CCC-030121 | Bootstrap Scripts | Ability to provide bootstrap scripts to a VM to run during the instance boot process. | -| CCC-030122 | Instance Preemptibility | Providing the option for using preemptible virtual machine (spot) instances at a lower cost for non-critical or fault-tolerant workloads that may be terminated by the cloud provider after a notice period. | -| CCC-030123 | Instance Affinity/Anti-affinity | Enabling control over the location of virtual machine instances to ensure or prevent co-location on the same physical hardware. | -| CCC-030124 | Instance Health Checks | Exposing health checks on virtual machine instances so that unhealthy instances can to automatically replaced or repaired. | -| CCC-030125 | Instance Remote Access | Offering remote access to virtual machine instances through methods such as SSH or RDP for troubleshooting, debugging, and maintenance purposes. | -| CCC-030126 | Instance Live Migration | Ability to perform live migration of virtual machine instances between physical hosts for maintenance or load balancing purposes without downtime. | -| CCC-030127 | Instance Remote Configuration | Providing tools for remotely configuring virtual machine instances, including deployment automation and configuration management frameworks. | -| CCC-030128 | Instance Resource Tagging | Enabling tagging of virtual machine instances with metadata for organization, management, and cost allocation purposes. | -| CCC-030129 | Instance Resource Utilisation Metrics | Providing tools for monitoring resource utilization and performance metrics for virtual machine instances, including CPU usage, memory usage, disk I/O, and network traffic. | -| CCC-030130 | Custom Images | Allows users to create and manage their own customized virtual machine images. | -| CCC-030131 | Dedicated Instances | Providing the option to run instances on physical servers that are dedicated solely to a single customer account, ensuring that the underlying hardware resources are not shared with other customers. | -| CCC-030132 | Interoperability with Storage Options | Capability to read/write to non-ephemeral external storage including object storage and encrypted block storage. | -| CCC-030133 | Instance Autoscaling | Providing an interface for autoscaling services to automatically adjusting the number and/or instance type of virtual machine instances based on predefined criteria such as CPU utilization or incoming traffic. | -| CCC-030134 | Instance Grouping | Offering logical grouping and management tools for sets of virtual machine instances. | -| CCC-030135 | Security Groups | Ability to configure security groups or firewalls to control inbound and outbound traffic to and from instances. | -| CCC-030136 | TPM Support | Providing support for Trusted Platform Module (TPM) for hardware-based security features such as secure boot and cryptographic key storage. | \ No newline at end of file +| Taxonomy ID | Feature | Description | +| ----------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| CCC-030101 | Instance Types - General Computing | Providing a range of instance types with different specifications for CPU and memory. | +| CCC-030102 | Instance Types - Storage Optimised | Providing instance types with storage optimization features including high-speed I/O capabilities, disk types, and high capacities. | +| CCC-030103 | Instance Types - GPU Optimised | Providing instance types tailored specifically for GPU-intensive workloads. | +| CCC-030104 | Instance Types - Network Optimised | Providing instance types equipped with a range of networking capabilities, including options for high-bandwidth connections, low-latency networking, and the ability to attach multiple or redundant network interfaces. | +| CCC-030105 | Instance Types - Dynamic Performance | Providing "burstable" instances for intermittent workloads that accumulate credits during periods of low usage which can be used to burst above baseline performance when needed. | +| CCC-030106 | Operating System Options | A selection of operating systems for virtual machine instances. | +| CCC-030107 | Ephemeral Storage | Temporary storage available to the VM which is lost when the instance is stopped or terminated. | +| CCC-030108 | High Availability | Ensuring high availability of virtual machine instances through redundancy and multiple (availability) zones within a region. | +| CCC-030109 | Identity and Access Management | Implementing identity and access management features such as key pairs, JIT and MFA to control user access to virtual machine instances. | +| CCC-030110 | Monitoring and Logging | Offering monitoring and logging capabilities to track performance metrics, user access and security events. | +| CCC-030111 | Backup and Restore | Providing backup and disaster recovery solutions for virtual machine instances and associated data, including snapshot-based backups, incremental backups, and point-in-time recovery. | +| CCC-030112 | Encryption at Rest | Encrypting data stored by virtual machine instances to protect against unauthorized access. | +| CCC-030113 | Patch Management | Offering patch management services and compatibility with third party patch management tools to keep virtual machine instances up to date with security patches and updates. | +| CCC-030114 | Isolated Secure Environments | Providing an isolated "enclave" within a virtual machine for processing encrypted and/or sensitive data, with support for custom key management infrastructure. | +| CCC-030115 | Nested Virtualization | Allowing the creation of virtual machines within virtual machines. | +| CCC-030116 | Container Support | Offering support for running containers within virtual machine instances for containerized applications. | +| CCC-030117 | Instance Metadata | Providing metadata about virtual machine instances for configuration and management purposes. | +| CCC-030118 | Instance Lifecycle Events | Offering features for managing the lifecycle and state of virtual machine instances, including starting, stopping, pausing, and restarting instances as needed. | +| CCC-030119 | Instance Snapshots | Creation of snapshots of virtual machine instances to capture and preserve state and data for backup and cloning purposes. | +| CCC-030120 | Instance Templates | Offering templates for provisioning virtual machine instances with pre-configured images, instance types and network configurations. | +| CCC-030121 | Bootstrap Scripts | Ability to provide bootstrap scripts to a VM to run during the instance boot process. | +| CCC-030122 | Instance Preemptibility | Providing the option for using preemptible virtual machine (spot) instances at a lower cost for non-critical or fault-tolerant workloads that may be terminated by the cloud provider after a notice period. | +| CCC-030123 | Instance Affinity/Anti-affinity | Enabling control over the location of virtual machine instances to ensure or prevent co-location on the same physical hardware. | +| CCC-030124 | Instance Health Checks | Exposing health checks on virtual machine instances so that unhealthy instances can to automatically replaced or repaired. | +| CCC-030125 | Instance Remote Access | Offering remote access to virtual machine instances through methods such as SSH or RDP for troubleshooting, debugging, and maintenance purposes. | +| CCC-030126 | Instance Live Migration | Ability to perform live migration of virtual machine instances between physical hosts for maintenance or load balancing purposes without downtime. | +| CCC-030127 | Instance Remote Configuration | Providing tools for remotely configuring virtual machine instances, including deployment automation and configuration management frameworks. | +| CCC-030128 | Instance Resource Tagging | Enabling tagging of virtual machine instances with metadata for organization, management, and cost allocation purposes. | +| CCC-030129 | Instance Resource Utilisation Metrics | Providing tools for monitoring resource utilization and performance metrics for virtual machine instances, including CPU usage, memory usage, disk I/O, and network traffic. | +| CCC-030130 | Custom Images | Allows users to create and manage their own customized virtual machine images. | +| CCC-030131 | Dedicated Instances | Providing the option to run instances on physical servers that are dedicated solely to a single customer account, ensuring that the underlying hardware resources are not shared with other customers. | +| CCC-030132 | Interoperability with Storage Options | Capability to read/write to non-ephemeral external storage including object storage and encrypted block storage. | +| CCC-030133 | Instance Autoscaling | Providing an interface for autoscaling services to automatically adjusting the number and/or instance type of virtual machine instances based on predefined criteria such as CPU utilization or incoming traffic. | +| CCC-030134 | Instance Grouping | Offering logical grouping and management tools for sets of virtual machine instances. | +| CCC-030135 | Security Groups | Ability to configure security groups or firewalls to control inbound and outbound traffic to and from instances. | +| CCC-030136 | TPM Support | Providing support for Trusted Platform Module (TPM) for hardware-based security features such as secure boot and cryptographic key storage. | diff --git a/services/database-services.md b/services/database-services.md index b435277d..1641cbd1 100644 --- a/services/database-services.md +++ b/services/database-services.md @@ -1,12 +1,13 @@ # Database Services -Database services in the context of cloud computing refer to managed database solutions provided by cloud service providers. These services enable users to store, manage, and access structured data in a scalable, reliable, and cost-effective manner. +Database services in the context of cloud computing refer to managed database solutions provided by cloud service providers. These services enable users to store, manage, and access structured data in a scalable, reliable, and cost-effective manner. ## Types of Database Services + - [Relational Databases](#relational-databases) - [NoSQL Databases](#nosql-databases) -- [Graph Databases](#graph-databases) - [In-Memory Databases](#in-memory-databases) +- Graph Databases - [Data Warehousing](#data-warehousing) ### Relational Databases @@ -23,7 +24,7 @@ Read more about [RDMS Taxonomy](database/relational/taxonomy.md) ### NoSQL Databases -NoSQL (Not Only SQL) databases support flexible, schema-less data models and are suitable for semi-structured or unstructured data. +NoSQL (Not Only SQL) databases support flexible, schema-less data models and are suitable for semi-structured or unstructured data. Examples: @@ -33,7 +34,7 @@ Examples: ### In-Memory Databases -In-memory database services store data in memory for faster read and write operations, making them ideal for high-performance applications. +In-memory database services store data in memory for faster read and write operations, making them ideal for high-performance applications. Examples: @@ -49,4 +50,4 @@ Examples: - **AWS**: Amazon Redshift - **Azure**: Azure Synapse Analytics -- **Google Cloud**: Google BigQuery \ No newline at end of file +- **Google Cloud**: Google BigQuery diff --git a/services/database/relational/taxonomy.md b/services/database/relational/taxonomy.md index 7e223524..5abfc0b4 100644 --- a/services/database/relational/taxonomy.md +++ b/services/database/relational/taxonomy.md @@ -6,18 +6,18 @@ use in financial services ecosystems. ## Taxonomy -| Taxonomy ID | Feature | Description | -| ----------- | ------- | ----------- | -| CCC-RDMS-1 | SQL Support | Properly handle queries in the SQL language. | -| CCC-RDMS-2 | Vertical Scaling | Users may increase or decrease resource allocation. | -| CCC-RDMS-3 | Horizontal Scaling | Read replicas of the primary database can be created. | -| CCC-RDMS-4 | Multi-region | Read replicas can be created in multiple user-specified regions. | -| CCC-RDMS-5 | Automated Backups | Backups can be automatically created and stored according to user specification. | -| CCC-RDMS-6 | Point in Time Recovery | Backups can be restored on demand to a specific point in time. | -| CCC-RDMS-7 | Encryption at Rest | Data is encrypted at rest, and can be encrypted with user private keys. | -| CCC-RDMS-8 | Encryption in Transit | Data is encrypted in transit, and can be encrypted with user private keys. | -| CCC-RDMS-9 | Role Based Access Control | Users can be assigned roles with specific permissions. | -| CCC-RDMS-10 | Logging | Configurable logs are available for user inspection. | -| CCC-RDMS-11 | Monitoring | Configurable metrics are available for user inspection. | -| CCC-RDMS-12 | Alerting | Configurable alerts can be enabled. | -| CCC-RDMS-13 | Failover | Standby database can be implemented for failover when the primary can't be reached. | +| Taxonomy ID | Feature | Description | +| ----------- | ------------------------- | ----------------------------------------------------------------------------------- | +| CCC-RDMS-1 | SQL Support | Properly handle queries in the SQL language. | +| CCC-RDMS-2 | Vertical Scaling | Users may increase or decrease resource allocation. | +| CCC-RDMS-3 | Horizontal Scaling | Read replicas of the primary database can be created. | +| CCC-RDMS-4 | Multi-region | Read replicas can be created in multiple user-specified regions. | +| CCC-RDMS-5 | Automated Backups | Backups can be automatically created and stored according to user specification. | +| CCC-RDMS-6 | Point in Time Recovery | Backups can be restored on demand to a specific point in time. | +| CCC-RDMS-7 | Encryption at Rest | Data is encrypted at rest, and can be encrypted with user private keys. | +| CCC-RDMS-8 | Encryption in Transit | Data is encrypted in transit, and can be encrypted with user private keys. | +| CCC-RDMS-9 | Role Based Access Control | Users can be assigned roles with specific permissions. | +| CCC-RDMS-10 | Logging | Configurable logs are available for user inspection. | +| CCC-RDMS-11 | Monitoring | Configurable metrics are available for user inspection. | +| CCC-RDMS-12 | Alerting | Configurable alerts can be enabled. | +| CCC-RDMS-13 | Failover | Standby database can be implemented for failover when the primary can't be reached. | diff --git a/services/networking-services.md b/services/networking-services.md index ac8840fe..357fdd5f 100644 --- a/services/networking-services.md +++ b/services/networking-services.md @@ -1,6 +1,6 @@ # Networking Service -Networking services in the context of cloud computing refer to the set of tools and resources provided by cloud service providers to facilitate communication, connectivity, and security within and between cloud environments, data centers, and end-users. These services enable users to build, manage, and optimize network infrastructure in a flexible, scalable, and cost-effective manner. +Networking services in the context of cloud computing refer to the set of tools and resources provided by cloud service providers to facilitate communication, connectivity, and security within and between cloud environments, data centers, and end-users. These services enable users to build, manage, and optimize network infrastructure in a flexible, scalable, and cost-effective manner. ## Types of Networking Services @@ -17,7 +17,7 @@ VPC is a logically isolated virtual network environment within the cloud, allowi ### Virtual Private Network (VPN) -VPN services establish secure encrypted connections between on-premises networks and cloud resources, enabling remote access, site-to-site connectivity, and secure data transmission over public networks. +VPN services establish secure encrypted connections between on-premises networks and cloud resources, enabling remote access, site-to-site connectivity, and secure data transmission over public networks. Examples: @@ -65,4 +65,4 @@ Examples: - **AWS**: Amazon Route 53 - **Azure**: Azure DNS -- **Google Cloud**:Google Cloud DNS \ No newline at end of file +- **Google Cloud**:Google Cloud DNS diff --git a/services/networking/loadbalancer/taxonomy.md b/services/networking/loadbalancer/taxonomy.md index 27fcd373..fe3a3ba6 100644 --- a/services/networking/loadbalancer/taxonomy.md +++ b/services/networking/loadbalancer/taxonomy.md @@ -7,7 +7,7 @@ use in financial services ecosystems. ## Taxonomy | Taxonomy ID | Feature | Description | -|-------------|-------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| ----------- | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CCC-050303 | Layer 7 Load Balancing - HTTP/1.1 | Provide load balancer operation on the HTTP/1.1 protocol at the Application Layer (Layer 7) of the OSI model. These load balancers will intelligently distribute incoming traffic based on application-level information, such as HTTP headers, cookies, or URLs, to ensure efficient and scalable application delivery. | | CCC-050303 | Layer 7 Load Balancing - HTTPS/1.1 | Provide load balancer operation on the HTTPS/1.1 protocol at the Application Layer (Layer 7) of the OSI model. These load balancers will intelligently distribute incoming traffic based on application-level information, such as HTTP headers, cookies, or URLs, to ensure efficient and scalable application delivery. | | CCC-050303 | Layer 7 Load Balancing - HTTP/2 / gRPC | Provide load balancer operation on the HTTP/2 or gRPC protocol at the Application Layer (Layer 7) of the OSI model. These load balancers will intelligently distribute incoming traffic based on application-level information, such as HTTP headers, cookies, or URLs, to ensure efficient and scalable application delivery. | diff --git a/services/storage-services.md b/services/storage-services.md index a1b72b63..732b1ca9 100644 --- a/services/storage-services.md +++ b/services/storage-services.md @@ -1,9 +1,9 @@ - # Storage Services "Storage Services" in the context of cloud computing refer to the provision of storage resources over the internet that users can access and utilize remotely. These services allow users to store, retrieve, and manage their data in a scalable, reliable, and cost-effective manner. ## Types of Storage Services + - [Object Storage](#object-storage) - [Block Storage](#block-storage) - [File Storage](#file-storage) @@ -11,7 +11,7 @@ ### Object Storage -Object storage is a scalable storage solution that stores data as objects, each containing the data itself along with metadata and a unique identifier. +Object storage is a scalable storage solution that stores data as objects, each containing the data itself along with metadata and a unique identifier. Examples: diff --git a/services/storage/object/controls.md b/services/storage/object/controls.md index 1cf7977b..c051209b 100644 --- a/services/storage/object/controls.md +++ b/services/storage/object/controls.md @@ -138,3 +138,15 @@ The following validations must be performed against corresponding Control Implem 2. **CCC.OS.C5.TR.02** {#CCC.OS.C5.TR.02}: Ensure that all changes to the object storage bucket configurations are logged. 3. **CCC.OS.C5.TR.03** {#CCC.OS.C5.TR.03}: Confirm that logs are protected against unauthorized access and tampering. +======= +# Object Storage Controls + +This document contains an abstracted list of controls based on the Threats for Object Storage. The scope of these controls expand across various cloud service providers. + +## Controls + +| Control Id | Objective | Description | Test | Service Taxonomy Id | NIST CSF | MITRE ATT&CK Mitigations | Threats | +| ---------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | -------- | ---------------------------------------------------- | --------- | +| CCC.OS.C1 | Prevent unencrypted requests to object storage bucket | Block all unencrypted requests to the object storage bucket you own | GIVEN you own the object storage bucket; WHEN an unencrypted HTTP request is made to the bucket; THEN the request should be denied | CCC-020115 | Protect | [M1041](https://attack.mitre.org/mitigations/M1041) | CCC.OS.T1 | +| CCC.OS.C2 | Prevent object storage data encrypted for impact | Block data plane requests with untrusted KMS keys to the object storage bucket you own | GIVEN you own the object storage bucket; WHEN a data plane request with an untrusted KMS key is made to the object storage bucket; THEN the request should be denied | CCC-020114 | Protect | None | CCC.OS.T2 | +| CCC.OS.C3 | Prevent the granting of direct public access to the object storage bucket you own | Block the creation or update of buckets with public access | GIVEN you own the object storage bucket; WHEN the access controls on the bucket are updated to grant public access to the bucket; THEN the request should be denied | CCC-020116 | Protect | [M1022](https://attack.mitre.org/mitigations/M1022/) | CCC.OS.T3 | diff --git a/services/storage/object/taxonomy.md b/services/storage/object/taxonomy.md index 06517d24..7332c91a 100644 --- a/services/storage/object/taxonomy.md +++ b/services/storage/object/taxonomy.md @@ -6,24 +6,24 @@ use in financial services ecosystems. ## Taxonomy -| Taxonomy ID | Feature | Description | -| ----------- | ------- | ----------- | -| CCC-020101 | Buckets | Concept of having uniquely identifiable containers in which objects exist. | -| CCC-020102 | Metadata | Support storing, accessing, and managing of object metadata for stored objects. | -| CCC-020103 | Scalability - Capacity Limit | Ability to store unlimited number of objects under a given maximum total capacity per bucket. | -| CCC-020104 | Scalability - Object Size Limit | Ability to store large objects under a given maximum object size. | -| CCC-020105 | Durability | High durability for stored objects through redundancy and replication. | -| CCC-020106 | Availability | High availability for stored objects through replication over multiple (availability) zones within a region. | -| CCC-020107 | Performance - Transaction Rate Limits | High throughput and low latency for read/write operations under given maximum transaction rate limits. | -| CCC-020108 | Performance - Querying | Ability to perform simple select queries to retrieve only a subset of objects from the bucket. | -| CCC-020109 | Storage Classes | Having different storage classes for frequently and infrequently accessed objects. | -| CCC-020110 | Lifecycle Policies | Ability to define policies to automate data management tasks. | -| CCC-020111 | Versioning | Ability to keep multiple versions of an object in the same bucket. | -| CCC-020112 | Compliance and Governance | Ability to create locks on objects disabling modification and/or deletion of an object for a given period of time. | -| CCC-020113 | Event Notifications | Publish object level events for creation, deletion and modification of objects allowing users to trigger actions in response. | -| CCC-020114 | Encryption at Rest | Data should be encrypted before storing by default. Should also make the option available for clients to maintain control over the encryptin keys. | -| CCC-020115 | Encryption in Transit | Ability to encrypt data in transit using SSL/TSL. | -| CCC-020116 | Identity Based Access Control | Ability to limit the users/roles who can access the object store. | -| CCC-020117 | Object Level Access Control | Ability to control access to specific objects on the object store. | -| CCC-020118 | Logging | Ability to log access, allowing the clients to track requests made to the object store. | -| CCC-020119 | Signed URLs | Ability to give temporary access to objects and buckets through a signed URL or signed access token. | +| Taxonomy ID | Feature | Description | +| ----------- | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | +| CCC-020101 | Buckets | Concept of having uniquely identifiable containers in which objects exist. | +| CCC-020102 | Metadata | Support storing, accessing, and managing of object metadata for stored objects. | +| CCC-020103 | Scalability - Capacity Limit | Ability to store unlimited number of objects under a given maximum total capacity per bucket. | +| CCC-020104 | Scalability - Object Size Limit | Ability to store large objects under a given maximum object size. | +| CCC-020105 | Durability | High durability for stored objects through redundancy and replication. | +| CCC-020106 | Availability | High availability for stored objects through replication over multiple (availability) zones within a region. | +| CCC-020107 | Performance - Transaction Rate Limits | High throughput and low latency for read/write operations under given maximum transaction rate limits. | +| CCC-020108 | Performance - Querying | Ability to perform simple select queries to retrieve only a subset of objects from the bucket. | +| CCC-020109 | Storage Classes | Having different storage classes for frequently and infrequently accessed objects. | +| CCC-020110 | Lifecycle Policies | Ability to define policies to automate data management tasks. | +| CCC-020111 | Versioning | Ability to keep multiple versions of an object in the same bucket. | +| CCC-020112 | Compliance and Governance | Ability to create locks on objects disabling modification and/or deletion of an object for a given period of time. | +| CCC-020113 | Event Notifications | Publish object level events for creation, deletion and modification of objects allowing users to trigger actions in response. | +| CCC-020114 | Encryption at Rest | Data should be encrypted before storing by default. Should also make the option available for clients to maintain control over the encryptin keys. | +| CCC-020115 | Encryption in Transit | Ability to encrypt data in transit using SSL/TSL. | +| CCC-020116 | Identity Based Access Control | Ability to limit the users/roles who can access the object store. | +| CCC-020117 | Object Level Access Control | Ability to control access to specific objects on the object store. | +| CCC-020118 | Logging | Ability to log access, allowing the clients to track requests made to the object store. | +| CCC-020119 | Signed URLs | Ability to give temporary access to objects and buckets through a signed URL or signed access token. | diff --git a/services/storage/object/threats.md b/services/storage/object/threats.md index b9c798c0..e4e51e8f 100644 --- a/services/storage/object/threats.md +++ b/services/storage/object/threats.md @@ -1,5 +1,11 @@ -| Threat Id | Name | Description | Service Taxonomy Id | MITRE ATT&CK TTPs | -|-----------|------|-------------|---------------------|-------------------| -| CCC.OS.T1 | Attacker intercepts data in transit to a bucket | The object storage service allows communication over HTTP. An attacker can intercept the traffic you send to bucket, in order to read or modify the data. | CCC-020115 | [TA009](https://attack.mitre.org/tactics/TA0009/) [T1557](https://attack.mitre.org/techniques/T1557/) | -| CCC.OS.T2 | Attacker encrypts objects for ransomware | The object storage service provides several types of encryption where the key is not operated by the CSP. An attacker can encrypt all the data stored in the bucket to ransom the data owner to get the decryption key. Alternatively, an attacker can change the default encryption key, for a similar effect on any new data uploaded. | CCC-020114 | [TA0040](https://attack.mitre.org/tactics/TA0040/) [T1486](https://attack.mitre.org/techniques/T1486/) -| CCC.OS.T3 | Attacker grants bucket access to untrusted principals | The bucket access controls (e.g. ACLs, bucket policies) can enable access to objects owned by the bucket. An attacker (or someone by negligence) can change (i.e., impair) the bucket access controls and make the content accessible to untrusted principals (via public endpoints, cross-account VPC endpoints, or cross-account access point). | CCC-020116 | [TA0005](https://attack.mitre.org/tactics/TA0005/) [T1562](https://attack.mitre.org/techniques/T1562/) | +# Object Storage Threats Catalog + +This service-level threats documents the most common list of threats that impacts Object Storage. The scope of these threats expand across various cloud service providers. + +## Threats + +| Threat Id | Name | Description | Service Taxonomy Id | MITRE ATT&CK TTPs | +| --------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------ | +| CCC.OS.T1 | Attacker intercepts data in transit to a bucket | The object storage service allows communication over HTTP. An attacker can intercept the traffic you send to bucket, in order to read or modify the data. | CCC-020115 | [TA009](https://attack.mitre.org/tactics/TA0009/) [T1557](https://attack.mitre.org/techniques/T1557/) | +| CCC.OS.T2 | Attacker encrypts objects for ransomware | The object storage service provides several types of encryption where the key is not operated by the CSP. An attacker can encrypt all the data stored in the bucket to ransom the data owner to get the decryption key. Alternatively, an attacker can change the default encryption key, for a similar effect on any new data uploaded. | CCC-020114 | [TA0040](https://attack.mitre.org/tactics/TA0040/) [T1486](https://attack.mitre.org/techniques/T1486/) | +| CCC.OS.T3 | Attacker grants bucket access to untrusted principals | The bucket access controls (e.g. ACLs, bucket policies) can enable access to objects owned by the bucket. An attacker (or someone by negligence) can change (i.e., impair) the bucket access controls and make the content accessible to untrusted principals (via public endpoints, cross-account VPC endpoints, or cross-account access point). | CCC-020116 | [TA0005](https://attack.mitre.org/tactics/TA0005/) [T1562](https://attack.mitre.org/techniques/T1562/) |