# BloSS@M Whiteboard of Greatness

**Presentation deadline: 12/5/2022**

- [x] Need to talk about presentation on Nov 29. (Prep)

## Presentation: Shifting Left the Right Way With OSCAL

### Abstract:
Top-down and bottom-up pressure to enhance security practice is increasingly acute following high-profile breaches and regulatory responses of late. **Properly documenting practices and standards for a system** is both human-driven and subjective. No standard medium for describing security compliance exists, adding significant complexity to these tasks. Developers practically compose heterogenous proprietary and open-source parts to build a whole, but must clearly communicate understanding of this sloppy, messy, real-world composition as a uniform whole, and must do so with a keen eye to any and all **security, privacy, and risk implications**.

**How should developers navigate the process of documenting, assessing, and approving** their increasingly complex systems in a way that lends itself to automation and leverages the benefits of good DevSecOps practices at the same time?

In this case study, we explore the use of **OSCAL as a means to document and facilitate the risk management of a pilot multi-party system that relies on distributed trust**.

> **The audience will be introduced to OSCAL and OSCAL tooling, as well as a pilot system designed with DevSecOps principles in mind.**

## Key Milestones

### Presentation Focus *(Questions to answer)*:

> - *Based on points above, and advertised to the audience.*
> - *Assumption is that OSCAL is a common thread below.*

#### Part 1: Background

- What is OSCAL? (Estimate: 2 Slides)
- How to move from paper to automation? (Estimate: 2 Slides)
- Private sector innovation in progress for GRC tooling.
- Link to tools page.
- What is OSCAL Tooling? (Estimate: 2 Slides)
- What is BloSS@M? (Estimate: 2 Slides)
- How does this contribute to the multi-party distributed trust effort? (Estimate: 1,2-4 Slides)
- Could mention ATO...
- Could mention ability to enable information exchange between orgs...
- Developers: Documenting Practices, Standards and Process (Estimate: 3 Slides)
- Documentation
- Assessment
- Approval
- **WE NEED SOME EVIDENCE HERE**
- Get Involved, Does it matter? (Estimate: 1 Slide)

> (10 Slides, ~**8**-10 Minutes)
> Outcome: I know what these things are, and where to find NIST's tools/repos. I understand the challenge(s) that we are trying to solve *(document security/privacy/risk compliance, and not be sloppy about it)*. I understand that I can be a participant in the future of these technologies, in addition to becoming an early adopter. Does it matter to me if I don't sell product to the federal govt?

#### Part 2: Approach ("Demo")

- What is **A** good DevSecOps practice? (Estimate: 4-? Slides) <- What our diagram is.

> (10 Slides, ~10-**12** Minutes)
> Outcome: I've seen a basic demonstration that sparks my interest, and provides a basic understanding of the application of these technologies that I can carry back to my team(s). I might be able to try this out in a small way in my own team. I also have some idea where the federal government may be headed with blockchain technology.

## General Flow


### In reverse, start with what we end with:

- Blossom github URL (here's an example of OSCAL being used)
- Which has:
- A sample app
- An example of the action being run (happy and sad path)
- A document that mirrors the presentation!

- A workflow quickstart
- Empty AP "smoke test"
- A set of permanent artifacts..to be determined how.

- Main branch = "Quick start"
- Empty templates
- Failing (maybe) tests

- Plan Step should fail if Resolved Catalog is older than the Profile. (Last Modified Date)

- We start with:
- A discussion of OSCAL, what an empty AP would look like

### Create demo repo (✅ done)

### Select target app, stage files

To decide:
- Use exiting BloSS@M application vs a purpose-built application for the demo
- Purpose built application
- Examples:
- A simple Django app with a login
- Pros
- The application is self explanatory, and does not require any additional context
- The application can be "melded" to the requirements we wish to comply with
- Cons
- App has to be built, however simple
- The "multi-party trust" aspect of the presentation would be difficult to demo
- Existing BloSS@M application
- Examples:
- dashboard
- enrollment
- chaincode
- authentication subsystem
- Pros
- Relates to blossom
- Allows us to talk about the multi-org aspect of this vision (shared responsibility, mutual ato, etc)
- Less throwaway work, all demo materials directly relevant to our next BloSS@M milestone
- Cons
- Not much presentation overhead (20 minutes). How much do we want to spend on explaining blossom?

### Stage AP, AR, SSP

### Configure GitHub Action(s)

### "Diagram" (steal existing SVG)

### Prep presentation materials

To decide:

- Present the system at a working state or a live demo utilizing *Important Federal Agency*
-

Note:
- Relating to hash check, how do we set this up so that others can follow what needs to be done, and understand.

### AP-AR Data Passthrough Architecture

So we have a system (documented in a SSP). That system is analyzed for security charateristics in an AP. The AP will reference automation in the `back-matter`, a little something like this:

  back-matter:
    resources:
      - uuid: BAAA0001-AAAA-5555-AAAA-AAAAAAAAAAAA
        title: "Execute pytest"
        description: "This is just to test the concept of executing some script or action within the repository."
        rlinks:
          - href: assessment/test_ac-8.py
            media-type: text/plain
            hashes:
              - algorithm: SHA-256
                value: 2e7de3c29f5ac5bceb0e5ef7a3a0134a6cca49c7135cf8c138f1422fb0fa9cee

How are we going to run this *within* a GitHub Action (or anywhere else for that matter)?

We should consider adding the following properties.

  back-matter:
    resources:
      - uuid: BAAA0001-AAAA-5555-AAAA-AAAAAAAAAAAA
        title: "Execute pytest"
        description: "This is just to test the concept of executing some script or action within the repository."
        props:
          - name: Assessment Result Expected Check Method
            ns: https://www.nist.gov/itl/csd/ssag/blossom
            class: ar-check-method
            value: system-shell-return-code
          - name: Assessment Result Expected Check Result
            ns: https://www.nist.gov/itl/csd/ssag/blossom
            class: ar-expected-check-result
            value: '0'
        rlinks:
          - href: assessment/test_ac-8.py
            media-type: text/plain
            hashes:
              - algorithm: SHA-256
                value: 2e7de3c29f5ac5bceb0e5ef7a3a0134a6cca49c7135cf8c138f1422fb0fa9cee