-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expansion of Protocol Tag to other components #1913
Comments
@Telos-sa, you have expressed two requests:
I had asked the FedRAMP Automation Team if there was a historical or outstanding current reason protocol is only for Re 2, is there any other type of component you are asking about to support protocol without error or warning? Can you give examples of a software component? If you recommend others, can you provide examples of those? |
During the 9/21 Triage Meeting, we decided to mark this ticket as |
@Arminta-Jenkins-NIST I meant feedback from @Telos-sa, not FedRAMP, sorry I didn't catch this sooner. Regarding FR PMO and Automation Team feedback from my previous comment #1913 (comment):
|
Thanks AJ. One of the new ones that may leverage the protocol tag for FedRAMP is their "Validations" for encryption. Since there are some, openSSL for instance, that should have their specific port or ports identified to support their use case. IE, how they are going to use the validation. Another use case, and the one that kicked this off, would be "Interconnection". If data is flowing via an interconnection, should it identify the specific port and protocol. If the overall goal is to leverage the service component as the owner of "protocol" then we may need some additional guidance on how to leverage the used by and provided by links, to demonstrate how the service is being leveraged by the interconnection. How the service is using the validation and/or software to support the connection. It may be that we leverage the "depends-on" and "uses-service" tags to support the components. In that case, would the depends on be owned by the service component as well, to identify the different validations/software that is required to make the service work? Then would the "uses-service" need to be used by the interconnection to show the upstream dependencies? If this is the case, and may be the best use case to support edge cases, then is the demonstration of the relationship owned solely by the down stream dependencies? |
For a https://pages.nist.gov/OSCAL/learn/tutorials/implementation/validation-modeling/
Does this make sense? Given our current documentation, I am not sure adding protocol here is sensible. Can you give an example as to why beyond what was said before?
This recommendation around |
@aj-stein-nist and @Telos-sa -- All comments above are addressing more than what the issue is calling for: "how information is flowing throughout the accreditation boundary and how these ports and protocols are being leveraged.". The FIPS 140 validation certificate is addressed in #1922. Continuing discussion the validation component type and the FIPS 140 validation certificate as component in two places is counter productive and risks providing inconsistent conclusions/outcomes. |
User Story:
As a project {stakeholder}, I need to be able to understand how information is flowing throughout the accreditation boundary and how these ports and protocols are being leveraged.
Communication via API
Software that leverage services:
Communication between two inventory items (Web server and DB):
Are cryptographic modules considered a component?
Goals:
Expand the use case of Components and protocols to meet the edge use cases of many interconnections, or support guidance for how to define edge.
Dependencies:
Link usnistgov/oscal-cli#186
Acceptance Criteria
The text was updated successfully, but these errors were encountered: