Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support for OSCAL as configuration input

Aperta
  • Qualcosa non va?
#17 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python
Ambito
devops, security

Direzione di ricerca

Non viene indicato alcun file di implementazione né alcun punto di ingresso. Inizia tracciando il flusso di configurazione esistente, i fetcher, i controlli, le evidenze di locker e la generazione di controls.json, quindi confronta gli approcci basati sulla definizione dei componenti e sul piano di valutazione. Il lavoro è completato quando esistono un piano di integrazione concordato ed esempi OSCAL standard che producono configurazioni equivalenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

cli configuration enhancement OSCAL

Overview

NISTs OSCAL is a public standard used for describing controls, implmentations, systems and their assessment. We have done IBM internal POC work to confirgure Auditree from OSCAL files. This is about how to bring that into the open source project.

Requirements

  1. Read standards compliant OSCAL file (model tbc - see below) to configure Auditree.
  2. OSCAL input should be stored as evidence for consistency
  3. Identifying controls implemented via a fetcher/check should be simple & inkeeping with the spirit of OSCAL
  4. OSCAL should not be a requirement for running Auditree, more a nice to have.

You could image a tool that goes the other way (from an Auditree configuration to an OSCAL file). That's interesting, and might help with adoption of OSCAL, but out of scope here.

Approach

We have a few potential approaches, depending on how & where in the life cycle we want to introduce OSCAL. There may be more than one approach used, depending on circumstance. This issue is to discuss & form a plan to go forward.

Component definition

Our current POC uses a component definition to turn on/off fetchers/checks. It does this by scanning the file for control-implementations where type is monitoring, and then scanning the properties of the implementation for a auditree_{fetcher,check}_path. This is then "grafted" onto the configuration repository to produce a full config.

To facilitate this, running auditree becomes a three step process:

  1. We retrieve the component defintion via a fetcher, placing it in the locker
  2. We run our configuration script to make the appropriate controls.json from the component defintion
  3. We run the complete configuration as normal

This has some useful properties:

  • it runs as part of normal execution, and is consequently kept current
  • combining the configuration in the component defintion with the one from the config repo happens "naturally"
  • input OSCAL is stored as evidence
  • the fetchers are "constrained" only by their configuration/permissions - e.g. we can "discover" inventory

However, it doesn't help much with configuring the broader Auditree system, for example is says nothing about how often Auditree itself should run (though could if Auditree was defined as a component) nor which Harvest reports are required.

SSP

I think this would look a lot like the component defintion, with the potential further constraint of a specified inventory.

Assessment plan

An assessment plan would allow for "bigger" configuration - for example configuring the frequency at which Auditree is run, or schedule Harvest reports as additional assets/assessment-activities.

I think the workflow would look like:

  1. Run an independent tool to configure Auditree from the assessment plan
    • configure tekton/travis/jenkins/circle... pipeline for fetcher/check execution
    • configure tekton/travis/jenkins/circle... pipeline for report execution
  2. Retrieve the assessment plan & store as evidence (could use plant or a simple fetcher.
  3. Use the assessment plan to configure the fetchers and checks, as in the component definition POC
  4. Run the complete fetcher/check config.
  5. Run harvest reports on independent schedule, using plant to place results into the locker.

An assessment plan seems more idiomatic, too.

Considerations & open questions
  • Auditree should be able to run without OSCAL (as now).
  • Should this be baked into the framework (additional CLI option, allowing for multiple), be a separate tool, or perhaps both?
  • Where should this code reside, framework + tool?
  • Configuration repositories are likely more easily managed than OSCAL, so should at least be used as a baseline.
  • What configuration, beyond fetchers/checks to run, should come from OSCAL? Does this require standardisation in fetcher/check development, or could it be embedded JSON blobs?

Security and Privacy

Provide the impact on security and privacy as it relates to the completion of
this issue. This level of detail may not be available at the time of
issue creation and can be completed at a later time. N/A if not applicable.

Credential management will be a thing, especially in the more complete integration. Obviously creds should not be placed in the OSCAL files, but maybe names/references to them could be (to then be retrieved from Vault or sealed secrets).

Test Plan

Provide the test process that will be followed to adequately verify that the
approach above satisfies the requirements provided. This level of detail may
not be available at the time of issue creation and can be completed at a later
time.

  • Define some standard OSCAL files that describe known configurations. Confirm that equivalent configurations are generated by the implementation.
Lingua principale
Python
Stelle
76
Fork
25
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ComplianceAsCode/auditree-framework

Tutte le issue di ComplianceAsCode/auditree-framework

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.