diff --git a/.github/ISSUE_TEMPLATE/account_management_request_form.yaml b/.github/ISSUE_TEMPLATE/account_management_request_form.yaml index 2c4ebfd..bae6ce9 100644 --- a/.github/ISSUE_TEMPLATE/account_management_request_form.yaml +++ b/.github/ISSUE_TEMPLATE/account_management_request_form.yaml @@ -3,19 +3,33 @@ description: Submit an account related request labels: ['ACCOUNT_REQUEST_RECORD'] body: - type: input - id: first-name + id: user-first-name attributes: label: Account Holder First Name placeholder: Type here user's first name as it appears in his/her ID. validations: required: true - type: input - id: last-name + id: user-last-name attributes: label: Account Holder Last Name placeholder: Type here user's last name as it appears in his/her ID. validations: required: true + - type: input + id: user-email + attributes: + label: Account Holder Email + placeholder: Type here user's email + validations: + required: true + - type: input + id: user-username + attributes: + label: Account Holder Username + placeholder: Type here user's username + validations: + required: true - type: input id: requester-name attributes: diff --git a/.github/workflows/account_request_approve.yaml b/.github/workflows/account_request_approve.yaml index ddbafb4..5714bb0 100644 --- a/.github/workflows/account_request_approve.yaml +++ b/.github/workflows/account_request_approve.yaml @@ -21,6 +21,82 @@ jobs: NUMBER: ${{ github.event.issue.number }} BODY: > Account management request APPROVED by Blossom Management. - @usnistgov/blossom-sysdevs please implement by updating the ACL and the SSP. + @usnistgov/blossom-sysdevs please ensure the ACL and/or Cognito are updated and the SSP is in sync with the update. When implemented, add the ACCOUNT_IMPLEMENTED label and - link this account request issue to the PR with the implementation. \ No newline at end of file + link this account request issue to the PR with the implementation. + + parse-issue: + needs: request-approved + runs-on: ubuntu-20.04 + outputs: + account-modification: ${{ steps.issue-parser.outputs.issueparser_account-modification }} + user-first-name: ${{ steps.issue-parser.outputs.issueparser_user-first-name }} + user-last-name: ${{ steps.issue-parser.outputs.issueparser_user-last-name }} + user-username: ${{ steps.issue-parser.outputs.issueparser_user-username }} + user-email: ${{ steps.issue-parser.outputs.issueparser_user-email }} + account-type: ${{ steps.issue-parser.outputs.issueparser_account-type }} + steps: + - name: Checkout repo + uses: actions/checkout@v4 + with: + sparse-checkout: | + .github/ISSUE_TEMPLATE/account_management_request_form.yaml + sparse-checkout-cone-mode: false + + - name: Parse issue body + uses: stefanbuck/github-issue-parser@v3.2.1 + id: issue-parser + with: + template-path: ".github/ISSUE_TEMPLATE/account_management_request_form.yaml" + + create-user: + needs: parse-issue + if: ${{ needs.parse-issue.outputs.account-modification == 'Create' }} + runs-on: ubuntu-20.04 + steps: + - name: Checkout repo + uses: actions/checkout@v4 + + - name: Ensure directory exists for created users + run: | + mkdir -p ato/oscal-artifacts/created_users/ + + - name: Ensure directory exists for created users references + run: | + mkdir -p ato/oscal-artifacts/reference_created_users/ + + - name: Create yaml file for automated user creation + env: + USER_NAME: "${{ needs.parse-issue.outputs.user-first-name }} ${{ needs.parse-issue.outputs.user-last-name }}" + USER_USERNAME: ${{ needs.parse-issue.outputs.user-username }} + USER_EMAIL: ${{ needs.parse-issue.outputs.user-email }} + USER_ROLE: ${{ needs.parse-issue.outputs.account-type }} + ISSUE_NUMBER: ${{ github.event.issue.number }} + run: | + python ato/secops/create_user.py --user-name "$USER_NAME" --user-username "$USER_USERNAME" --user-email "$USER_EMAIL" --user-role "$USER_ROLE" --issue-number "$ISSUE_NUMBER" + + - name: Store user yaml in repo + run: | + git config --global user.name "create-user-action[bot]" + git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com" + git checkout -b "$BRANCH_NAME" + git add "ato/oscal-artifacts/created_users/*" + git add "ato/oscal-artifacts/reference_created_users/*" + git commit -m "Create user request #$ISSUE_NUMBER" + git push origin "$BRANCH_NAME" + env: + ISSUE_NUMBER: ${{ github.event.issue.number }} + BRANCH_NAME: "account-request-${{ github.event.issue.number }}" + + - name: Configure AWS CLI + uses: aws-actions/configure-aws-credentials@v4 + with: + aws-region: ${{ secrets.AWS_REGION }} + aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }} + aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }} + + - name: Copy reference yaml to bucket + run: | + aws s3 cp --recursive ato/oscal-artifacts/reference_created_users/ s3://"$AWS_BUCKET" + env: + AWS_BUCKET: ${{ secrets.AWS_BUCKET }} diff --git a/.github/workflows/account_request_assessment.yaml b/.github/workflows/account_request_assessment.yaml index de52e40..2384b60 100644 --- a/.github/workflows/account_request_assessment.yaml +++ b/.github/workflows/account_request_assessment.yaml @@ -12,10 +12,9 @@ jobs: if_merged: if: github.event.pull_request.merged == true runs-on: ubuntu-20.04 - permissions: - issues: write +# permissions: +# issues: write steps: - name: Run automated assessment run: echo "assessment" - # 1. dump empty file to s3 bucket, to initiate connection - # 2. query chaincode, code to execute on chaincode for list of supported roles, API command + # query chaincode, code to execute on chaincode for list of supported roles, API command diff --git a/account_workflow.md b/.github/workflows/account_workflow.md similarity index 53% rename from account_workflow.md rename to .github/workflows/account_workflow.md index df4dfa6..a664e6d 100644 --- a/account_workflow.md +++ b/.github/workflows/account_workflow.md @@ -2,13 +2,20 @@ This document explains the workflow of GitHub actions used to automate Blossom service's accounts management. +## Requirements to run Actions +- [ ] Repository secrets: AWS_ACCESS_KEY, AWS_SECRET_KEY, AWS_REGION, AWS_BUCKET +- [ ] Issue labels: ACCOUNT_REQUEST_RECORD, ACCOUNT_APPROVED, ACCOUNT_REJECTED, ACCOUNT_IMPLEMENTED + ## Account Request and Creation - [ ] The requester requests an account for the Account Holder by creating a new GitHub issue using the Account Request Form. - [ ] The Blossom Management group is automatically notified to review the request through GitHub. - [ ] One of the Blossom Management (a member of the Blossom Management group) reviews the request and adds a new label to the issue: ACCOUNT_APPROVED or ACCOUNT_REJECTED - [ ] If ACCOUNT_REJECTED, the account request issue is automatically closed. -- [ ] If the account is approved and the label ACCOUNT_APPROVED is added, the Blossom Sysdevs group is automatically notified to implement the account. -- [ ] Upon completion of creating the account requested, the Blossom Sysdev links the Account Request issue to the Pull Request that implements the account. +- [ ] If the account is approved and the label ACCOUNT_APPROVED is added, the Blossom Sysdevs group is automatically notified about implementation. +- [ ] A YAML file is automatically created from information submitted through the Account Request Form, which is pushed to the GitHub repo as a new branch and a condensed version is sent to S3 bucket. +- [ ] S3 bucket receives the file about the new user to create and sends a trigger to EC2, which implements the new user in Cognito, SSM, ACL, AMB as necessary. +- [ ] The new user is inserted into the SSP, which is pushed into the GitHub repo to the new branch. +- [ ] Upon completion of creating the account requested, a Pull Request is automatically created, to link the branch with the Account Request issue. - [ ] Upon merging the Pull Request that implements the account, the relevant updated controls are re-assessed automatically. The Blossom Assessors group is then notified to monitor the automated assessment. - [ ] TBD: STEPS FOR AUTOMATED ASSESSMENT diff --git a/.sims/handshake/handshake_empty b/.sims/handshake/handshake_empty new file mode 100644 index 0000000..e69de29 diff --git a/ato/secops/create_user.py b/ato/secops/create_user.py new file mode 100644 index 0000000..32891df --- /dev/null +++ b/ato/secops/create_user.py @@ -0,0 +1,61 @@ +import click +import yaml +from datetime import datetime + +@click.command() +@click.option('--user-name', required=True, help='Name of user to create') +@click.option('--user-username', required=True, help='Name of user to create') +@click.option('--user-email', required=True, help='Email of user to create') +@click.option('--user-role', required=True, help='Role of user to create') +@click.option('--location-uuid', help='UUID of physical location of user') +@click.option('--org-member', help='UUID of organization that user is member of') +@click.option('--issue-number', help='Issue number of user account request') +def create_user(user_name, user_username, user_email, user_role, location_uuid, org_member, issue_number): + """ + Creates a yaml file containing information about a new user + + Args: + user_name (string): String containing name of new user + user_username (string): String containing username of new user + user_email (string): String containing email of new user + user_role (string): String containing role of new user + location_uuid (string): String containing UUID of physical location of user + org_member (string): String containing UUID of organization that user is member of + issue_number (string): String containing issue number of user account request + """ + + # Structure of yaml file + cmd = { + "command" : "create-acl-user|create-cognito-user", + "user" : { + "name" : f"{user_name}", + "username" : f"{user_username}", + "email-address":f"{user_email}", + "role":f"{user_role}", + "location-uuid":f"{location_uuid}", + "member-of-organization":f"{org_member}", + }, + } + + # Include timestamp in filename + timestamp = datetime.now().strftime("%Y%m%d-%H%M%S") + + # Write to user yaml file (stored in repo) + filename = "ato/oscal-artifacts/created_users/created_user_" + timestamp + ".yaml" + with open(filename, 'w') as f: + print(f"\n\n{yaml.safe_dump(cmd, default_flow_style=False)}", file=f) + + # Structure of yaml file referencing user yaml file + reference = { + "file": f"{filename}", + "issue_number": f"{issue_number}", + "branch_name": f"account-request-{issue_number}" + } + + # Write to user reference yaml file (sent to S3) + filename_reference = "ato/oscal-artifacts/reference_created_users/reference_created_user_" + timestamp + ".yaml" + with open(filename_reference, 'w') as f: + print(f"\n\n{yaml.safe_dump(reference, default_flow_style=False)}", file=f) + +if __name__ == '__main__': + create_user() \ No newline at end of file diff --git a/oscal-content/xml/ssp/blossom_admin_member_ssp.xml b/oscal-content/xml/ssp/blossom_admin_member_ssp.xml index d0a25ca..cf331b4 100644 --- a/oscal-content/xml/ssp/blossom_admin_member_ssp.xml +++ b/oscal-content/xml/ssp/blossom_admin_member_ssp.xml @@ -1,1236 +1,1236 @@ - - - - BloSS@M System Security Plan - 2022-04-05T00:00:00Z - 2024-03-27T00:00:00Z - 0.1 - 1.1.2 - - - System Owner (SO) - -

The individual within the organization who is ultimately accountable for - everything related to the deployment, assessemnt, authorization and operations - of the Blossom Member which provides the software assets leasing service (here - in known as "this system").

- - - - System Administrator (SA) - -

The individual accountable for the deployment, configuration, testing and - operations of the system on behalf of the System Owner.

- - - - System Security Assessor (SSA) - -

The individual accountable for assessing the security posture of the system on - behalf of the system owner.

- - - - Authorizing Official - -

The individual or individuals who are ultimatly accountable for reviewing the - assessemnt package, discuss with the SO the findings and grant an authorization - to operate (ATO) to Blosom, a.ka "this system".

-

The Authorizing Official is the only entity responsible for the security posture - of the system and has access to the ATO channel (chaincode) to upload the ATO Attestation Memo (AAM). - The AO signs the AAM on behalf of the agency.

- - - - - Technical Point of Contact (TPOC) - -

The individual accountable for managing leased licenses (checkout, install, - uninstall, return).

- - - - License Owner (LO) - -

The individual within the service provider organization who is accountable for - managing the pool of software resources made available for leasing to USG - agencies.

-

The License Owner role exists only within the service provider agency.

- - - - Acquisition Officer - -

The individual within the Agency which is responsible for approving and - processing the payment of the leased pool of software licenses.

- - - - National Institute of Standards and Technology -
- 100 Bureau Drive - Gaithersburg - MD - 20899 -
- -

NIST ITL Computer Security Division's Secure Systems and Applications Group is - the primary CSP for this project.

- - - - AWS US East/West -
- 13200 Woodland Park Rd - Herndon - VA - 20171 -
- - -

This title must be kept as-is to match FedRAMP Marketplace listing. This is a a - FedRAMP requirement. This official mailing address of Amazon's AWS commercial - offering for the us-east-1 is provided, as Amazon not disclose the address of - data-centers either on a region or availability zone basis.

- - - - National Institute of Standards and Technology IT Lab Computer Security Division Secure Systems and Applications Group - NIST - - 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 - -

Blossom network provider.

- - - - Stan Owens - - - - blossom@nist.gov - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - ManoGiana Bloom - - blossom@nist.gov - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - Simmon Admino - - - - blossom@nist.gov - 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - Steve S. Asesoro - - - - blossom@nist.gov - 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - - Aurelian Officeman - - - - blossom@nist.gov - 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - Licenta Owens - - - - blossom@nist.gov - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - Acquia Officiale - - - - blossom@nist.gov - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - Tom Pock - - - - blossom@nist.gov - 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 - 8aed7ffd-5158-445d-8d7c-eec5cf240cba - - - - - 09ad840f-aa79-43aa-9f22-25182c2ab11b - 551b9706-d6a4-4d25-8207-f2ccec541016 - - - 4fded5fd-7a65-47ea-bd76-df57c46e27d1 - -

This party has development, deployment, configuration and operations - responsibilities for "this system" supporting the system owner.

- - - - - 132953a9-640c-46f7-9de9-3fa15ec99361 - -

The party responsible to assess the security controls on behalf of the system - owner.

- - - - - - 51588d7c-aa79-43aa-9f22-25182c2cd22d - -

The license owner is responsible for managing the licenses a Blossom Member leases, and is also responsible for uploading to the asset chaincode the MOA signed by the TPOC and Acquisition Officer.

- - - - - c46e27d1-7a65-47ea-bd76-df574fded5fd - -

Interfaces with the other agencies and need only read access to the ledger to review the assets (licenses) processed.

-

The TPOC is also responsible for reviewing and signing the initial Memorandum of Aggrement (MOA) stating the rules on engagemnet whith Blossom service around ATO automation and assets leasing.

- - - - c46e27d1-7a65-47ea-bd76-df574fded5fd - -

Interfaces with the other agencies and need only read access to the ledger to review the assets (licenses) processed.

- - - - - - 3360e343-9860-4bda-9dfc-ff427c3dfab6 - - -

This SSP was created using a simplified version of OSCAL-based FedRAMP SSP Template - for the FedRAMP Low, Moderate, and High baselines.

- - - - -

This example points to the tailored FedRAMP Moderate 800-53 rev 5 baseline, adjusted - accordingly for BloSS@M.

- - - - 8101e04d-8305-4e73-bb95-6b59f645b143 - Blockchain-based Secure Software Assets Management - Blossom - -

TBD: Describe the purpose and functions of this system here.

- - - - - - - fips-199-moderate - - - - - - - - Blockchain-based Software Assets Management - -

BloSS@M stores the minimally required identity and authorization metadata to - authenitcate and authorize federal users of the system.

- - - C.2.8.12 - - - fips-199-low - fips-199-moderate - - - fips-199-low - fips-199-moderate - -

The NIST Privacy Office and Office of Information Systems Management - categorizes personal identity and authentication information with as - FIPS-199 Low impact for integrity concerns. - This categorization is limited to federal employees when this data is - for identification of these federal employees only.

- - - - fips-199-low - fips-199-low - - - - Inventory control information - -

TBD

- - - C.3.4.2 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - - Logistics management information - -

TBD

- - - C.3.4.3 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - - Services acquisition information - -

TBD

- - - C.3.4.4 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - - Lifecycle and change management information - -

TBD

- - - C.3.5.2 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-moderate - - - fips-199-moderate - fips-199-low - - - - Information security information - -

TBD

- - - C.3.5.5 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-moderate - - - fips-199-moderate - fips-199-low - - - - Record retention information - -

TBD

- - - C.3.5.6 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - - Information management information - -

TBD:

- - - C.3.5.7 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-moderate - - - fips-199-moderate - fips-199-low - - - - Information sharing information - -

TBD

- - - C.3.5.9 - - - fips-199-moderate - fips-199-moderate - -

This information has no base recommendation in SP 800-60 Volume 2 - Revision 1 guidance. - The Office of Information Systems Management's consulted the BloSS@M - Team and the NIST system owner, who categorized this information sharing - at FIPS-199 Moderate impact.

- - - - fips-199-moderate - fips-199-moderate - -

This information has no base recommendation in SP 800-60 Volume 2 - Revision 1 guidance. - The Office of Information Systems Management's consulted the BloSS@M - Team and the NIST system owner, who categorized this information sharing - at FIPS-199 Moderate impact.

- - - - fips-199-moderate - fips-199-moderate - -

This information has no base recommendation in SP 800-60 Volume 2 - Revision 1 guidance. - The Office of Information Systems Management's consulted the BloSS@M - Team and the NIST system owner, who categorized this information sharing - at FIPS-199 Moderate impact.

- - - - - Scientific and technological research and innovation information - -

TBD

- - - D.19.1 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-moderate - - - fips-199-moderate - fips-199-low - - - - Research and development information - -

TBD

- - - D.20.1 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-moderate - - - fips-199-moderate - fips-199-moderate - - - - Research and development information - -

TBD

- - - D.20.4 - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - fips-199-moderate - fips-199-low - - - - - fips-199-moderate - fips-199-moderate - fips-199-low - - - - -

TBD: A holistic, top-level explanation of the system's authorization boundary.

- - - -

A diagram-specific explanation.

- - - Authorization Boundary Diagram - - - - -

A holistic, top-level explanation of the network architecture.

- - - -

A diagram-specific explanation.

- - - Network Diagram - - - - -

A holistic, top-level explanation of the system's data flows.

- - - -

A diagram-specific explanation.

- - - Data Flow Diagram - - - - - - AWS Managed Blockchain (AMB) - - - e63e870d-bf43-40dc-98a0-37d5e39b2dd1 - 2024-01-01 - -

TBD: ssp-uuid: 73a7ca56-ac02-43b9-8664-62bcb05a7e91 will need to be added for - oscal 1.2.0.

-

The leveraged authorization assembly is supposed to have a required uuid flag - instead of an optional id flag. This will be fixed in the syntax shortly.

-

Use one leveraged-authorization assembly for each underlying system. (In the - legacy world, these may be general support systems.

-

The link fields are optional, but preferred where known. Often, a leveraging - system's SSP author will not have access to the leveraged system's SSP, but - should have access to the leveraged system's CRM.

- - - - System Administrator - - - - system-administrator - - Full administrative access rights - add and remove users, software-name and hardware - install and configure deployments - system updates, patches and hotfixes - perform backups - - - - System Owner - - - - system-owner - - Privileged access rights - add and remove users, software-name and hardware - install and configure deployments - system updates, patches and hotfixes - perform backups - - - - System Security Assessor - - - - sys-sec-assessor - - Non-privileged access rights (read only) - review system documentation and security configurations - review if system updates, patches and hotfixes are documented and successfully completed - review disaster recovery procedures and system backups existance - - - - This System - -

The entire Blossom system as depicted in the system authorization boundary

- - - - - AWS Managed Blockchain (AMB) - Leveraged System - -

TBD: If the leveraged system owner provides a UUID for their system (such as in - an OSCAL-based CRM), it should be reflected in the inherited-uuid - property.

- - - - - - - - - -

TBD: Description of Blossom inventory items 1

- - - - - - - - - - - - -

This is a palceholder for the FedRAMP SSP Template Section 13

-

This description field is required by OSCAL.

-

FedRAMP does not require any specific information here.

- - - - - - - - - -

Per the documentation available in the Blossom Wiki, the AWS Managed - Blockchain (AMB) provides access control to the infrastracture for the - entities identified below which require access to IaaS to maintain and - deploy system components. The blockchain's chaincode is implementing Next - Generation Access Control (NGAC) standard to manage the access to resources - for the roles docuemnted in the Blossom specification. Access control policy - machines are implemented for the two private channels of the AMB: the ATO or - "Authorization" channel and the "Businness" channel.

- - - - -

The policy machines are controling the access to the two chaincodes - (Authorization and Business) used by the system.

- - - - - - - have an organization-sponsored email address to demonstrate employment,complete training, and have been approved by the System Owner based on the business need of the individual - - - Access tagging - - - Accounts Manager(s): System Owner and Program Manager. - - - Organizational access control policies, standards and procedures, as documented in the AC-02.a statement implementation (statement-id="ac-2_smt.a", uuid="24a85abb-25ad-4686-850c-5c0e8ab69a0c"). - - - - System Administrator - - - 1 business day - - - within one hour - - - within openxmlformats-officedocument hours - - - - need to know - - - every 6 months or when a change takes place - - - 4fded5fd-7a65-47ea-bd76-df57c46e27d1 - - - 09ad840f-aa79-43aa-9f22-25182c2ab11b - - - - -

For the IAM entities that have a business need, and which have accounts created in Cognito, the Policy machines which implement NGAC in the two chaincodes are managing the access control for the Blossom business layer users and the BC Member's Authorizing Official that is uploading the ATO Attestation to the Authorization channel.

- - - -

The Blossom system's System Owner and System Administrator are repsonsible for approving, creating and managing accounts and grant or denie access to the system by maintaining accurate information in Cognito and updating the access control policies access control lists (ACLs).

- - - - - -

AWS manages the access to approved entities to the system's infrastructure, for deployment, maintenance, and operations.

- - - -

Keep the ACL list current at all times.

- - - - - - - -

The system has privileged and non-privileged accounts associated with the business layer and the ATO processes.

-

These accounts are managed by the NGAC implementation in the chaincodes for the ATO and for the assets management (business) processes.

-

The following accounts are supported for the business operations (assets management):

-
    -
  • Privileged accounts: -
      License Owner
    -
    • -
  • Non-Privileged accounts: -
      Acquisition Officer
    -
      Technical Point of Contact
    -
    • -
-

The Authorizing Official is responsible for reviewing the ATO package prepared by the System Owner and signing/authorizing the system to operate.

-

The System Owner remains the custodian of all system ATO related artifacts.

-

Upon approval, the Authorizing official is responsible for automatically generating the ATO attestation and uploading it to the ATO channel.

-

The following account is supported for the ATO processes.

-
    -
  • Privileged accounts: -
      Authorizing Official
    -
    • -
- - - - - -

The following accounts of the NIST Member of the Blossom System are managed by the Leveraged AWS IaaS:

-
    -
  • Privileged accounts: -
      System Owner
    -
      System Administrator
    -
    • -
  • Non-Privileged accounts: -
      System Security Assessor
    - -
    • -
- - - -

TBD: provided-uuid needs to match the one in the AWS' SSP.

-

All privileged and non-privileged accounts that are granted access to - the AWS infrastructure and are responsible for the Blossom System deployment and maintenance - (this system), are managed by the AWS IaaS (leveraged ATO system) - which uses an Access Control List (ACL) for the NIST employees - assigned Blossom roles.

- - - - -

The Access Control List (ACL) updates are Blossom system's responsibility (as customers of AWS) - For all roles listed above which are managed by the AWS IaaS - system, account creation/revokation/deletion requests are approved - by the Blossom system's System Owner or the Program Manager and are added to or delete - from the ACL list by the System Administrator.

- - - - - - - -

For this system, the entity with the System Administrator role - acts as the Accounts Manager and is responsible for creating, - revoking, deleting accounts per decisions made by the System Owner and the Program Manager.

- - - - - - - -

For each identified role, access to the system for each role will be individually - analyzed and granted if the requesters proves they - for the respective group and role membership.

- - - - - - -

1. All authorized users are listed and accuratelly maintained in this SSP in the "metadata", as "party" elements of type="person".

-

2. All roles supported by the Blossom system are documented in this SSP in the "metadata", as "role" elements with "id" identifying the role. - This system does not support groups.

-

3. All access authorizations are documented in this SSP in the "metadata" as "responsible-party" with "role-id" mathing the respective roles or attributes.

- - - - - - -

Authorized Blossom users are documented in the Blossom SSP.

- - - - - - -

Group and role membership

- - - - - - -

Access authorizations (i.e., privileges) and [Assignment: organization-defined attributes - (as required)] for each account;

- - - - - - -

Request to create accounts are approved by the System Owner and the Program Manager;

- - - - - - -

Blossom user accounts are created, enabled, modified, disabled, and removed according to the types of Blossom accounts (privileged or non-privileged);

- - - - - - -

Monitor the use of accounts;

- - - - - - -

Account managers, System Owner, and Program Manager are notified within:

- - - - - - -

Account managers, System Owner, and Program Manager are notified within1 business day when accounts are no longer required;

- - - - - - -

within 1 business day when users are terminated or - transferred;

- - - - - - -

within 1 business day when system usage or need-to-know - changes for an individual;

- - - - - - -

System access authorization is based on:

- - - - - - -

A valid access authorization;

- - - - - - -

Intended system usage;

- - - - - - -

Business need of the individual;

- - - - - - -

Accounts are reviewed for compliance with account management requirements every 6 months.;

- - - - - - -

There are no group or shared accounts created for accessing Blossom;

- - - - - - -

All Blossom user accounts are updated by the system administrator when they are terminated or are transferred where their Blossom account is not required.

- - - - - - - - -

Blossom Wiki

- - - -

Project's Wiki which provides descriptions for the ATO and business processes.

- - - - -

National Institute of Standards and Technology's Logo

- - - 00000000 - -

May use rlink with a relative path, or embedded as base64 - .

-

FedRAMP prefers base64 for images and diagrams.

-

Images must be in sufficient resolution to read all detail when rendered in a - browser via HTML5.

- - - - -

The primary authorization boundary diagram.

- - - 00000000 - -

Section 9.2, Figure 9-1 Authorization Boundary Diagram (graphic)

-

This should be referenced in the - system-characteristics/authorization-boundary/diagram/link/@href flag using a - value of "#d2eb3c18-6754-4e3a-a933-03d289e3fad5"

-

May use rlink with a relative path, or embedded as base64 - .

-

FedRAMP prefers base64 for images and diagrams.

-

Images must be in sufficient resolution to read all detail when rendered in a - browser via HTML5.

- - - - -

The primary network diagram.

- - - 00000000 - -

Section 9.4, Figure 9-2 Network Diagram (graphic)

-

This should be referenced in the - system-characteristics/network-architecture/diagram/link/@href flag using a - value of "#61081e81-850b-43c1-bf43-1ecbddcb9e7f"

-

May use rlink with a relative path, or embedded as base64 - .

-

FedRAMP prefers base64 for images and diagrams.

-

Images must be in sufficient resolution to read all detail when rendered in a - browser via HTML5.

- - - - Privacy Impact Assessment - - - - - - 00000000 - -

Table 15-1 Attachments: Privacy Impact Assessment

-

May use rlink with a relative path, or embedded as base64 - .

- - - + + + + BloSS@M System Security Plan + 2022-04-05T00:00:00Z + 2024-03-27T00:00:00Z + 0.1 + 1.1.2 + + + System Owner (SO) + +

The individual within the organization who is ultimately accountable for + everything related to the deployment, assessemnt, authorization and operations + of the Blossom Member which provides the software assets leasing service (here + in known as "this system").

+ + + + System Administrator (SA) + +

The individual accountable for the deployment, configuration, testing and + operations of the system on behalf of the System Owner.

+ + + + System Security Assessor (SSA) + +

The individual accountable for assessing the security posture of the system on + behalf of the system owner.

+ + + + Authorizing Official + +

The individual or individuals who are ultimatly accountable for reviewing the + assessemnt package, discuss with the SO the findings and grant an authorization + to operate (ATO) to Blosom, a.ka "this system".

+

The Authorizing Official is the only entity responsible for the security posture + of the system and has access to the ATO channel (chaincode) to upload the ATO Attestation Memo (AAM). + The AO signs the AAM on behalf of the agency.

+ + + + + Technical Point of Contact (TPOC) + +

The individual accountable for managing leased licenses (checkout, install, + uninstall, return).

+ + + + License Owner (LO) + +

The individual within the service provider organization who is accountable for + managing the pool of software resources made available for leasing to USG + agencies.

+

The License Owner role exists only within the service provider agency.

+ + + + Acquisition Officer + +

The individual within the Agency which is responsible for approving and + processing the payment of the leased pool of software licenses.

+ + + + National Institute of Standards and Technology +
+ 100 Bureau Drive + Gaithersburg + MD + 20899 +
+ +

NIST ITL Computer Security Division's Secure Systems and Applications Group is + the primary CSP for this project.

+ + + + AWS US East/West +
+ 13200 Woodland Park Rd + Herndon + VA + 20171 +
+ + +

This title must be kept as-is to match FedRAMP Marketplace listing. This is a a + FedRAMP requirement. This official mailing address of Amazon's AWS commercial + offering for the us-east-1 is provided, as Amazon not disclose the address of + data-centers either on a region or availability zone basis.

+ + + + National Institute of Standards and Technology IT Lab Computer Security Division Secure Systems and Applications Group + NIST + + 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 + +

Blossom network provider.

+ + + + Stan Owens + + + + blossom@nist.gov + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + ManoGiana Bloom + + blossom@nist.gov + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + Simmon Admino + + + + blossom@nist.gov + 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + Steve S. Asesoro + + + + blossom@nist.gov + 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + + Aurelian Officeman + + + + blossom@nist.gov + 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + Licenta Owens + + + + blossom@nist.gov + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + Acquia Officiale + + + + blossom@nist.gov + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + Tom Pock + + + + blossom@nist.gov + 1ef39fd9-d184-44c4-8ef4-36d2dbad70a2 + 8aed7ffd-5158-445d-8d7c-eec5cf240cba + + + + + 09ad840f-aa79-43aa-9f22-25182c2ab11b + 551b9706-d6a4-4d25-8207-f2ccec541016 + + + 4fded5fd-7a65-47ea-bd76-df57c46e27d1 + +

This party has development, deployment, configuration and operations + responsibilities for "this system" supporting the system owner.

+ + + + + 132953a9-640c-46f7-9de9-3fa15ec99361 + +

The party responsible to assess the security controls on behalf of the system + owner.

+ + + + + + 51588d7c-aa79-43aa-9f22-25182c2cd22d + +

The license owner is responsible for managing the licenses a Blossom Member leases, and is also responsible for uploading to the asset chaincode the MOA signed by the TPOC and Acquisition Officer.

+ + + + + c46e27d1-7a65-47ea-bd76-df574fded5fd + +

Interfaces with the other agencies and need only read access to the ledger to review the assets (licenses) processed.

+

The TPOC is also responsible for reviewing and signing the initial Memorandum of Aggrement (MOA) stating the rules on engagemnet whith Blossom service around ATO automation and assets leasing.

+ + + + c46e27d1-7a65-47ea-bd76-df574fded5fd + +

Interfaces with the other agencies and need only read access to the ledger to review the assets (licenses) processed.

+ + + + + + 3360e343-9860-4bda-9dfc-ff427c3dfab6 + + +

This SSP was created using a simplified version of OSCAL-based FedRAMP SSP Template + for the FedRAMP Low, Moderate, and High baselines.

+ + + + +

This example points to the tailored FedRAMP Moderate 800-53 rev 5 baseline, adjusted + accordingly for BloSS@M.

+ + + + 8101e04d-8305-4e73-bb95-6b59f645b143 + Blockchain-based Secure Software Assets Management + Blossom + +

TBD: Describe the purpose and functions of this system here.

+ + + + + + + fips-199-moderate + + + + + + + + Blockchain-based Software Assets Management + +

BloSS@M stores the minimally required identity and authorization metadata to + authenitcate and authorize federal users of the system.

+ + + C.2.8.12 + + + fips-199-low + fips-199-moderate + + + fips-199-low + fips-199-moderate + +

The NIST Privacy Office and Office of Information Systems Management + categorizes personal identity and authentication information with as + FIPS-199 Low impact for integrity concerns. + This categorization is limited to federal employees when this data is + for identification of these federal employees only.

+ + + + fips-199-low + fips-199-low + + + + Inventory control information + +

TBD

+ + + C.3.4.2 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + + Logistics management information + +

TBD

+ + + C.3.4.3 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + + Services acquisition information + +

TBD

+ + + C.3.4.4 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + + Lifecycle and change management information + +

TBD

+ + + C.3.5.2 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-moderate + + + fips-199-moderate + fips-199-low + + + + Information security information + +

TBD

+ + + C.3.5.5 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-moderate + + + fips-199-moderate + fips-199-low + + + + Record retention information + +

TBD

+ + + C.3.5.6 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + + Information management information + +

TBD:

+ + + C.3.5.7 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-moderate + + + fips-199-moderate + fips-199-low + + + + Information sharing information + +

TBD

+ + + C.3.5.9 + + + fips-199-moderate + fips-199-moderate + +

This information has no base recommendation in SP 800-60 Volume 2 + Revision 1 guidance. + The Office of Information Systems Management's consulted the BloSS@M + Team and the NIST system owner, who categorized this information sharing + at FIPS-199 Moderate impact.

+ + + + fips-199-moderate + fips-199-moderate + +

This information has no base recommendation in SP 800-60 Volume 2 + Revision 1 guidance. + The Office of Information Systems Management's consulted the BloSS@M + Team and the NIST system owner, who categorized this information sharing + at FIPS-199 Moderate impact.

+ + + + fips-199-moderate + fips-199-moderate + +

This information has no base recommendation in SP 800-60 Volume 2 + Revision 1 guidance. + The Office of Information Systems Management's consulted the BloSS@M + Team and the NIST system owner, who categorized this information sharing + at FIPS-199 Moderate impact.

+ + + + + Scientific and technological research and innovation information + +

TBD

+ + + D.19.1 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-moderate + + + fips-199-moderate + fips-199-low + + + + Research and development information + +

TBD

+ + + D.20.1 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-moderate + + + fips-199-moderate + fips-199-moderate + + + + Research and development information + +

TBD

+ + + D.20.4 + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + fips-199-moderate + fips-199-low + + + + + fips-199-moderate + fips-199-moderate + fips-199-low + + + + +

TBD: A holistic, top-level explanation of the system's authorization boundary.

+ + + +

A diagram-specific explanation.

+ + + Authorization Boundary Diagram + + + + +

A holistic, top-level explanation of the network architecture.

+ + + +

A diagram-specific explanation.

+ + + Network Diagram + + + + +

A holistic, top-level explanation of the system's data flows.

+ + + +

A diagram-specific explanation.

+ + + Data Flow Diagram + + + + + + AWS Managed Blockchain (AMB) + + + e63e870d-bf43-40dc-98a0-37d5e39b2dd1 + 2024-01-01 + +

TBD: ssp-uuid: 73a7ca56-ac02-43b9-8664-62bcb05a7e91 will need to be added for + oscal 1.2.0.

+

The leveraged authorization assembly is supposed to have a required uuid flag + instead of an optional id flag. This will be fixed in the syntax shortly.

+

Use one leveraged-authorization assembly for each underlying system. (In the + legacy world, these may be general support systems.

+

The link fields are optional, but preferred where known. Often, a leveraging + system's SSP author will not have access to the leveraged system's SSP, but + should have access to the leveraged system's CRM.

+ + + + System Administrator + + + + system-administrator + + Full administrative access rights + add and remove users, software-name and hardware + install and configure deployments + system updates, patches and hotfixes + perform backups + + + + System Owner + + + + system-owner + + Privileged access rights + add and remove users, software-name and hardware + install and configure deployments + system updates, patches and hotfixes + perform backups + + + + System Security Assessor + + + + sys-sec-assessor + + Non-privileged access rights (read only) + review system documentation and security configurations + review if system updates, patches and hotfixes are documented and successfully completed + review disaster recovery procedures and system backups existance + + + + This System + +

The entire Blossom system as depicted in the system authorization boundary

+ + + + + AWS Managed Blockchain (AMB) - Leveraged System + +

TBD: If the leveraged system owner provides a UUID for their system (such as in + an OSCAL-based CRM), it should be reflected in the inherited-uuid + property.

+ + + + + + + + + +

TBD: Description of Blossom inventory items 1

+ + + + + + + + + + + + +

This is a palceholder for the FedRAMP SSP Template Section 13

+

This description field is required by OSCAL.

+

FedRAMP does not require any specific information here.

+ + + + + + + + + +

Per the documentation available in the Blossom Wiki, the AWS Managed + Blockchain (AMB) provides access control to the infrastracture for the + entities identified below which require access to IaaS to maintain and + deploy system components. The blockchain's chaincode is implementing Next + Generation Access Control (NGAC) standard to manage the access to resources + for the roles docuemnted in the Blossom specification. Access control policy + machines are implemented for the two private channels of the AMB: the ATO or + "Authorization" channel and the "Businness" channel.

+ + + + +

The policy machines are controling the access to the two chaincodes + (Authorization and Business) used by the system.

+ + + + + + + have an organization-sponsored email address to demonstrate employment,complete training, and have been approved by the System Owner based on the business need of the individual + + + Access tagging + + + Accounts Manager(s): System Owner and Program Manager. + + + Organizational access control policies, standards and procedures, as documented in the AC-02.a statement implementation (statement-id="ac-2_smt.a", uuid="24a85abb-25ad-4686-850c-5c0e8ab69a0c"). + + + + System Administrator + + + 1 business day + + + within one hour + + + within openxmlformats-officedocument hours + + + + need to know + + + every 6 months or when a change takes place + + + 4fded5fd-7a65-47ea-bd76-df57c46e27d1 + + + 09ad840f-aa79-43aa-9f22-25182c2ab11b + + + + +

For the IAM entities that have a business need, and which have accounts created in Cognito, the Policy machines which implement NGAC in the two chaincodes are managing the access control for the Blossom business layer users and the BC Member's Authorizing Official that is uploading the ATO Attestation to the Authorization channel.

+ + + +

The Blossom system's System Owner and System Administrator are repsonsible for approving, creating and managing accounts and grant or denie access to the system by maintaining accurate information in Cognito and updating the access control policies access control lists (ACLs).

+ + + + + +

AWS manages the access to approved entities to the system's infrastructure, for deployment, maintenance, and operations.

+ + + +

Keep the ACL list current at all times.

+ + + + + + + +

The system has privileged and non-privileged accounts associated with the business layer and the ATO processes.

+

These accounts are managed by the NGAC implementation in the chaincodes for the ATO and for the assets management (business) processes.

+

The following accounts are supported for the business operations (assets management):

+
    +
  • Privileged accounts: +
      License Owner
    +
    • +
  • Non-Privileged accounts: +
      Acquisition Officer
    +
      Technical Point of Contact
    +
    • +
+

The Authorizing Official is responsible for reviewing the ATO package prepared by the System Owner and signing/authorizing the system to operate.

+

The System Owner remains the custodian of all system ATO related artifacts.

+

Upon approval, the Authorizing official is responsible for automatically generating the ATO attestation and uploading it to the ATO channel.

+

The following account is supported for the ATO processes.

+
    +
  • Privileged accounts: +
      Authorizing Official
    +
    • +
+ + + + + +

The following accounts of the NIST Member of the Blossom System are managed by the Leveraged AWS IaaS:

+
    +
  • Privileged accounts: +
      System Owner
    +
      System Administrator
    +
    • +
  • Non-Privileged accounts: +
      System Security Assessor
    + +
    • +
+ + + +

TBD: provided-uuid needs to match the one in the AWS' SSP.

+

All privileged and non-privileged accounts that are granted access to + the AWS infrastructure and are responsible for the Blossom System deployment and maintenance + (this system), are managed by the AWS IaaS (leveraged ATO system) + which uses an Access Control List (ACL) for the NIST employees + assigned Blossom roles.

+ + + + +

The Access Control List (ACL) updates are Blossom system's responsibility (as customers of AWS) + For all roles listed above which are managed by the AWS IaaS + system, account creation/revokation/deletion requests are approved + by the Blossom system's System Owner or the Program Manager and are added to or delete + from the ACL list by the System Administrator.

+ + + + + + + +

For this system, the entity with the System Administrator role + acts as the Accounts Manager and is responsible for creating, + revoking, deleting accounts per decisions made by the System Owner and the Program Manager.

+ + + + + + + +

For each identified role, access to the system for each role will be individually + analyzed and granted if the requesters proves they + for the respective group and role membership.

+ + + + + + +

1. All authorized users are listed and accuratelly maintained in this SSP in the "metadata", as "party" elements of type="person".

+

2. All roles supported by the Blossom system are documented in this SSP in the "metadata", as "role" elements with "id" identifying the role. + This system does not support groups.

+

3. All access authorizations are documented in this SSP in the "metadata" as "responsible-party" with "role-id" mathing the respective roles or attributes.

+ + + + + + +

Authorized Blossom users are documented in the Blossom SSP.

+ + + + + + +

Group and role membership

+ + + + + + +

Access authorizations (i.e., privileges) and [Assignment: organization-defined attributes + (as required)] for each account;

+ + + + + + +

Request to create accounts are approved by the System Owner and the Program Manager;

+ + + + + + +

Blossom user accounts are created, enabled, modified, disabled, and removed according to the types of Blossom accounts (privileged or non-privileged);

+ + + + + + +

Monitor the use of accounts;

+ + + + + + +

Account managers, System Owner, and Program Manager are notified within:

+ + + + + + +

Account managers, System Owner, and Program Manager are notified within1 business day when accounts are no longer required;

+ + + + + + +

within 1 business day when users are terminated or + transferred;

+ + + + + + +

within 1 business day when system usage or need-to-know + changes for an individual;

+ + + + + + +

System access authorization is based on:

+ + + + + + +

A valid access authorization;

+ + + + + + +

Intended system usage;

+ + + + + + +

Business need of the individual;

+ + + + + + +

Accounts are reviewed for compliance with account management requirements every 6 months.;

+ + + + + + +

There are no group or shared accounts created for accessing Blossom;

+ + + + + + +

All Blossom user accounts are updated by the system administrator when they are terminated or are transferred where their Blossom account is not required.

+ + + + + + + + +

Blossom Wiki

+ + + +

Project's Wiki which provides descriptions for the ATO and business processes.

+ + + + +

National Institute of Standards and Technology's Logo

+ + + 00000000 + +

May use rlink with a relative path, or embedded as base64 + .

+

FedRAMP prefers base64 for images and diagrams.

+

Images must be in sufficient resolution to read all detail when rendered in a + browser via HTML5.

+ + + + +

The primary authorization boundary diagram.

+ + + 00000000 + +

Section 9.2, Figure 9-1 Authorization Boundary Diagram (graphic)

+

This should be referenced in the + system-characteristics/authorization-boundary/diagram/link/@href flag using a + value of "#d2eb3c18-6754-4e3a-a933-03d289e3fad5"

+

May use rlink with a relative path, or embedded as base64 + .

+

FedRAMP prefers base64 for images and diagrams.

+

Images must be in sufficient resolution to read all detail when rendered in a + browser via HTML5.

+ + + + +

The primary network diagram.

+ + + 00000000 + +

Section 9.4, Figure 9-2 Network Diagram (graphic)

+

This should be referenced in the + system-characteristics/network-architecture/diagram/link/@href flag using a + value of "#61081e81-850b-43c1-bf43-1ecbddcb9e7f"

+

May use rlink with a relative path, or embedded as base64 + .

+

FedRAMP prefers base64 for images and diagrams.

+

Images must be in sufficient resolution to read all detail when rendered in a + browser via HTML5.

+ + + + Privacy Impact Assessment + + + + + + 00000000 + +

Table 15-1 Attachments: Privacy Impact Assessment

+

May use rlink with a relative path, or embedded as base64 + .

+ + + \ No newline at end of file