GitSync
O GitSync é uma integração robusta criada pela equipe de serviços profissionais do Google Security Operations SOAR e projetada para sincronizar componentes do Google Security Operations SOAR com um repositório Git. Ele usa as operações internas do git para gravar diretamente no próprio repositório, fazendo com que ele funcione como um serviço de armazenamento de arquivos. Ele fornece métodos para realizar o seguinte:
Migrar recursos entre instâncias do Google Security Operations SOAR
Fazer backup dos recursos do Google Security Operations SOAR
Documentação automática
Cria uma "loja" para compartilhar recursos/conhecimento
Controle de versões
A integração consiste em vários jobs de SOAR do Google Security Operations: jobs de push e pull para cada recurso compatível e jobs de push/pull para toda a instância de SOAR do Google Security Operations. Esses jobs não precisam ser executados periodicamente, já que foram criados para serem executados manualmente no ambiente de desenvolvimento integrado (IDE, na sigla em inglês), mas podem ser usados como jobs regulares (por exemplo, fazer upload de um commit diário).
O GitSync usa a API SOAR do Google Security Operations para buscar o recurso relevante, como uma integração ou uma família visual, e analisar todas as informações disponíveis desse recurso. Essas informações são renderizadas posteriormente em um arquivo README.md, que geralmente é exibido ao navegar pelo repositório. Em seguida, ele grava a definição JSON do recurso e o README renderizado no repositório local e envia para o repositório remoto.
Outro uso do GitSync é o compartilhamento de conhecimento. Com essa integração, um repositório git pode funcionar como um "armazenamento" de recursos, como playbooks ou configurações de ontologia, que foram projetados antes e aproveitam as práticas recomendadas de SOAR do Google Security Operations para impulsionar a plataforma ao máximo.
Pré-requisitos
Como enviar/extrair um repositório atual:
Método de autenticação no Git. As opções compatíveis são uma combinação de nome de usuário/senha (não recomendada), um token de acesso (recomendado) e uma chave privada SSH codificada em base64 (recomendada). Ao usar os dois últimos, o parâmetro "username" não é obrigatório.
Um usuário local do Google Security Operations SOAR. Usado para importar recursos. Esse usuário precisa ter permissão para gravar o módulo de destino. Por exemplo, um usuário sem acesso à IDE não pode extrair integrações.
Criar um novo repositório
Todos os pontos mencionados em "Como enviar/extrair um repositório atual" acima.
Um repositório remoto. Recomendamos que você tenha pelo menos um arquivo no repositório. A maioria dos serviços do Git oferece uma opção para criar um arquivo README ao criar o repositório.
Configurar a integração
Você precisa configurar a integração como uma instância compartilhada. Não pode estar conectado a um ambiente atual no Google SecOps SOAR.
Propriedades de integração
Nome do parâmetro | Descrição |
URL do repositório | URL do repositório. Ao usar a autenticação de usuário/senha, esse valor precisa começar com https://. Se você estiver usando a autenticação SSH, esse valor precisará começar com git@ ou ssh://. Consulte "Configurar URL do repositório e ramificação" abaixo. |
Ramificação | A ramificação no repositório para sincronizar. |
Senha/token/chave SSH do Git | Método de autenticação para o Git. Esse valor pode ser senha/token do Git/chave privada SSH. As chaves privadas precisam ser codificadas em base64. RSA e Ed25519 são compatíveis. |
Nome de usuário do Git | Nome de usuário do Git. Esse valor não é obrigatório ao usar a autenticação SSH. |
Autor da confirmação |
Não é obrigatório. Permite especificar o autor do commit. Esse valor precisa estar neste formato: Nome de usuário |
Google Security Operations SOAR: verificar SSL | Verificar SSL para a API SOAR do Google Security Operations |
Git Verify SSL | Verificar o SSL com o serviço Git de destino |
Como configurar o URL e a ramificação do repositório
Neste guia, vamos mostrar como conseguir os valores certos no Bitbucket. 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 por usuário/senha ou token: o URL do repositório é https://bitbucket.org/siemplifyproserv/connectors.git . (O nome de usuário pode ser ignorado)
Verifique a ramificação atual (mestre na imagem abaixo)
Exemplo de uso
Cada job no GitSync contém os seguintes parâmetros:
Nome | Descrição |
Específicos do job: nome do conector, identificador de integração, lista de permissões de playbook etc. | Esses parâmetros especificam o que é enviado ou extraído para o repositório. No GitSync, os recursos são referenciados pelos identificadores. Esses valores diferenciam maiúsculas de minúsculas. |
URL e ramificação do repositório | Adicione suporte a vários repositórios com as mesmas credenciais. Depois que esses parâmetros forem definidos, o repositório configurado na instância de integração será ignorado. |
Mensagem de confirmação | Ao enviar recursos para o repositório, uma mensagem é necessária para o commit. Aqui você pode especificar o motivo do push, indicando o que foi corrigido, mudado ou adicionado ao recurso. |
Complemento Readme | Adiciona a capacidade de estender a documentação dos recursos quando enviados. Nesse valor, é possível usar:
O modelo é adicionado ao final da documentação e salvo no arquivo 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, verifique se o recurso está no repositório configurado. Basta navegar pelos diretórios do repositório e copiar o identificador do recurso. Geralmente, é o nome do diretório ou o título do arquivo README.
Exemplo de um repositório no Bitbucket, no diretório "Connectors". Os diretórios são os nomes de integração, e dentro deles estão os identificadores reais dos conectores. Encontre o trabalho adequado no ambiente de desenvolvimento integrado (IDE) do SOAR do Google Security Operations. Neste exemplo, vamos usar a tarefa "Pull Connector".
Observação: ao extrair um conector, verifique se a integração dele também está instalada.
Clique na guia "Testes" e configure os parâmetros. Como estamos usando um repositório que 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 com os valores necessários.
Execute o job.
Consulte a saída de depuração para o registro da operação. Se tudo correr bem, o log vai indicar isso.
- Acesse o Google Security Operations SOAR -> Conectores e configure o conector.
Envio de recursos
Neste exemplo, vamos enviar um playbook e um bloco para o repositório.
Identifique os playbooks que você quer enviar. Aqui, vamos enviar um novo bloco chamado "Falha no login" e um playbook atualizado chamado "Atividade maliciosa".
Encontre o trabalho adequado no ambiente de desenvolvimento integrado (IDE) do SOAR do Google Security Operations. Neste exemplo, vamos usar o job "Push Playbook".
Clique na guia "Testes" e configure os parâmetros.
- Como ambos estão na mesma pasta (padrão), você também pode usar a lista de permissões de pastas.
Execute o job.
Consulte a saída de depuração para o registro da operação. Se tudo correr bem, o log vai indicar isso.
Valide se o repositório contém as versões mais recentes dos playbooks.
Como criar um repositório
Para criar um repositório, apenas uma coisa é importante: incluir um único arquivo no repositório antes de configurá-lo com o GitSync. Isso pode ser feito rapidamente incluindo um arquivo README na raiz do repositório ao criá-lo.
Bitbucket
GitHub
Limitações e problemas conhecidos
Depois que o repositório é definido pela primeira vez, ele usa uma estrutura de diretório predefinida para garantir que saiba onde cada recurso está localizado. Se a estrutura de diretórios não for seguida com um commit personalizado ou mudanças no repositório, a integração vai apresentar falhas. Confira o esquema da estrutura de diretórios do repositório no final deste documento.
Tenha cuidado ao usar essa integração com repositórios públicos. Os recursos do SOAR do Google Security Operations usam parâmetros que contêm IDs de aplicativos, IDs de clientes, nomes de usuários e outras informações sensíveis. O GitSync não consegue saber se o parâmetro é sensível ou não. Por isso, todos os parâmetros que não são do tipo "Senha" são enviados ao repositório. Além disso, ao enviar uma instância do SOAR do Google Security Operations (job de envio de ambiente), há uma opção para confirmar senhas. Essa opção instrui o GitSync a tentar exportar todos os parâmetros de senha da configuração de integração. Não defina esse valor como "true" se o repositório for público. Caso contrário, todas as credenciais serão vazadas on-line.
Ao extrair uma instância do SOAR do Google Security Operations (job "Extrair ambiente"), a instalação de todas as integrações pode levar mais de cinco minutos, e o job vai falhar com um tempo limite. Recomendamos instalar manualmente todas as integrações comerciais do Google Security Operations Marketplace para evitar problemas. No entanto, também é possível executar o job novamente se ele falhar com um tempo limite.
As integrações comerciais e personalizadas são processadas de maneira diferente. A integração personalizada será enviada como a exportação completa em ZIP da integração para uma operação de importação/exportação. As integrações comerciais serão enviadas apenas com o código personalizado. Depois de extraído, o GitSync vai instalar a versão mais recente da integração no Google SecOps Marketplace e salvar o código personalizado na integração oficial.
Ao extrair mapeamentos, eles não aparecem na tabela "Configurações" > "Ontologia" > "Status da ontologia" até que os eventos sejam ingeridos no SOAR do Google Security Operations, porque ainda não foram indexados.
O repositório local é salvo em /opt/siemplify/siemplify_server/GitSyncFiles/{RepoName}. Como a integração grava objetos do Git e não arquivos, essa pasta não representa o repositório e é substituída por qualquer mudança feita sempre que um job é executado. Recomendamos usar outro clone do repositório, não o criado pelo GitSync.
Os playbooks com permissões restritas (por exemplo, permissões padrão definidas como Pode visualizar) exigem uma configuração de permissão específica no sistema de origem para uma sincronização bem-sucedida pelo GitSync. Para mais informações, consulte Trabalhar com permissões de playbook.
O Google SecOps oferece suporte ao uso do GitSync para fazer backup de recursos do SOAR. No entanto,o Google SecOps não oferece suporte ao uso do GitSync para *distribuir* recursos de SOAR entre sistemas. Isso pode levar a resultados inesperados porque os objetos do banco de dados podem não ser exclusivos.
Trabalhar com permissões de playbook
Ao usar o GitSync para sincronizar playbooks com permissões restritas (por exemplo, permissões padrão definidas como Pode visualizar ou outras configurações não padrão), talvez ocorra um erro no sistema de destino se ele não tiver autorização para modificar o playbook. Isso acontece porque o GitSync usa uma chave de API interna do sistema com a função Administrator SOC para realizar ações. Para garantir a sincronização bem-sucedida de playbooks com permissões restritas, conceda à função do SOC Administrator as permissões Pode editar no sistema de origem para esses playbooks.
Ativar o GitSync para extrair playbooks com permissões restritas
- No sistema de origem:
- Acesse o playbook que você quer sincronizar com o GitSync.
- Abra as configurações de permissões do playbook.
- Verifique se a função
Administratordo SOC foi adicionada à lista de entidades com permissões de Edição.
- Depois de ajustar as permissões no sistema de origem, execute a ação Enviar playbook no GitSync para atualizar o repositório Git com o playbook e as permissões dele.
- No sistema de destino, execute a ação Extrair playbook no GitSync.
Criar chaves SSH para usar com o GitSync
Primeiro, gere um par de chaves. Quando uma senha longa for solicitada, pressione Enter:
ssh-keygen -b 2048 -t rsa -f ./id_rsaDois arquivos serão criados: id_rsa (chave privada) e id_rsa.pub (chave pública). Mantenha a chave privada em um local seguro.
Defina a chave pública no repositório. Por exemplo, no Bitbucket, insira as configuraçõ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 "Chave".
Antes de adicionar a chave privada à configuração de integração, ela precisa ser codificada em Base64.
Use estes comandos para codificar o arquivo:
- 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 "Senha/Token/Chave SSH" e teste a conectividade da integração.
Estrutura de diretórios do repositório GitSync
Esta é a estrutura de diretórios esperada no repositório remoto.
* Esta é uma resposta ao comando "tree" para um repositório de exemplo. Os comentários estão em vermelho.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.