Applica in modo sicuro lo standard SLES 15 STIG con OpenSCAP

Utilizza il profilo DISA STIG supportato da SUSE per SLES 15, esegui la scansione del server con OpenSCAP e intervieni solo dopo aver esaminato la baseline su un sistema di test. Ad esempio, immagina un amministratore fittizio di nome Alex che prepara un server SLES 15 per un servizio regolamentato: Alex utilizza il flusso di lavoro descritto di seguito per identificare i problemi, testare le modifiche e raccogliere le prove, ma non considera una scansione automatizzata senza errori come un'approvazione di conformità.

I comandi seguono le attuali linee guida STIG di SUSE per SLES 15. Il contenuto del profilo può cambiare con gli aggiornamenti dei pacchetti e le nuove versioni del benchmark DISA, quindi verificare la versione applicabile e i requisiti specifici del sistema prima di utilizzare questa procedura. Le immagini del terminale illustrano i comandi e non mostrano l'output reale della scansione.

1. Confermare l'obiettivo e il benchmark attuale

Iniziate registrando il service pack SLES dell'host, lo scopo, il ruolo di rete e le applicazioni. Alex annota quali servizi devono rimanere disponibili, come si connettono gli amministratori e il metodo di ripristino nel caso in cui una modifica di hardening interrompa l'accesso. Questo ambito è importante: un host di database e un server generico possono avere eccezioni approvate diverse, anche se entrambi utilizzano lo stesso profilo STIG del sistema operativo.

Prima di selezionare il contenuto, verifica la versione installata:

cat /etc/os-release
hostnamectl

Successivamente, scaricate la checklist SLES 15 STIG e la revisione del benchmark applicabili dalla pagina ufficiale di download DISA STIG . Abbinate la checklist alla famiglia di sistemi e seguite le istruzioni di valutazione della vostra organizzazione. SUSE documenta il supporto per il profilo SCAP "DISA STIG for SUSE Linux Enterprise 15", ma questo da solo non determina quale versione è richiesta dalla vostra autorità né certifica un host.

2. Installare e verificare il contenuto di SCAP

Su un sistema SLES registrato con accesso ai repository appropriati, installare le utilità da riga di comando di OpenSCAP e il contenuto della Guida alla sicurezza di SCAP:

sudo zypper install openscap-utils scap-security-guide

I nomi dei pacchetti e la posizione del flusso di dati SLES 15 riportati di seguito sono documentati nella guida di hardening di OpenSCAP di SUSE e nella procedura STIG di SUSE . I repository dei pacchetti e le revisioni dei profili possono variare a seconda del service pack e del livello di aggiornamento. Elencare i flussi di dati installati e ispezionare il file candidato anziché presumere un nome file o un profilo:

ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Verificare che il flusso di dati SLES 15 sia presente e che l'elenco dei profili includa stig. Se il file o il profilo non sono presenti, interrompere e risolvere l'incongruenza del pacchetto o del repository; non utilizzare il benchmark di un altro sistema operativo.

3. Acquisire una linea di base, quindi testare la soluzione

Prima di generare i report, create una cartella protetta per le prove. Eseguite prima una scansione, senza modificare le impostazioni di sistema:

sudo install -d -m 0700 /root/stig-review
sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/baseline.xml \
  --report /root/stig-review/baseline.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Apri il report HTML ed esamina ogni risultato, in particolare gli errori, i guasti e le regole che non è stato possibile verificare. Conserva il report XML come prova di configurazione sensibile. Possono rivelare dettagli sull'host e sullo stato di sicurezza, quindi archiviali o trasferiscili solo tramite canali approvati.

Successivamente, clonare o creare uno snapshot del server in un ambiente non di produzione. Convalidare il comportamento dell'applicazione, l'accesso alle identità, la rete, il monitoraggio e il ripristino prima di applicare le modifiche automatizzate. SUSE avverte gli amministratori di testare prima le soluzioni al di fuori dell'ambiente di produzione, poiché modificano la configurazione del sistema. Sull'host di test, il metodo documentato per l'applicazione "al volo" è il seguente:

sudo oscap xccdf eval --remediate \
  --profile stig \
  --results /root/stig-review/remediation.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Il risultato generato può includere un risultato del test pre-correzione e un risultato del test post-correzione. Una regola contrassegnata fixedindica che la relativa correzione automatica è stata applicata e che la regola ha superato la valutazione; un erroraltro stato indica che la correzione per quella regola non è riuscita. Nessuno dei due stati sostituisce i test operativi o la revisione del requisito sottostante.

4. Eseguire una nuova scansione, risolvere le eccezioni e conservare le prove.

Dopo aver analizzato il comportamento del test, eseguire una scansione separata con percorsi di output nuovi. Una valutazione basata esclusivamente sulla scansione aiuta a distinguere lo stato attuale da quello dell'esecuzione della correzione:

sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/final.xml \
  --report /root/stig-review/final.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Non aspettatevi che ogni regola sia automaticamente risolvibile. Analizzate i fallimenti rispetto al testo completo della verifica e della correzione della regola utilizzando l'esatta versione della checklist DISA selezionata per il sistema. Alcune regole richiedono una decisione esplicita del responsabile del servizio, una configurazione specifica del sito o una documentazione manuale. Se una regola non è applicabile o non può essere soddisfatta, documentate le motivazioni e i controlli compensativi attraverso la procedura formale di gestione delle eccezioni dell'organizzazione; la modifica o l'adattamento di un profilo non garantisce automaticamente il superamento di un requisito.

Per la revisione della checklist, SUSE documenta l'esportazione di un file XCCDF che può essere importato in DISA STIG Viewer. Generalo con l'opzione supportata e poi importalo nel Viewer seguendo le istruzioni utente correnti:

sudo oscap xccdf eval \
  --profile stig \
  --stig-viewer /root/stig-review/results_stig.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Il pacchetto di prove di Alex per il server fittizio registra l'identità dell'host e del service pack, la revisione del benchmark, la versione del contenuto SCAP, la data della scansione, i report di base e finali, le azioni correttive, i controlli manuali e le eccezioni approvate. Conferma che i file esistano e rimangano leggibili solo dai revisori autorizzati:

sudo ls -l /root/stig-review

Prima di dichiarare l'attività completata, verificare che il report finale rifletta una scansione eseguita dopo le modifiche, che ogni problema rimanente abbia un responsabile e una soluzione, e che i servizi richiesti dal server funzionino correttamente. La conformità agli standard STIG è uno stato valutato legato a uno specifico benchmark e ambito di sistema; OpenSCAP supporta tale valutazione, ma non concede l'accreditamento né garantisce che tutti i requisiti del sito siano stati soddisfatti.

Fonti

• SUSE: Rafforzare la sicurezza di SUSE Linux Enterprise con gli standard STIG.
• SUSE: Rafforzamento della sicurezza di SLES con OpenSCAP
• DISA: Download STIG