GitSync
GitSync è un'integrazione solida creata dal team di servizi professionali SOAR di Google Security Operations e progettata per sincronizzare i componenti SOAR di Google Security Operations con un repository Git. Utilizza le operazioni interne di Git per scrivere direttamente nel repository, fungendo essenzialmente da servizio di archiviazione di file. Fornisce metodi per eseguire le seguenti operazioni:
Esegui la migrazione degli asset tra le istanze di Google Security Operations SOAR
Eseguire il backup degli asset di Google Security Operations SOAR
Documentazione automatica
Crea un "negozio" per condividere asset/conoscenze
Controllo delle versioni
L'integrazione è costituita da più job SOAR di Google Security Operations: job push e pull per ogni asset supportato e job push/pull per l'intera istanza SOAR di Google Security Operations. Questi job non devono essere eseguiti periodicamente, in quanto sono stati creati per essere eseguiti manualmente dall'IDE, ma possono essere utilizzati come job regolari (ad esempio, caricamento di un commit giornaliero).
GitSync utilizzerà l'API SOAR di Google Security Operations per recuperare l'asset pertinente, ad esempio un'integrazione o una famiglia di visualizzazioni, e analizzare tutte le informazioni disponibili dell'asset. Queste informazioni verranno poi visualizzate in un file README.md che viene solitamente mostrato durante la navigazione nel repository. Poi scrive la definizione JSON dell'asset e il file README sottoposto a rendering nel repository locale e lo invia al repository remoto.
Un altro utilizzo di GitSync è la condivisione delle conoscenze. Utilizzando questa integrazione, un repository Git può fungere da "archivio" per asset come playbook o impostazioni dell'ontologia progettati in precedenza e sfruttare le best practice SOAR di Google Security Operations per spingere la piattaforma al meglio.
Prerequisiti
Esecuzione del push/pull di un repository esistente:
Metodo di autenticazione per Git. Sono supportate una combinazione di nome utente/password (sconsigliata), un token di accesso (consigliato) e una chiave privata SSH con codifica Base64 (consigliata). Quando utilizzi gli ultimi due, il parametro username non è obbligatorio.
Un utente locale di Google Security Operations SOAR. Utilizzato per importare gli asset. Questo utente deve disporre dell'autorizzazione per scrivere il modulo di destinazione (ad esempio, un utente senza accesso all'IDE non sarebbe in grado di eseguire il pull delle integrazioni).
Crea un nuovo repository
Tutti i punti menzionati in Push/Pull di un repository esistente in precedenza.
Un repository remoto. È consigliabile avere almeno un file nel repository. La maggior parte dei servizi Git offre un'opzione per creare un file README durante la creazione del repository.
Configura l'integrazione
Devi configurare l'integrazione come istanza condivisa. Non può essere collegato a un ambiente esistente in Google SecOps SOAR.
Proprietà di integrazione
Nome parametro | Descrizione |
URL del repository | URL del repository. Quando utilizzi l'autenticazione utente/password, questo valore deve iniziare con https://. Se utilizzi l'autenticazione SSH, questo valore deve iniziare con git@ o ssh://. (vedi Configurazione dell'URL del repository e del ramo di seguito). |
Branch | Il ramo del repository da sincronizzare. |
Password/token/chiave SSH Git | Metodo di autenticazione per Git. Questo valore può essere la password/il token/la chiave privata SSH di Git. Le chiavi private devono essere codificate in base64. Sono supportati RSA ed Ed25519. |
Nome utente Git | Nome utente Git. Questo valore non è obbligatorio quando utilizzi l'autenticazione SSH. |
Autore commit |
Non obbligatorio. Consente di specificare l'autore del commit. Questo valore deve essere nel formato: Nome utente |
Google Security Operations SOAR Verify SSL | Verifica SSL per l'API Google Security Operations SOAR |
Git Verify SSL | Verificare l'SSL con il servizio Git di destinazione |
Configurazione dell'URL del repository e del ramo
In questa guida, mostreremo come ottenere i valori corretti in Bitbucket (tieni presente che la procedura è la stessa in GitHub).
Individua il repository in Bitbucket.
Fai clic sul pulsante Clona nell'angolo in alto a destra (Codice in GitHub).
Autenticazione SSH: l'URL del repository è git@bitbucket.org:siemplifyproserv/connectors.git
Autenticazione con utente/password o token: l'URL del repository è https://bitbucket.org/siemplifyproserv/connectors.git . (Il nome utente può essere ignorato)
Controlla il ramo attuale (master nell'immagine seguente)
Esempio di utilizzo
Ogni job in GitSync contiene i seguenti parametri:
Nome | Descrizione |
Specifici per il job: nome del connettore, identificatore di integrazione, lista consentita di playbook e così via. | Questi parametri servono a specificare cosa viene inviato o estratto dal repository. In GitSync, gli asset vengono indicati con i relativi identificatori. Questi valori sono sensibili alle maiuscole. |
URL e branch del repository | Aggiungi il supporto per più repository con le stesse credenziali. Una volta impostati questi parametri, il repository configurato nell'istanza di integrazione verrà ignorato. |
Messaggio di commit | Quando vengono inviati asset al repository, è necessario un messaggio per il commit. Qui puoi specificare il motivo del push, indicando cosa è stato corretto, modificato o aggiunto all'asset. |
Componente aggiuntivo Readme | Aggiunge la possibilità di estendere la documentazione degli asset quando vengono inviati. In questo valore puoi utilizzare:
Il modello viene aggiunto alla fine della documentazione e salvato nel file di metadati GitSync.json nella directory principale del repository. |
Recupero degli asset
In questo esempio, estrarremo un connettore con i mapping e le famiglie di visualizzazioni corretti.
- Innanzitutto, assicurati che l'asset si trovi nel repository configurato. Basta sfogliare le directory del repository e copiare l'identificatore della risorsa (di solito è il nome della directory o il titolo del file README).
Esempio di un repository in Bitbucket, nella directory Connettori. Tieni presente che le directory sono i nomi delle integrazioni e al loro interno si trovano i veri identificatori dei connettori. Trova il lavoro adatto nell'IDE SOAR di Google Security Operations. In questo esempio, utilizzeremo il job Pull Connector.
Nota: quando estrai un connettore, verifica che sia installata anche l'integrazione del connettore.
Fai clic sulla scheda Test e configura i parametri. Poiché utilizziamo un repository ed è già configurato nell'istanza di integrazione, lasceremo vuoti i parametri URL repository e Ramo e imposteremo gli altri parametri sui valori che ci servono.
Esegui il job.
Per il log dell'operazione, vedi Output di debug. Se tutto va bene, il log lo indicherà.
- Vai a Google Security Operations SOAR -> Connettori e configura il connettore.
Invio di asset
In questo esempio, eseguiremo il push di un playbook e di un blocco nel repository.
Identifica i playbook che vuoi eseguire il push. Qui inseriremo un nuovo blocco chiamato Tentativo di accesso non riuscito e un playbook aggiornato chiamato Attività dannosa.
Trova il lavoro adatto nell'IDE SOAR di Google Security Operations. In questo esempio, utilizzeremo il job Push Playbook.
Fai clic sulla scheda Test e configura i parametri.
- Poiché entrambi si trovano nella stessa cartella (Predefinita), puoi utilizzare anche la lista consentita di cartelle.
Esegui il job.
Per il log dell'operazione, vedi Output di debug. Se tutto va bene, il log lo indicherà.
Verifica che il repository contenga le versioni più recenti dei playbook.
Creazione di un nuovo repository
Per creare un nuovo repository, è importante includere un singolo file nel repository prima di configurarlo con GitSync. Puoi farlo rapidamente includendo un file README nella radice del repository durante la creazione.
Bitbucket
GitHub
Problemi noti e limitazioni
Dopo aver impostato il repository per la prima volta, utilizza una struttura di directory predefinita per assicurarsi di sapere dove si trova ogni asset. Se non rispetti la struttura delle directory con un commit personalizzato o modifiche al repository, l'integrazione non funzionerà correttamente. Puoi trovare lo schema della struttura delle directory del repository alla fine di questo documento.
Fai attenzione quando utilizzi questa integrazione con i repository pubblici. Gli asset SOAR di Google Security Operations utilizzano parametri che contengono ID applicazione, ID client, nomi utente e altre informazioni sensibili. GitSync non è in grado di stabilire se il parametro è sensibile o meno, pertanto ogni parametro che non è di tipo "Password" verrà caricato nel repository. Inoltre, quando viene eseguito il push di un'istanza SOAR di Google Security Operations (job Push Environment), è disponibile un'opzione per il commit delle password. Questa opzione indica a GitSync di provare a esportare tutti i parametri della password dalla configurazione dell'integrazione. Non impostare questo valore su true se il repository è pubblico, altrimenti tutte le credenziali verranno divulgate online.
Quando estrai un'istanza SOAR di Google Security Operations (job Estrai ambiente), l'installazione di tutte le integrazioni potrebbe richiedere più di 5 minuti e il job non andrà a buon fine a causa di un timeout. Per evitare problemi, ti consigliamo di installare manualmente tutte le integrazioni commerciali dal Google Security Operations Marketplace in anticipo. Tuttavia, è anche possibile eseguire nuovamente il job se non va a buon fine a causa di un timeout.
Le integrazioni commerciali e quelle personalizzate vengono gestite in modo diverso. L'integrazione personalizzata verrà inviata come intero file zip dell'integrazione per un'operazione di importazione/esportazione. Le integrazioni commerciali verranno inviate solo con il codice personalizzato. Una volta eseguito il pull, GitSync installerà l'ultima versione dell'integrazione da Google SecOps Marketplace e salverà il codice personalizzato nell'integrazione ufficiale.
Quando vengono estratti i mapping, questi non vengono visualizzati nella tabella Impostazioni -> Ontologia -> Stato ontologia finché gli eventi non vengono effettivamente importati in Google Security Operations SOAR, perché non sono ancora indicizzati.
Il repository locale viene salvato in /opt/siemplify/siemplify_server/GitSyncFiles/{RepoName}. Poiché l'integrazione scrive oggetti Git e non file, questa cartella non rappresenta il repository e viene sovrascritta con le modifiche apportate ogni volta che viene eseguito un job. Ti consigliamo di utilizzare un altro clone del repository e non quello creato da GitSync.
I playbook con autorizzazioni limitate (ad esempio, le autorizzazioni predefinite impostate su Può visualizzare) richiedono una configurazione specifica delle autorizzazioni sul sistema di origine per una sincronizzazione riuscita tramite GitSync. Per ulteriori informazioni, vedi Utilizzare le autorizzazioni del playbook.
Google SecOps supporta l'utilizzo di GitSync per eseguire il backup degli asset SOAR. Tuttavia,Google SecOps non supporta l'utilizzo di GitSync per *distribuire* gli asset SOAR tra i sistemi. Ciò può portare a risultati imprevisti perché gli oggetti del database potrebbero non essere univoci.
Utilizzare le autorizzazioni del playbook
Quando utilizzi GitSync per sincronizzare i playbook con autorizzazioni limitate (ad esempio, autorizzazioni predefinite impostate su Può visualizzare o altre impostazioni non predefinite), potresti riscontrare un errore nel sistema di destinazione se non dispone dell'autorizzazione per modificare il playbook. Ciò accade perché GitSync utilizza una chiave API di sistema interna con il ruolo SOC Administrator per eseguire azioni. Per garantire la sincronizzazione corretta dei playbook con autorizzazioni limitate, concedi al Administrator ruolo SOC le autorizzazioni
Può modificare nel sistema di origine per questi playbook.
Abilitare GitSync per estrarre playbook con autorizzazioni limitate
- Nel sistema di origine:
- Vai al playbook che intendi sincronizzare con GitSync.
- Apri le impostazioni delle autorizzazioni del playbook.
- Assicurati che il ruolo SOC
Administratorvenga aggiunto all'elenco delle entità con autorizzazioni Può modificare.
- Dopo aver modificato le autorizzazioni sul sistema di origine, esegui l'azione Push Playbook in GitSync per aggiornare il repository Git con il playbook e le relative autorizzazioni.
- Nel sistema di destinazione, esegui l'azione Pull Playbook in GitSync.
Creare chiavi SSH da utilizzare con GitSync
Innanzitutto, genera una coppia di chiavi. Quando ti viene richiesta una passphrase, premi Invio:
ssh-keygen -b 2048 -t rsa -f ./id_rsaVerranno creati due file: id_rsa (chiave privata) e id_rsa.pub (chiave pubblica). Conserva la chiave privata in un luogo sicuro.
Imposta la chiave pubblica nel repository. Ad esempio, in Bitbucket, inserisci le impostazioni del repository e fai clic su Chiavi di accesso. Fai clic su Aggiungi chiave e incolla i contenuti di id_rsa.pub nel parametro Chiave.
Prima di poter aggiungere la chiave privata alla configurazione dell'integrazione, deve essere codificata in Base64.
Utilizza questi comandi per codificare il file:
- Linux:
cat id_rsa | base64 -w 0 - Windows:
Apri PowerShell dove si trova id_rsa e incolla (si tratta di una sola riga):
Write-Output [System.Text.Encoding]::ASCII.GetString([convert]::ToBase64String(([IO.File]::ReadAllBytes((Join-Path (pwd) 'id_rsa')))))
- Linux:
- Copia il valore stampato nella proprietà di integrazione Password/Token/Chiave SSH e testa la connettività dell'integrazione.
Struttura delle directory del repository GitSync
Di seguito è riportata la struttura di directory prevista nel repository remoto.
* Questo è l'output comando tree per un repository di esempio. I commenti sono in rosso.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.