Skip to content
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

Network components need to declare the direction of network traffic #930

Open
14 tasks
aj-stein-gsa opened this issue Nov 22, 2024 · 0 comments
Open
14 tasks

Comments

@aj-stein-gsa
Copy link
Contributor

aj-stein-gsa commented Nov 22, 2024

Constraint Task

There must be at least one direction property, with no more than one incoming and no more than one outgoing direction.

Intended Outcome

Check that different kinds of network components for different leveraged authorizations and interconnection scenarios (see #808 (comment)) declare minimally required network traffic directions.

Syntax Type

This is required core OSCAL syntax.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

<!-- Metapath context target -->
"//component[ (@type='service'  and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction']) or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ]"

<!-- Constraint requirements:   There must be at least one direction property, with no more than one incoming and no more than one outgoing direction -->
count(./prop[@name='direction'])>=1
count(./prop[@name='direction' and @value='incoming']) <= 1
count(./prop[@name='direction' and @value='outgoing']) <= 1


<!-- Constraint requirements:
        If ./prop[@name='direction' and @value='incoming'] 
        If direction is incoming there must be at least one local ipv4 address, ipv6 address, or URI to an API.
-->
count( (./prop[@class='local' and @name=('ipv4-address', 'ipv6-address')]) or (./link[@rel='uri']) ) >=1

<!-- Constraint requirements:
        If ./prop[@name='direction' and @value='incoming'] 
        If direction is incoming there must be at least one local protocol entry.
-->
count(./protocol[@name='local']/port-range/@start)

<!-- Constraint requirements:
        If ./prop[@name='direction' and @value='incoming']  If ./prop[@name='direction' and @value='outgoing']
        If direction is outgoing there must be at least one remote ipv4 address, ipv6 address or URI to an API.
-->
count( (./prop[@class='remote' and @name=('ipv4-address', 'ipv6-address')]) or (./link[@rel='uri']) ) >=1
<!-- Constraint requirements:
        If ./prop[@name='direction' and @value='incoming']  If ./prop[@name='direction' and @value='outgoing']
        If direction is outgoing there must be at least one remote ports entry. -->
count(./protocol[@name='remote']/port-range/@start) >= 1

Purpose of the OSCAL Content

To identify network traffic patterns for reviewers to know if it is properly risk-managed and conforms with FedRAMP requirements and best practices.

Dependencies

No response

Acceptance Criteria

  • All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
    • Explanation is present and accurate
    • sample content is present and accurate
    • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
  • All constraints associated with the review task have been created
  • The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
  • The constraint conforms to the FedRAMP Constraint Style Guide.
    • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
  • Known good test content is created for unit testing.
  • Known bad test content is created for unit testing.
  • Unit testing is configured to run both known good and known bad test content examples.
  • Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
  • A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
  • This issue is referenced in the PR.

Other information

This is part of #807 and #808.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🏗 In progress
Development

No branches or pull requests

2 participants