OSCAL Integration
Options
![[Deleted User]](https://wa.vanillicon.com/v2/ae0a4a12ac07ad74ee7cb6db2170f99a.svg)
[Deleted User]
Posts: 8
The National Institute of Standards and Technology (NIST) is developing the Open Security Controls Assessment Language (OSCAL). I would like to propose that Jama integrates OSCAL into Jama such that security controls can be developed, and then exported in the appropriate digital format, or at least integrated with tools that do produce the OSCAL compliant security documentation. For more information, see https://pages.nist.gov/OSCAL/
Rationale:
1. The development of security documentation is fundamentally a requirements effort. You develop the "control language" in response to the NIST 800-53 control, and then create the required derived requirements necessary to implement that control language.
2. Most tools in this space only allow you to create the security documents, but do not provide the ability to track derived requirements or integrate with execution tools such as Jira.
3. The NIST 800-53 controls are becoming the standard cyber security requirements framework beyond the US Government, and is not used significantly across many verticals that require the development and validation of secure computing platforms.
Current workaround using Jama
1. Manually create all of the NIST 800-53 controls as requirements
2. Manually create field types to hold the "control language" in response to the NIST 800-53 controls
3. Manually sync the NIST 800-53 controls with NIST when there are changes to the controls
4. Manually cut-and-paste from Jama to Word to produce the required documentation (the RTF editor used by Jama doesn't allow the creation of the required Word formatting)
In the future the workaround will include cutting and pasting from Jama into an OSCAL compliant tool if Jama is involved at all.
This process is daunting and pushes Jama out of this growing market. Once other tools such as Xacta allow for requirements decomposition and task tracking, Jama will permanently be cut out of this market.
Rationale:
1. The development of security documentation is fundamentally a requirements effort. You develop the "control language" in response to the NIST 800-53 control, and then create the required derived requirements necessary to implement that control language.
2. Most tools in this space only allow you to create the security documents, but do not provide the ability to track derived requirements or integrate with execution tools such as Jira.
3. The NIST 800-53 controls are becoming the standard cyber security requirements framework beyond the US Government, and is not used significantly across many verticals that require the development and validation of secure computing platforms.
Current workaround using Jama
1. Manually create all of the NIST 800-53 controls as requirements
2. Manually create field types to hold the "control language" in response to the NIST 800-53 controls
3. Manually sync the NIST 800-53 controls with NIST when there are changes to the controls
4. Manually cut-and-paste from Jama to Word to produce the required documentation (the RTF editor used by Jama doesn't allow the creation of the required Word formatting)
In the future the workaround will include cutting and pasting from Jama into an OSCAL compliant tool if Jama is involved at all.
This process is daunting and pushes Jama out of this growing market. Once other tools such as Xacta allow for requirements decomposition and task tracking, Jama will permanently be cut out of this market.
0