GitSync
O GitSync é uma integração robusta criada pela equipa de serviços profissionais do SOAR do Google Security Operations e concebida para sincronizar os componentes do SOAR do Google Security Operations com um repositório git. Usa as operações internas do git para escrever diretamente no próprio repositório, o que o faz funcionar como um serviço de armazenamento de ficheiros. Oferece métodos para realizar o seguinte:
Migre recursos entre instâncias SOAR do Google Security Operations
Faça uma cópia de segurança dos recursos SOAR do Google Security Operations
Documentação automática
Cria uma "loja" para partilhar recursos/conhecimentos
Controlo de versões
A integração consiste em várias tarefas SOAR do Google Security Operations: tarefas de envio e obtenção para cada recurso suportado e tarefas de envio/obtenção para toda a instância SOAR do Google Security Operations. Estas tarefas não precisam de ser executadas periodicamente, uma vez que foram criadas para serem executadas manualmente a partir do IDE, mas podem ser usadas como tarefas normais (por exemplo, carregar uma confirmação diária).
O GitSync usa a API SOAR do Google Security Operations para obter o recurso relevante, como uma integração ou uma família visual, e analisar todas as informações disponíveis desse recurso (estas informações são posteriormente renderizadas num ficheiro README.md que é normalmente apresentado quando navega no repositório). Em seguida, escreve a definição JSON do recurso e o ficheiro README renderizado no repositório local e envia-o para o repositório remoto.
Outra utilização do GitSync é a partilha de conhecimentos. Através desta integração, um repositório git pode funcionar como um "armazenamento" de recursos, como manuais de procedimentos ou definições de ontologia, que foram concebidos anteriormente e tiram partido das práticas recomendadas de SOAR do Google Security Operations para levar a plataforma ao seu melhor desempenho.
Pré-requisitos
Enviar/extrair um repositório existente:
Método de autenticação para o Git. É suportada uma combinação de nome de utilizador/palavra-passe (não recomendado), um token de acesso (recomendado) e uma chave privada SSH codificada em base64 (recomendado). Quando usar os dois últimos, o parâmetro username não é obrigatório.
Um utilizador local do SOAR do Google Security Operations. Usado para importar recursos. Este utilizador tem de ter autorização para escrever no módulo de destino (por exemplo, um utilizador sem acesso ao IDE não pode extrair integrações).
Crie um novo repositório
Todos os pontos mencionados na secção Enviar/extrair um repositório existente anteriormente.
Um repositório remoto. Recomendamos que tenha, pelo menos, 1 ficheiro no repositório. A maioria dos serviços Git oferece uma opção para criar um ficheiro README quando cria o repositório.
Configure a integração
Tem de configurar a integração como uma instância partilhada. Não pode ser associado a um ambiente existente no Google SecOps SOAR.
Propriedades de integração
Nome do parâmetro | Descrição |
URL do repositório | URL do repositório. Quando usar a autenticação de utilizador/palavra-passe, este valor tem de começar por https://. Se usar a autenticação SSH, este valor tem de começar por git@ ou ssh://. (Consulte Configurar URL do repositório e ramificação abaixo). |
Agência | O ramo no repositório com o qual sincronizar. |
Palavra-passe/token/chave SSH do Git | Método de autenticação para o git. Este valor pode ser a palavra-passe/token do Git ou a chave privada SSH. As chaves privadas devem ser codificadas em Base64. O RSA e o Ed25519 são suportados. |
Nome de utilizador do Git | Nome de utilizador do Git. Este valor não é obrigatório quando usa a autenticação SSH. |
Autor da consolidação |
Não é obrigatório. Dá a capacidade de especificar o autor da confirmação. Este valor tem de estar neste formato: Username |
Google Security Operations SOAR Verify SSL | Valide o SSL para a API SOAR do Google Security Operations |
Git Verify SSL | Valide o SSL com o serviço Git de destino |
Configurar o URL do repositório e a ramificação
Neste guia, vamos demonstrar como obter os valores certos no Bitbucket (tenha em atenção que o processo é o mesmo no GitHub).
Localize o repositório no Bitbucket.
Clique no botão clonar no canto superior direito (Código no GitHub)
Autenticação SSH: o URL do repositório é git@bitbucket.org:siemplifyproserv/connectors.git
Autenticação de utilizador/palavra-passe ou token: o URL do repositório é https://bitbucket.org/siemplifyproserv/connectors.git . (O nome de utilizador pode ser ignorado)
Verifique a ramificação atual (principal na imagem abaixo)
Exemplo de utilização
Cada tarefa no GitSync contém os seguintes parâmetros:
Nome | Descrição |
Específico da tarefa: nome do conetor, identificador de integração, lista de autorizações do manual de procedimentos, etc. | Estes parâmetros destinam-se a especificar o que é enviado ou extraído para o repositório. No GitSync, os recursos são referidos pelos respetivos identificadores. Estes valores são sensíveis a maiúsculas e minúsculas. |
URL do repositório e ramo | Adicionar suporte para vários repositórios com as mesmas credenciais. Depois de definir estes parâmetros, o repositório configurado na instância de integração é ignorado. |
Mensagem de consolidação | Quando envia recursos para o repositório, é necessária uma mensagem para a confirmação. Aqui, pode especificar o motivo do envio, indicando o que foi corrigido, alterado ou adicionado ao recurso. |
Suplemento Readme | Adiciona a capacidade de expandir a documentação dos recursos quando são enviados. Neste valor, pode usar:
O modelo é adicionado ao final da documentação e é guardado no ficheiro de metadados GitSync.json na raiz do repositório. |
Extrair recursos
Neste exemplo, vamos extrair um conector com os mapeamentos e as famílias visuais corretos.
- Primeiro, certifique-se de que o recurso está localizado no repositório configurado. Basta procurar nos diretórios do repositório e copiar o identificador do recurso (normalmente, é o nome do diretório ou o título do ficheiro README).
Exemplo de um repositório no Bitbucket, no diretório Connectors. Tenha em atenção que os diretórios são os nomes de integração e, no interior, encontram-se os identificadores reais dos conetores. Encontre o trabalho adequado no IDE do SOAR do Google Security Operations. Neste exemplo, vamos usar a tarefa Pull Connector.
Nota: quando extrai um conetor, verifique se a integração do conetor também está instalada.
Clique no separador de testes e configure os parâmetros. Uma vez que estamos a usar um repositório e já está configurado na instância de integração, vamos deixar os parâmetros URL do repositório e ramificação vazios e definir os outros parâmetros para os valores de que precisamos.
Execute a tarefa.
Consulte o resultado da depuração para ver o registo da operação. Se tudo correr bem, o registo indica-o.
- Aceda ao SOAR do Google Security Operations -> Conetores e configure o conetor.
Enviar recursos
Neste exemplo, vamos enviar um playbook e um bloco para o repositório.
Identifique os manuais de soluções que quer enviar. Aqui, vamos enviar um novo bloqueio denominado Início de sessão falhado e um manual atualizado denominado Atividade maliciosa.
Encontre o trabalho adequado no IDE do SOAR do Google Security Operations. Neste exemplo, vamos usar a tarefa Push Playbook.
Clique no separador de testes e configure os parâmetros.
- Uma vez que ambos estão na mesma pasta (Predefinição), também pode usar a lista de autorizações de pastas.
Execute a tarefa.
Consulte o resultado da depuração para ver o registo da operação. Se tudo correr bem, o registo indica-o.
Valide se o repositório contém as versões mais recentes dos manuais de procedimentos.
Criar um novo repositório
Para criar um novo repositório, apenas uma coisa é importante: incluir um único ficheiro no repositório antes de o configurar com o GitSync. Pode fazê-lo rapidamente incluindo um ficheiro README na raiz do repositório quando o cria.
Bitbucket
GitHub
Problemas conhecidos e limitações
Depois de o repositório ser definido pela primeira vez, usa uma estrutura de diretórios predefinida para garantir que sabe onde cada recurso está localizado. Se não seguir a estrutura de diretórios com uma confirmação personalizada ou alterações ao repositório, a integração vai funcionar incorretamente. Pode encontrar o esquema da estrutura de diretórios do repositório no final deste documento.
Tenha cuidado ao usar esta integração com repositórios públicos. Os recursos SOAR das operações de segurança da Google usam parâmetros que contêm IDs de aplicações, IDs de clientes, nomes de utilizadores e outras informações confidenciais. O GitSync não consegue determinar se o parâmetro é sensível ou não, pelo que todos os parâmetros que não sejam do tipo "Palavra-passe" são carregados para o repositório. Além disso, quando envia uma instância SOAR do Google Security Operations (tarefa de envio do ambiente), existe uma opção para confirmar palavras-passe. Esta opção indica ao GitSync que tente exportar todos os parâmetros de palavra-passe da configuração de integração. Não defina este valor como verdadeiro se o repositório for público, caso contrário, todas as credenciais serão divulgadas online.
Quando extrai uma instância SOAR do Google Security Operations (tarefa Pull Environment), a instalação de todas as integrações pode demorar mais de 5 minutos e a tarefa falha devido a um limite de tempo. Recomendamos que instale manualmente toda a integração comercial do Google Security Operations Marketplace antecipadamente para evitar problemas. No entanto, também é possível executar novamente a tarefa se falhar devido a um limite de tempo.
As integrações comerciais e as integrações personalizadas são processadas de forma diferente. A integração personalizada é enviada como a exportação ZIP completa da integração para uma operação de importação/exportação. As integrações comerciais são enviadas apenas com o código personalizado. Depois de extraído, o GitSync instala a versão mais recente da integração a partir do Google SecOps Marketplace e guarda o código personalizado na integração oficial.
Quando extrai mapeamentos, estes não são apresentados na tabela Definições -> Ontologia -> Estado da ontologia até que os eventos tenham sido efetivamente carregados no SOAR do Google Security Operations, porque ainda não foram indexados.
O repositório local é guardado em /opt/siemplify/siemplify_server/GitSyncFiles/{RepoName}. Uma vez que a integração escreve objetos Git e não ficheiros, esta pasta não representa o repositório e é substituída por quaisquer alterações feitas sempre que uma tarefa é executada. Recomendamos que use outro clone do repositório e não o criado pelo GitSync.
Os manuais de estratégias com autorizações restritas (por exemplo, autorizações predefinidas definidas como Pode ver) requerem uma configuração de autorizações específica no sistema de origem para uma sincronização bem-sucedida através do GitSync. Para mais informações, consulte o artigo Trabalhe com autorizações de manuais de procedimentos.
O Google SecOps suporta a utilização do GitSync para fazer uma cópia de segurança dos recursos de SOAR. No entanto,o Google SecOps não suporta a utilização do GitSync para *distribuir* recursos de SOAR entre sistemas. Isto pode levar a resultados inesperados, uma vez que os objetos da base de dados podem não ser exclusivos.
Trabalhe com autorizações do manual de estratégias
Quando usa o GitSync para sincronizar manuais de procedimentos com autorizações restritas (por exemplo, autorizações predefinidas definidas como Pode ver ou outras definições não predefinidas), pode ocorrer um erro no sistema de destino se não tiver autorização para modificar o manual de procedimentos. Isto acontece porque o GitSync usa uma chave da API do sistema interna com a função Administrator SOC para realizar ações. Para garantir a sincronização bem-sucedida dos manuais de procedimentos com autorizações restritas, conceda as autorizações Administrator da função SOC Pode
editar no sistema de origem para esses manuais de procedimentos.
Ative o GitSync para obter manuais de procedimentos com autorizações restritas
- No sistema de origem:
- Aceda ao manual que quer sincronizar com o GitSync.
- Abra as definições de autorizações do manual de estratégias.
- Certifique-se de que a
Administratorfunção SOC é adicionada à lista de entidades com autorizações Pode editar.
- Depois de ajustar as autorizações no sistema de origem, execute a ação Enviar Playbook no GitSync para atualizar o repositório Git com o playbook e as respetivas autorizações.
- No sistema de destino, execute a ação Pull Playbook no GitSync.
Crie chaves SSH para usar com o GitSync
Primeiro, gere um par de chaves. Quando lhe for pedida uma frase de acesso, prima Enter:
ssh-keygen -b 2048 -t rsa -f ./id_rsaSão criados dois ficheiros: id_rsa (chave privada) e id_rsa.pub (chave pública). Mantenha a chave privada num local seguro.
Defina a chave pública no repositório. Por exemplo, no Bitbucket, introduza as definições do repositório e clique em Chaves de acesso. Clique em Adicionar chave e cole o conteúdo de id_rsa.pub no parâmetro Key.
Antes de poder adicionar a chave privada à configuração da integração, esta deve ser codificada em Base64.
Use estes comandos para codificar o ficheiro:
- Linux:
cat id_rsa | base64 -w 0 - Windows:
Abra o PowerShell onde id_rsa está localizado e cole (esta é uma linha):
Write-Output [System.Text.Encoding]::ASCII.GetString([convert]::ToBase64String(([IO.File]::ReadAllBytes((Join-Path (pwd) 'id_rsa')))))
- Linux:
- Copie o valor impresso para a propriedade de integração Password/Token/SSH Key e teste a conetividade da integração.
Estrutura do diretório do repositório GitSync
Segue-se a estrutura de diretórios esperada no repositório remoto.
* Este é um resultado do comando tree para um repositório de exemplo. Os comentários estão a vermelho.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.