Planning definition

[sunstonesecure-robert]

What would you like to be added?

Planning policy and procedure for the project and the delivery of the artifacts needs to be defined:

• PL-1 Policy and Procedures
• PL-2 System Security and Privacy Plans
• PL-2(1) System Security and Privacy Plans | Concept of Operations
• PL-2(2) System Security and Privacy Plans | Functional Architecture
• PL-2(3) System Security and Privacy Plans | Plan and Coordinate with Other Organizational Entities
• PL-3 System Security Plan Update
• PL-4 Rules of Behavior
• PL-4(1) Rules of Behavior | Social Media and External Site/application Usage Restrictions
• PL-5 Privacy Impact Assessment
• PL-6 Security-related Activity Planning
• PL-7 Concept of Operations
• PL-8 Security and Privacy Architectures
• PL-8(1) Security and Privacy Architectures | Defense in Depth
• PL-8(2) Security and Privacy Architectures | Supplier Diversity
• PL-9 Central Management
• PL-10 Baseline Selection
• PL-11 Baseline Tailoring

Why is this needed?

SLEDGEHammer as an in-boundary system will need to adhere to NIST 800-53 rev 5. Planning is a required set of controls. We can and should however tailor the High Baseline to align with early operator user goals/requirements, as well as CNCF requirements (e.g. PL(4)-1 restricting social media use may be explicitly a requirement for an open project)

User Stories

1. The project governance team creates, approves, and merges PRs containing planning policies and procedures into the repo for the community to review and use.
2. The project governance team creates machine readable planning definitions and code artifacts that can be verified
   to include:
3. metadata for actions (eg purpose), boundaries and interfaces (eg scope) - ex: UUIDs for components defining actions
4. contributor and reviewer roles and responsibilities - ex: NICE roles defined in yaml
5. project governance requirements and commitments - ex: schedule invites in a calendar with automatic reminders
6. define coordination among organizational entities - ex: PRs in github
7. compliance assessment checks - ex: specific policy-as-code checks that PRs are closed, meeting notes exist, roles
   are populated
8. Defines a machine readable structure for assessing compatibility with sovereign laws, executive orders, directives,
   regulations, policies, standards, and guidelines (I assume this capability should be broken out separately as a
   policy-as-code check of how to codify laws checklists)
9. encode procedures that facilitate the implementation of the planning policy and the associated planning controls;
   in addition to (or annotations to) simple human readable markdown there should be machine readable code
   supporting the policy goals noted above and specific implementations (eg github actions or validation policy-as-code)
10. The project governance team, expressed in the repo contributor list, reviews PRs and issues for the planning artifacts in the
    github repo, and execution of all github actions, etc.
11. The project governance team creates calendar invites to ensure that the community Reviews and update the current
    planning Policy and Procedure/Action/Policy-as-Code documents and machine readable artifacts annually and
    following a specific incident or security vulnerability that warrants ad hoc review
12. The project team agrees on and creates tooling to generate a machine readable System Security Plan and a github
    action to validate the SSP
13. The project team agrees on and creates tooling to generate a machine readable Privacy (Impact) Plan and a github
    action to validate the Privacy (Impact) Plan
14. The project team defines a machine readable Concept of Operations if possible. This could be a graph or expressed
    in a formal model.
15. The project team uses tooling to generate a machine readable definitions of the Functional, Security and Privacy
    Architectures. These enumerate the functional components, security capabilities, data flows, boundaries and data
    classification labels, ingress and egress interfaces and all connections between internal and external components
    and other default systems. Obviously users and operators can add new components and external connections and these
    will be out of scope for this effort.
16. The project team uses github, Zoom, Slack, and the project email list to Plan and Coordinate with operators, assessors, and
    the CNCF community of projects and contributors and users. Additional channels may be used by community members
    to embargo or keep private user or operator details that may be deemed too sensitive for public release. In all cases
    where security threats or vulnerabilities are involved, the security team assigned in the repo will follow the embargo and
    release of project-owned information - once all information is reviewed and sanitized for any operator or user-specific
    data or metadata.
17. The project governance team creates calendar invites to ensure that the community updates the current
    SSP and Privacy documents and machine readable artifacts annually and following a specific incident or security
    vulnerability that warrants ad hoc updates (eg new threats or control implementations)
18. The project team approves a template Rules of Behavior that may be useful to some operators. This is not intended to
    be specific to a given regulatory framework and may be tailored by the operator to fit their purposes. Considering the
    open and inherently distributed and "social" nature of the CNCF there is no restriction on social media use or guidance
    on limiting social media or other open channels for non-embargoed information. The security embargo policy and
    procedures will note the exceptions.
19. The project team approves tooling and artifacts for automated Security-related Activities for a K8s stack. These are defined
    in the system security plan and related control tasks/actions which describe how automated tools are used. There is no
    expectation of any manual cluster security activities. For the project itself, ie this repo, security activities will be limited
    to review of reported security issues or vulnerabilities in the project-provided artifacts themselves, not any hosted or
    user operated clusters.
20. The project defines Defense in Depth machine readable and automated security capabilities using threat based models like
    MITRE ATTACK and MITRE DEFEND, specific to K8s and related projects. Every supported component will have a machine
    readable threat model defined enumerating the TTPs and defensive controls to identify and protect as well as monitor
    and remediate (if possible to pre-determine).
21. The project defines a SBOM and feature configuration mechanism which is inclusive of multiple open source and
    commercial CNCF member components to encourage Supplier Diversity. Limitations on geographic or other sourcing
    options is not in scope, though the initial operator audience will be located in the US. Therefore suppliers used in the
    initial testing labs will in all likelihood operate in accordance with US requirements. However, the project explicitly aims
    to define compatible artifacts for ex-US requirements in later sprints.
22. This github repo is used for all Central Management of the project planning.
23. The project team will provide default Baseline Selections and Tailoring compatible with identified early adopters and
    testers. Subsequent sprints will add new baselines and new tailoring.