- 1. CICD-SEC-7: Spiegazione della configurazione insicura del sistema
- 2. Importanza della configurazione sicura del sistema in CI/CD
- 3. Prevenire la configurazione insicura del sistema in CI/CD
- 4. Standard di settore per la sicurezza della configurazione del sistema
- 5. FAQ sulla configurazione insicura del sistema
Indice dei contenuti
Che cos'è la configurazione insicura del sistema?
Indice dei contenuti
La configurazione insicura del sistema è un rischio di sicurezza della Top 10 CI/CD di OWASP. Si verifica quando i sistemi CI/CD distribuiscono con configurazioni non ottimali o predefinite. Può includere porte aperte non necessarie, credenziali predefinite, sistemi non patchati, reti mal segregate o funzioni di sicurezza disattivate. Queste vulnerabilità possono esporre il sistema ad accessi non autorizzati e aumentare la propagazione di malware e il potenziale di iniezione di codice maligno nel processo di distribuzione, portando infine a violazioni di dati e interruzioni delle operazioni aziendali. Le configurazioni insicure possono anche portare all'abuso di processi CI/CD legittimi, consentendo agli aggressori di manipolare i flussi di lavoro e di accedere agli ambienti di produzione.
CICD-SEC-7: Spiegazione della configurazione insicura del sistema
Una configurazione insicura del sistema rappresenta un rischio significativo per la sicurezza. Si tratta di carenze nelle impostazioni di sicurezza, nella configurazione e nell'indurimento di vari sistemi della pipeline, come la gestione del codice sorgente (SCM), i sistemi CI e i repository di codice. Queste vulnerabilità sono spesso un facile bersaglio per gli aggressori che cercano di espandere la loro portata all'interno dell'ambiente.
Gli ambienti CI/CD sono costituiti da più sistemi di diversi fornitori. Per migliorare la sicurezza del CI/CD, è essenziale concentrarsi non solo sul codice e sugli artefatti che scorrono nella pipeline, ma anche sulla posizione e sulla resilienza di ogni singolo sistema.
Come i sistemi di archiviazione ed elaborazione dei dati, i sistemi CI/CD comportano numerose impostazioni e configurazioni di sicurezza a livello di applicazione, rete e infrastruttura. Queste impostazioni giocano un ruolo significativo nel determinare la postura di sicurezza degli ambienti CI/CD e la loro suscettibilità a potenziali violazioni.
Gli aggressori vanno a caccia di vulnerabilità CI/CD e di configurazioni errate da sfruttare. I potenziali difetti di tempra includono:
- Sistemi con versioni obsolete
- Sistemi con controlli di accesso alla rete troppo permissivi.
- Sistemi self-hosted con permessi di amministrazione sul sistema operativo sottostante.
- Scarsa igiene delle credenziali
Configurazione del sistema definita
La configurazione del sistema si riferisce al processo di impostazione dei sistemi e dei servizi, alla definizione delle modalità di interazione e alla definizione delle regole di funzionamento. Questo include l'impostazione dell'hardware, l'installazione e la configurazione del software e la creazione di connessioni di rete. Poiché il processo di configurazione può avere un impatto significativo sulla funzionalità, sulle prestazioni e sulla sicurezza di un sistema, è di vitale importanza che sia corretto - e che mantenga il suo stato ottimale.
Componenti della configurazione sicura del sistema
Una configurazione sicura comporta la corretta impostazione dei parametri di sistema, la gestione dei controlli di accesso e l'implementazione di misure di sicurezza per i sistemi che sono alla base della pipeline CI/CD. Tali configurazioni mitigano il rischio di accesso non autorizzato e impediscono lo sfruttamento delle vulnerabilità nei sistemi che costituiscono la spina dorsale dell'ambiente di sviluppo.
La complessità nell'ambiente CI/CD deriva dall'ambiente CI/CD, in quanto la configurazione del sistema si estende oltre i singoli sistemi, fino alle interconnessioni tra gli strumenti, i servizi e le piattaforme utilizzate nella pipeline. Non sorprende che il componente principale di una configurazione efficace e sicura del sistema sia una rigorosa gestione della configurazione.
Come avviene il CICD-SEC-7
La causa principale delle configurazioni di sistema insicure è spesso riconducibile all'errore umano, alla mancanza di procedure adeguate o alla comprensione inadeguata dei requisiti di sicurezza. Può derivare da qualcosa di semplice come lasciare invariate le impostazioni predefinite, consentire permessi eccessivi o trascurare l'aggiornamento e la patch dei sistemi.
Una situazione ipotetica
L'aggressore esegue la scansione della rete di destinazione, un'azienda tecnologica specializzata in intelligenza artificiale, e scopre un server Jenkins esposto e configurato con impostazioni predefinite. Utilizzando strumenti facilmente reperibili e una chiamata API, procedono all'estrazione dei metadati del server Jenkins per ottenere informazioni potenziali sul sistema sottostante. Una miniera di informazioni inonda il loro schermo: dati sui plugin, sui lavori, sulle configurazioni del sistema e altro ancora. Tra questa messe di dettagli, spicca una serie di informazioni. Chiavi AWS. Venivano utilizzati da Jenkins per distribuire le applicazioni su AWS e non erano adeguatamente protetti. Le chiavi sono per un account amministratore, che garantisce un accesso potenzialmente illimitato all'ambiente AWS dell'azienda.
Utilizzando le chiavi per infiltrarsi nell'infrastruttura AWS dell'azienda, l'attaccante entra nel cuore del sistema dell'organizzazione. Individuano un bucket S3 che ospita modelli AI proprietari e, grazie all'accesso a livello di amministrazione dalle chiavi AWS rubate, scaricano rapidamente i modelli e escono senza far scattare l'allarme.
L'attaccante decide quindi di sfruttare ulteriormente questo sistema. Consapevoli che il server Jenkins ha i permessi di scrittura sui repository di codice GitHub, inseriscono uno snippet di codice dannoso nel codice sorgente dell'applicazione principale che crea una backdoor nell'applicazione. Nel successivo ciclo di distribuzione, l'azienda spinge inconsapevolmente l'applicazione in produzione. Ora, armato di una backdoor persistente, l'aggressore può rubare i dati, manipolare i controlli del sistema e installare ulteriori malware, il tutto sotto il radar dei sistemi di sicurezza dell'azienda.
Importanza della configurazione sicura del sistema in CI/CD
Una configurazione errata in qualsiasi punto dell'ambiente di progettazione potrebbe esporre l'intera pipeline a potenziali minacce. Un aggressore che sfrutta la configurazione errata potrebbe ottenere un accesso non autorizzato al sistema CI/CD - o peggio, compromettere il sistema e accedere al sistema operativo sottostante. L'attaccante potrebbe manipolare i flussi CI/CD legittimi, ottenere token sensibili e potenzialmente accedere agli ambienti di produzione. In alcuni scenari, i difetti di configurazione possono consentire a un aggressore di muoversi lateralmente all'interno dell'ambiente e al di fuori del contesto dei sistemi CI/CD.
Rischi associati alla configurazione insicura del sistema
I team DevOps con una comprensione dei rischi associati alla configurazione insicura dei sistemi sono in grado di progettare sistemi meno vulnerabili, di assumersi la responsabilità della sicurezza dei sistemi che progettano e di mitigare i rischi quando si presentano.
Caso di studio 1: PHP passa a GitHub in seguito all'incidente di sicurezza e alla potenziale fuga del database degli utenti.
Nell'aprile 2021, la comunità PHP ha affrontato un incidente di sicurezza che ha coinvolto git.php.net. Inizialmente sospettata come una compromissione del server, l'indagine ha rivelato che i commit dannosi sono stati effettuati utilizzando HTTPS e l'autenticazione basata su password, aggirando l'infrastruttura Gitolite. Il database degli utenti di master.php.net potrebbe essere trapelato, richiedendo una migrazione del sistema a main.php.net e un reset della password per tutti gli utenti di php.net. Git.php.net e svn.php.net sono stati resi di sola lettura e il repository principale di PHP è stato spostato su GitHub, migliorando la sicurezza e semplificando il flusso di sviluppo.
Caso di studio 2: Webmin rivede le misure di sicurezza dopo l'incidente dell'inserimento di codice maligno
Nell'agosto 2019, Webmin, uno strumento di configurazione del sistema basato sul web, ha subito una violazione della sicurezza quando è stato inserito del codice maligno nel suo codice sorgente. La violazione, che non era un bug accidentale, permetteva l'esecuzione di comandi da remoto. Il codice maligno è stato introdotto tramite un server di sviluppo compromesso. Al momento della scoperta, Webmin ha risposto aggiornando il processo di aggiornamento per utilizzare solo il codice controllato da GitHub, ruotando tutti i segreti accessibili e controllando tutti i commit di GitHub dell'ultimo anno alla ricerca di vulnerabilità simili.
Caso di studio 3: Il codice sorgente di Nissan North America è stato esposto online a causa di un server Git mal configurato.
In una significativa falla nella sicurezza, il codice sorgente di Nissan North America per le applicazioni mobili e gli strumenti interni è trapelato online a causa di un server Git mal configurato. Il server, lasciato esposto con nome utente e password predefiniti 'admin/admin', è stato scoperto dall'ingegnere informatico di origine svizzera Tillie Kottmann. Il repository conteneva il codice di varie app Nissan, strumenti di diagnostica, portali per concessionari, strumenti di marketing e altro ancora. Nissan ha confermato l'incidente, ha messo in sicurezza il sistema interessato e ha affermato che non è stato possibile accedere ai dati personali.
Caso di studio 4: Il Dipartimento IT dello Stato di New York espone online il repository interno di codice.
Un repository di codice interno utilizzato dal dipartimento IT dello Stato di New York è stato inavvertitamente esposto online, rendendolo accessibile a chiunque. Il server GitLab, scoperto dalla società di cybersicurezza SpiderSilk, conteneva progetti con chiavi e password segrete per i sistemi del governo statale. Il server era configurato in modo da consentire a chiunque di creare un account utente e accedere. Il server è stato individuato online per la prima volta il 18 marzo ed è stato messo offline dopo la segnalazione dell'esposizione. Secondo quanto riferito, il server era un box di prova creato da un fornitore e da allora è stato smantellato.
Prevenire la configurazione insicura del sistema in CI/CD
Sebbene la configurazione errata possa costituire un punto di ingresso per gli aggressori, portando a significative violazioni della sicurezza, la configurazione sicura del sistema rimane trascurata in molti processi di sviluppo. I consigli degli autori dell'elenco OWASP Top 10 CI/CD Security Risks possono mettere i suoi sistemi in regola:
- Tenga un inventario dei sistemi e delle versioni in uso, mappando ogni sistema a un proprietario designato. Controlli regolarmente questi componenti per verificare la presenza di vulnerabilità note. Quando è disponibile una patch di sicurezza, aggiorni il componente vulnerabile. Se non è disponibile una patch per il componente vulnerabile, consideri la possibilità di rimuovere il componente o il sistema. In alternativa, ridurre al minimo l'impatto potenziale dello sfruttamento della vulnerabilità, limitando l'accesso al sistema o la sua capacità di eseguire operazioni sensibili.
- Si assicuri che l'accesso in rete ai sistemi sia in linea con il principio dell'accesso con il minimo privilegio.
- Impostate un processo per rivedere periodicamente tutte le configurazioni del sistema. Concentri la sua revisione sulle impostazioni che potrebbero influenzare la postura di sicurezza del sistema. Assicuri le impostazioni ottimali.
- Concede permessi ai nodi di esecuzione della pipeline in base al principio del minimo privilegio. Una configurazione errata comune in questo contesto consiste nel concedere agli ingegneri i permessi di debug sui nodi di esecuzione. Molte organizzazioni lo consentono, ma è fondamentale considerare che qualsiasi utente che abbia accesso al nodo di esecuzione in modalità debug potrebbe esporre tutti i segreti mentre vengono caricati in memoria. Potrebbero anche utilizzare l'identità del nodo, concedendo di fatto permessi elevati a qualsiasi ingegnere con questa autorizzazione.
Standard di settore per la sicurezza della configurazione del sistema
Diversi standard di settore delineano le migliori pratiche per la sicurezza della configurazione del sistema. Il Center for Internet Security (CIS) fornisce parametri di riferimento completi per la configurazione sicura, mentre il National Institute of Standards and Technology (NIST) pubblica anche linee guida per la configurazione dei sistemi per la sicurezza.
Crittografia dei suoi segreti
Segreti come password, chiavi API e credenziali del database devono essere crittografati a riposo e in transito. Non memorizzi mai i segreti nel codice o nei file di configurazione. Utilizzi uno strumento di gestione dei segreti come HashiCorp Vault o AWS Secrets Manager. Questi strumenti mantengono i segreti crittografati e ne controllano l'accesso, aiutando a evitare che le credenziali delle sue organizzazioni finiscano nelle mani sbagliate.
Registrazione e monitoraggio dei suoi sistemi
Una parte fondamentale del mantenimento della configurazione sicura del sistema consiste nello stabilire politiche chiare e nel monitorare regolarmente la conformità. È importante registrare tutte le attività, in modo da poter individuare quelle sospette e rispondere rapidamente agli incidenti di sicurezza. Dovrebbe anche monitorare il suo sistema per individuare eventuali segni di attacco, come schemi di traffico insoliti o tentativi di accesso falliti.
Patching delle vulnerabilità
Si assicuri di disporre di un sistema completo di identificazione delle vulnerabilità e di patching. Identificare sistematicamente le vulnerabilità e dare priorità alla correzione. Nei casi in cui le vulnerabilità non possono essere corrette con una patch, utilizzi mitigazioni alternative, come la rimozione dei diritti di amministrazione. Si ricordi che mantenere i suoi sistemi aggiornati significa applicare regolarmente patch e aggiornamenti ai suoi server, applicazioni e strumenti CI/CD.
Eliminazione degli account e dei privilegi non necessari
Applichi il minimo privilegio rimuovendo gli account non necessari (come gli account orfani e gli account inutilizzati). Questa è una delle pratiche di sicurezza più efficaci per ridurre la superficie di attacco. Si assicuri che ogni componente del suo sistema - compresi gli utenti, i processi e i servizi - abbia solo i privilegi minimi necessari per svolgere la sua funzione. In questo modo, limiterà i danni in caso di compromissione di un componente.
Creazione di blocchi alla rete
Dividere la sua rete in segmenti più piccoli e isolati limiterà i movimenti laterali se un aggressore ottiene l'accesso alla sua rete. Utilizzi i firewall e le liste di controllo degli accessi (ACL) per controllare il traffico tra i segmenti. Crittografa il traffico, blocca le porte di rete aperte inutilizzate o non necessarie e disabilita o rimuove i protocolli e i servizi non necessari. Verifichi regolarmente le regole del suo firewall.
Proteggere i server di costruzione
I suoi server di compilazione sono responsabili della compilazione e del pacchetto del suo codice, quindi sono un obiettivo primario per gli aggressori. Si assicuri che i suoi server di build siano adeguatamente protetti con patch di sicurezza aggiornate e password forti. E ricordi che mettere in sicurezza il suo ambiente di creazione significa isolarlo dall'ambiente di produzione.
Audit dei suoi sistemi esistenti
Audit e revisioni regolari aiutano a garantire che le configurazioni del sistema rimangano sicure nel tempo. Esegua un audit completo della sua tecnologia esistente. Utilizza i test di penetrazione, la scansione delle vulnerabilità, la gestione della configurazione e altri strumenti di auditing della sicurezza per trovare le falle nel sistema e dare priorità alle correzioni. Eseguire valutazioni del sistema rispetto alle risorse utilizzando gli standard di settore di NIST, Microsoft, CIS, DISA, ecc.
Utilizzare gli strumenti per proteggere la configurazione del sistema
Esistono molti strumenti per aiutare a gestire e proteggere la configurazione del sistema. Gli strumenti di gestione della configurazione come Ansible, Chef o Puppet consentono una configurazione automatizzata e un'applicazione coerente tra gli ambienti. Per i sistemi basati sul cloud, i servizi cloud-nativi come AWS Config, Azure Policy e Google Cloud Security Command Center possono aiutare a mantenere una configurazione sicura.
FAQ sulla configurazione insicura del sistema
La gestione della configurazione è un processo di ingegneria dei sistemi per stabilire e mantenere la coerenza delle prestazioni, degli attributi funzionali e fisici di un prodotto con i requisiti, il design e le informazioni operative durante la sua vita.
L'hardening dei sistemi è un processo metodico di verifica, identificazione, chiusura e controllo delle potenziali vulnerabilità di sicurezza in tutta un'organizzazione. Applicando una serie di linee guida e strumenti per ridurre al minimo le vulnerabilità, l'hardening elimina le funzioni, le configurazioni e i servizi non necessari. Il processo può comprendere la configurazione sicura delle impostazioni del sistema, l'applicazione tempestiva di patch e aggiornamenti, la limitazione del numero di amministratori e utenti del sistema e l'impostazione di protocolli di autenticazione forti. L'idea alla base dell'indurimento dei sistemi è quella di rafforzare la sicurezza restringendo la superficie di attacco del sistema.
Gli standard di hardening dei sistemi sono linee guida e best practice progettate per proteggere i sistemi dalle minacce. Spesso sviluppati da organizzazioni di cybersecurity o da gruppi industriali, gli standard di hardening forniscono un quadro per configurare un sistema in modo da ridurre al minimo la sua superficie di attacco.
Esempi di standard di hardening sono i Benchmark del Center for Internet Security (CIS), che forniscono best practice di settore ben definite, imparziali e basate sul consenso, per aiutare le organizzazioni a valutare e migliorare la loro sicurezza.
Altri standard includono le Security Technical Implementation Guides (STIG) della Defense Information Systems Agency (DISA) e le linee guida di hardening del National Institute of Standards and Technology (NIST). Questi standard coprono un'ampia gamma di sistemi, tra cui sistemi operativi, dispositivi di rete e ambienti cloud, e vengono regolarmente aggiornati per affrontare le minacce e le vulnerabilità emergenti.
L'infrastruttura come codice è il processo di gestione e provisioning dei centri dati informatici attraverso file di definizione leggibili dalla macchina, piuttosto che la configurazione dell'hardware fisico o gli strumenti di configurazione interattivi.
Un Dockerfile è un documento di testo che contiene tutti i comandi che un utente potrebbe chiamare sulla linea di comando per assemblare un'immagine. Utilizzando Docker build gli utenti possono creare una build automatizzata che esegue diverse istruzioni da riga di comando in successione.
Una distribuzione Kubernetes è un oggetto risorsa in Kubernetes che fornisce aggiornamenti dichiarativi per pod e ReplicaSet. Gli ingegneri descrivono uno stato desiderato in una distribuzione, e il Controllore di distribuzione cambia lo stato attuale in quello desiderato a una velocità controllata.
Helm è un gestore di pacchetti per Kubernetes che consente a sviluppatori e operatori di pacchettizzare, configurare e distribuire più facilmente applicazioni e servizi sui cluster Kubernetes. Un grafico Helm è una raccolta di file che descrivono un insieme correlato di risorse Kubernetes.
I Buildpack sono un modo modulare e indipendente dalla lingua per trasformare il codice sorgente della sua applicazione in un'immagine OCI. Un buildpack ispeziona il suo codice per determinare cosa includere nell'immagine OCI.
La deriva della configurazione si verifica quando un sistema 'sbanda' o cambia rispetto alla configurazione prevista. Può accadere quando si apportano modifiche manuali ai sistemi, oppure quando si eseguono aggiornamenti o installazioni senza utilizzare uno strumento di gestione della configurazione.
YAML (YAML Ain't Markup Language) è un linguaggio di serializzazione dei dati leggibile dall'uomo. È comunemente utilizzato per i file di configurazione e nelle applicazioni in cui i dati vengono archiviati o trasmessi.
JSON (JavaScript Object Notation) è un formato di scambio dati leggero, facile da leggere e scrivere per gli esseri umani e facile da analizzare e generare per le macchine. Viene spesso utilizzato per trasmettere i dati nelle applicazioni web.
