Comments (10)
This is a very important thread to thoroughly consider in this spiral: usnistgov/OSCAL#1300
from oscal-define.
Additional input needed to go into the document, but the latest spiral was moved out of my personal fork into the project for visibility, will add changes/updates to the branch referenced below.
from oscal-define.
Preliminary brief and discussion around CRM support in OSCAL.
from oscal-define.
Consider trying this in working branch as a concept for export
.
from oscal-define.
@Compton-NIST The intent of the export
is to provide a container for descriptive data that is to be made public, while the data in the containing object can be kept private. This gives SSP authors the ability to have BOTH public and private information. This mirrors capabilities that are available in GRC tools today.
While deprecating the use of export
and providing an exportable
flag is simple, at face value it looks like the descriptive information can only be public or private. Under this solution, how would an SSP author represent both public and private information? This is not clear from the examples in your briefing.
from oscal-define.
@david-waltermire-nist Thanks for this. More depth is on the way, and I can demonstrate this concept of public vs private. I have a round of feedback to process, and I'll share updates here. Hopefully by end of this week.
from oscal-define.
@Compton-NIST - Please find below some food for thoughts. I summarized the proposal discussed and then try to look at a DB scenario documented as CDef ->used in SaaS SSP -> with provided and responsibilities -> carried into PaaS CRM -> leveraged in SaaS SSP where some responsibilities are satisfied, others are passed on to -> SaaS CRM for the Client SSP.
Let's discuss tomorrow some concerns I tried to capture. I included the usnistgov/OSCAL/#1300 issue to discuss it since it makes sense for the CRM to document the implementation-status similar to the SSP.
from oscal-define.
Latest briefing on state of the modeling.
Note that there is awareness of the uuid concerns noted above, but for now I'm assuming CDef as a pass through for the identifiers that should exist in the SSPs. I'm minimized those in the diagrams to focus on the essential parts. Technically, the CDef should not be required if full SSPs are shared.
briefing-2023-08-31.pdf. See below.
from oscal-define.
Updated with corrections to a few identifiers in the Application Owner SSP. briefing-2023-08-31.pdf
from oscal-define.
To Do:
- Need to add context in the SSP and CDef models so that visitors to the reference understand the intentions in the prototype.
from oscal-define.
Related Issues (18)
- SAMPLE ONLY: Model needed for communicating shared responsibilities without exposing SSP in OSCAL. HOT 2
- Spiral 3: Create export examples for responsibility model HOT 4
- Research Effort: Determine changes and revisions required in the development mapping model. HOT 5
- SAMPLE ONLY: Spiral 1: Use Case and Sample Data Creation HOT 2
- Spiral 1: Consolidate all issues and research into single spiral. HOT 2
- Spiral: Change Request creation for a qualifier assembly/tag in mapping. HOT 7
- Spiral: Change Request creation for a provenance assembly in mapping. HOT 13
- Spiral: Determine approach for unmapped items in a mapping. HOT 2
- SAMPLE ONLY: Spiral 2: Map use case information to existing OSCAL model(s) and identify gaps.
- Spiral: Determine approach to mapping with context of evidence HOT 2
- Update process and documentation HOT 3
- Spiral: Determine approach to documenting in the SSP and Component Definition a mapped control or statement. HOT 1
- SSP system characteristics needs to be expanded to support multiple frameworks
- [Spiral]: This is a test spiral
- [Research Effort]: Lack of Cyber Resilience OSCAL control profile to assess and protect High Value Targets HOT 1
- Research Effort: A model is needed for customer responsibilities that does not expose the SSP. HOT 1
- Feedback and notes on research process as applied to the current effort/spirals. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oscal-define.