Guia completo de SOC

Embora a defesa cibernética seja um tema extremamente aprofundado, existem certas mentalidades, modelos, fontes de dados e técnicas que podem fazer qualquer equipe começar o SOC da maneira certa.  

Este guia é uma coleção de alguns dos mais úteis informações e modelos para quem trabalha em segurança cibernética centros de operações, bem como indicações para alguns poderosas ferramentas gratuitas, referências de livros e muito mais para ajudar construa sua equipe, habilidades e capacidades defensivas. 

Funções do SOC 

Ao detalhar como funciona um Centro de Operações de Segurança, pode ser útil para decompor o fluxo de trabalho complexo de eventos em funções atômicas para que cada um pode ser estudado. Em qualquer sistema complexo (incluindo SOCs), cada função de um processo tem um conjunto específico de entradas e saídas que podem ser generalizadas, compreendido e medido para avaliar se esse componente está funcionando como pretendido.  

Dividir os componentes e tarefas de um SOC desta forma ajuda descrever em detalhes claros exatamente o que uma equipe de segurança deve fazer para ter sucesso, bem como outros grupos e funções interagem com as funções principais do SOC fornecendo todos os serviços necessários para o sucesso na defesa cibernética. 

A seguir está uma lista das funções principais do SOC – tarefas que normalmente se enquadram a organização “SOC”, embora isso possa, é claro, variar de equipe para equipe dependendo de uma série de fatores. Cada um está listado com entradas, saídas e objetivos da função, bem como interações com outros grupos. “Funções auxiliares” também estão listados.  

Esses são recursos que menos comumente se enquadram no SOC organização diretamente, mas muitas vezes operam em estreita colaboração com as operações de segurança equipe para garantir que a organização esteja segura. 

Funções principais do SOC 

A seguir estão as partes desconstruídas da execução de um Centro de Segurança de Operações, e são listadas como atividades “principais” que a defesa cibernética média equipe é responsável. A seção a seguir discutirá cada função, seus objetivos e como prever a eficácia dessa função. 

Coleção 

A primeira etapa do processo é a coleta. Esta etapa envolve registrar a segurança de eventos relevantes (qualquer evento útil e observável, mas não necessariamente malicioso atividade) no ambiente. Gravando todos os eventos, como tráfego da web, logins e mais é necessário para detectar atividades anômalas que podem ser usadas para identificar ataques em andamento.  

Os tipos de dados específicos que você coleta devem ser guiado pela sua inteligência de ameaças, que deve informar quais tipos de eventos e logs são necessários para detectar ataques. Na maioria dos SOCs, uma análise completa estratégia de coleta exigirá cooperação entre múltiplas equipes e orçamento para o hardware e software necessários para atender aos requisitos de visibilidade. 

A saída deste estágio são eventos que podem ser logs, metadados de tráfego de rede, ou outras informações derivadas sobre o que ocorreu em um determinado dispositivo ou segmento de rede.  

Esses dados normalmente são gerados em um endpoint dispositivo como um log ou coletado/gerado a partir do tráfego de rede observado diretamente por um dispositivo de rede ou por meio de tap de rede ou porta de espelho de switch. 

Os dados coletados são idealmente centralizados e enviados para um SIEM para correlação, aplicação de regras analíticas e armazenamento de longo prazo. O objetivo desta etapa é uma coleta completa de todos os dados relevantes para a segurança que podem então ser usados na próxima etapa para análise de detecção.  

A eficácia de um SOC neste estágio estará diretamente relacionada à sua capacidade de identificar casos de uso de segurança e as principais fontes de dados que indicariam que um ataque está em andamento. 

Detecção 

Após a etapa de coleta vem a etapa de detecção. Nesta função o objetivo é identificar, com a maior precisão possível (sem perder nada ou gerar falsos positivos), todos os eventos observados que podem indicar um ataque potencial. Esse acontece de duas maneiras principais, de forma reativa e proativa. Reativo e automático as detecções são aplicadas por mecanismos de análise no SIEM, na rede ou no endpoint. 

As detecções também são feitas por analistas que pesquisam proativamente os dados por meio de caça a ameaças (consulte a seção de caça a ameaças mais adiante neste guia para detalhes adicionais).  

O objetivo desta etapa é encontrar todas as atividades verdadeiramente maliciosas e receba um alerta relacionado a ele na fila de triagem para ação da equipe de segurança. 

A eficácia de um SOC nesta fase está correlacionada com a qualidade das ferramentas empregadas, bem como a força da ameaça do SOC capacidades de caça, informações de inteligência sobre ameaças (feeds e inteligência gerada internamente) e funções de engenharia de detecção. 

A detecção bem-sucedida depende naturalmente dos dados disponíveis a etapa de coleta. Quanto melhor sua função de coleta estiver operando, melhor sua função de detecção pode funcionar, e ele se aplica à qualidade das assinaturas produzidas por engenheiros analíticos e de inteligência sobre ameaças. 

Triagem 

Uma vez que a etapa de detecção tenha gerado alertas sobre os eventos de interesse, esses alertas são todos encaminhados para uma ou mais filas para triagem. Neste estágio, os analistas SOC devem classificar todos as atividades potencialmente maliciosas geradas pela função de detecção e determinar a ordem de importância na qual avaliar cada alerta.  

A ordem de triagem geralmente é baseada em fatores como a distância que o ataque pode ter já progrediu, a criticidade do sistema que está sendo atacado, o privilégio da conta que pode estar comprometida e/ou se parece ser um ataque único ou direcionado.  

Semelhante a uma sala de emergência de um hospital, o o objetivo do analista nesta etapa é enfileirar corretamente os itens a serem investigados em uma ordem lógica de prioridade de acordo com os dados apresentados. Analistas eficazes fazem isso combinando seu conhecimento de conceitos como o Lockheed Martin Cyber Kill Chain e TTPs de invasores como aqueles na estrutura MITRE ATT&CK técnicas táticas – com sua experiência anterior em defesa.  

Como os alertas são muitas vezes complexos de interpretar e difíceis de compreender claramente na sua forma bruta, a eficácia nesta fase é em grande parte determinada pelo nível de detalhe e contexto fornecido pelas ferramentas de segurança aos analistas enquanto eles fazem a triagem de alertas. 

Investigação 

Depois que um alerta é selecionado na fila de triagem, os analistas do SOC investigam o alerte com mais detalhes para verificar se algo ruim realmente está acontecendo. Tantos SOCs sofrem com análises excessivamente sensíveis e lógica de alerta desafinada, isso pode ser um passo isso muitas vezes leva a uma determinação de falso positivo e à rejeição do alerta. 

Para chegar à verdade sobre o assunto, os analistas devem tomar o alerta fornecido dados e usar suas habilidades de análise e qualquer evidência adicional que puderem encontrar para avaliar se o alerta identificou corretamente um ataque. Esse pode envolver a coleta de dados de sensores de rede adicionais ou registros de múltiplas fontes ou realizando pesquisas de inteligência de código aberto.  

O objetivo desta etapa é a verificação precisa se um alerta é verdadeiro ou falso positivo. Quando ocorrem falsos positivos, é aconselhável que os analistas identifiquem imediatamente o motivo do erro e alimente essas informações de volta à equipe de engenharia de detecção para corrigir as regras de alerta. 

Os analistas devem ser treinados para realizar a etapa de investigação de forma estruturada e rigorosa, evitando preconceitos cognitivos e outros erros que podem ocorrer ao realizar uma investigação intuitivamente.  

A eficácia nesta fase está relacionada com múltiplos fatores – experiência de o analista, técnica de análise, disponibilidade de dados e tecnologia e automação que ajuda a gerar e apresentar evidências aos analistas. 

Resposta a incidentes 

A função de resposta a incidentes (ou equipe, quando separada) recebe notificação de alertas que foram investigados e qualificados como situação isso deve ser tratado. O objetivo deste estágio é definir o escopo, conter e erradicar o problema o mais rápido possível e, finalmente, recuperar-se o incidente com um mínimo de danos. 

Dependendo da gravidade do problema, esta atividade pode variar desde pequenas remoções de vírus até investigações de meses de duração com perícia, envolvimento da aplicação da lei, e muito mais.  

No SOC, ferramentas de coleta e geração de dados como EDR/ O registro de NDR e SIEM centralizado ajuda analistas e respondedores de incidentes consultar rapidamente eventos de rede e endpoint e definir o escopo do problema e a extensão do mesmo e, em seguida, determinar o cronograma do incidente.  

As saídas de uma função de resposta a incidentes devem ser tanto remediação do incidente e lições aprendidas sobre como prevenir esse tipo de problema no futuro. Os detalhes do ataque pós-incidente devem ser categorizados por métricas e alimentados com inteligência de ameaças para correlação com ataques anteriores e futuros, a fim de construir perfis de grupos de ameaças. 

Rastrear padrões e detalhes de incidentes a longo prazo ajuda a fornecer o SOC uma vantagem tática e estratégica em ataques subsequentes. 

Funções auxiliares do SOC 

Os seguintes grupos geralmente fazem parte da organização SOC ou trabalhar em estreita colaboração com ele para ajudar a cumprir a missão de defesa cibernética. 

• Inteligência de ameaças – As equipes de inteligência de ameaças devem trabalhar em estreita colaboração com o SOC para informá-los sobre quais grupos adversários existem, o que eles querem e quais têm maior probabilidade de se interessar pela sua organização. Em última análise, devem ajudar a priorizar controles, ferramentas defensivas e estratégias de detecção, e garantir que a equipe se concentre nas áreas certas para esforços defensivos.
• Perícia – amplamente focada em auxiliar na fase de resposta a incidentes, equipes forenses e especialistas ajudam a encontrar a verdade durante um incidente usando conhecimento especializado de como a atividade em uma máquina pode deixe evidências datáveis. Como a ciência forense é um tema tão profundo por si só, muitas vezes é considerada sua própria posição e área de conhecimento especializada.
• Teste de penetração/Red Teaming – Esses grupos ajudam a verificar os SOCs pessoas, processos e tecnologia simulando ataques. Os testes podem ser anunciados ou não, e cada tipo de teste pode ser focado em responder perguntas específicas sobre a postura e a capacidade do SOC de reagir a um ataque realista, com que rapidez os incidentes podem ser identificados e se a equipe recebeu o treinamento necessário para identificá-los.
• Gerenciamento de vulnerabilidades – O gerenciamento de vulnerabilidades deve trabalhar em estreita colaboração com o SOC, em grande parte para disponibilizar os resultados das varreduras de forma que o SOC pode detectar quando uma tentativa de exploração foi tentada contra um sistema que podem ser vulneráveis a ele. Saber que ocorreu uma tentativa de exploração que é provavelmente funcionou é um componente-chave para priorizar os esforços de triagem.

Ferramentas SOC 

No SOC existem vários sistemas que receberão uso quase constante. Os sistemas nesta seção são as ferramentas às quais os analistas SOC se referirão, usarão ou procurando em quase todos os alertas que investigam ou incidente que eles cobrem. 

Visão geral das ferramentas SOC 

As ferramentas SOC trabalham juntas para orquestrar o fluxo de trabalho dos dados coletados registros recebidos, detecção e investigação de eventos suspeitos e o rastreamento, trabalho e coleta de métricas para cada incidente. O diagrama mostra como cada sistema individual descrito nesta seção funciona com outros Ferramentas SOC e o tipo de dados comumente trocados entre elas. 

Observe que essas são funções lógicas separadas para discussão separada. No seu ambiente, eles podem estar integrados em um único sistema – alguns SIEMs possuem recursos integrados de gerenciamento de incidentes, por exemplo. 

O conjunto de ferramentas principais do analista consiste em: 

• SIEM – O nexo de todos os dados de log coletados em todo o ambiente.
• Plataforma de inteligência contra ameaças – seja uma solução dedicada ou construída em outro de seus outros produtos, uma plataforma de inteligência de ameaças deve fornecer aos analistas o contexto em torno de quaisquer indicadores de compromisso correspondentes (IOCs) encontrados no meio ambiente e os adversários por trás de seu uso.
• Sistema de gerenciamento de incidentes – Os analistas do sistema de tickets usarão este sistema para fazer triagem de alertas e/ou incidentes, redigindo relatórios sobre o que ocorreu e, finalmente, encerrando e categorizar investigações de incidentes concluídas.

SIEM 

Se fosse necessário apontar uma única ferramenta de particular importância para a segurança equipe acertar, seria Segurança de Informações e Gerenciamento de Eventos (SIEM). O SIEM está na melhor posição para ver e correlacionar quase todos os dados de todo o ambiente. É o ponto de centralização de todos os eventos e alertas registrados pelo log de segurança e muitas vezes integrados a outras ferramentas para armazenar contexto sobre informações de ativos, informações de verificação de vulnerabilidades e muito mais. 

Nenhuma outra ferramenta no ambiente tem esse escopo de dados para trabalhar, o que significa que o SIEM está em uma posição excepcionalmente poderosa em sua pilha de segurança. 

A principal função do SIEM é receber fielmente todos os logs e analisá-los corretamente nos campos de interesse, potencialmente enriquecendo e correlacionando as informações no processo. Depois, os campos analisados são indexados em algum tipo de banco de dados para recuperação rápida. São esses dados que você pode então pesquise, alerte ou crie visualizações e relatórios rapidamente. 

Plataforma de inteligência de ameaças 

Outra ferramenta SOC importante é a Plataforma de Inteligência de Ameaças (TIP). Em cada SOC deve haver uma lista mestra de todos os domínios, hashes, endereços IP, etc., que devem ser comparados com todos os eventos de rede e endpoint.  

Em muitos casos, o TIP é onde essas informações são armazenadas, e o TIP serve como “fonte da verdade” para os COIs se igualarem. Para fazer isso, todos os indicadores atômicos devem ser exportados periodicamente para o SIEM, IDS ou qualquer outra ferramenta utilizada para combinar os dados, para que uma lista de observação atualizada possa ser aplicada aos eventos que são observados.  

Ao mesmo tempo, a plataforma de inteligência sobre ameaças provavelmente estar recebendo informações de fornecedores externos de informações sobre ameaças, bem como qualquer informação produzido dentro da equipe de inteligência sobre ameaças ou do SOC, com base em incidentes reais. 

Um TIP deve conter mais informações do que apenas uma lista de indicadores atômicos. Se um alerta dispara dizendo “Threat Intel Match – Malicious IP Contacted”, um o analista precisará descobrir por que esse IP foi marcado como ruim. Se o TIP for apenas uma lista de IPs “ruins” atômicos sem contexto, eles não terão direção a seguir a investigação. O TIP, portanto, idealmente deveria conter informações relacionado a cada indicador atômico que pode informar um analista como, quando, e porque cada item atômico foi marcado como um IOC.  

Se os analistas puderem acessar a plataforma e ver “Este IP estava relacionado ao APT1234 e foi usado para malware X na campanha Y em 4 de julho de 2020”, eles agora têm um próximo passo claro para validar o alerta e potencialmente correlacioná-lo com ataques anteriores. 

Sistema de gerenciamento de incidentes 

Para o Sistema de Gestão de Informação (IMS), a principal fonte de entrada dados são alertas enviados a partir do SIEM ou de outras ferramentas de segurança (a menos que você faça a triagem alertas diretamente em sua ferramenta SIEM ou SOAR ou em produtos de ponto de segurança separados).  

Os analistas usam o IMS para fazer a triagem de alertas e também para trabalhar em incidentes ativos. Para faça isso da maneira mais eficaz possível, integrações com sua plataforma TIP e SOAR pode ajudar a tornar a pesquisa e correlação de informações adicionais rápida e indolor. 

Depois que os incidentes são investigados, remediados e encerrados, os analistas fecham o ticket associado. Ao fazer isso, um item chave que não deve ser ignorado é a categorização do incidente para fins de métricas. Essas métricas podem então idealmente, ser extraído automaticamente no final de cada semana e os gerentes do SOC podem usar as tendências observadas para fornecer feedback sobre onde o orçamento adicional pode ser melhor gasto para proteger a empresa. Como os analistas muitas vezes gastam quase o dia todo em um IMS, é outro software importante a ser escolhido com cuidado. 

Coleção de dados-chave 

A defesa cibernética de alto desempenho não é de forma alguma uma tarefa fácil. Coletando e aplicando um conjunto de detecções em constante mudança a montanhas de dados de streaming requer inteligência contra ameaças, uma pilha de tecnologia capaz e uma equipe qualificada por trás de tudo.  

No centro de qualquer SOC está uma coleta de dados massiva e complexa operação. Como as equipes precisam de dados sobre eventos de rede e de host, obter os dados corretos é um dos primeiros desafios que qualquer equipe deve enfrentar. 

Tipos de dados 

As informações coletadas podem ser divididas em dois campos principais – dados de monitoramento de segurança de rede e dados de monitoramento de endpoint (ou dados contínuos monitoramento de segurança, como às vezes é chamado).  

Esses dados são coletados de todos os pontos da rede e grande parte dela é centralizada em um SIEM para pesquisa, visualização, busca de anomalias e relatórios convenientes. 

 O as páginas seguintes detalharão cada tipo de dados e descreverão as principais fontes para cada um que deve ser coletado para fornecer às suas operações de segurança equipe a melhor chance possível de sucesso para detecção avançada de ataques. 

Registros de fluxo 

Os registros de fluxo são o nível mais alto de registros de monitoramento de segurança de rede, descrevendo principalmente detalhes das camadas 3 e 4 do OSI (TCP/IP), bem como detalhes de tempo.  

As vantagens dos logs de fluxo são que eles normalmente estão facilmente disponíveis para as equipes de segurança porque são frequentemente usados por equipes de operações de rede para desempenho monitoramento e ocupam relativamente pouco espaço para armazenar devido aos seus dados limitados.  

A desvantagem dos logs de fluxo é que eles geralmente não são detalhados o suficiente para realmente determinar se existe ou não um ataque potencial, a menos que sejam sendo usado para combinar IOCs, como endereços IP ou para localizar anomalias de tráfego. 

Ferramentas e formatos comuns: registros baseados em texto produzidos por ferramentas como Zeek ou Suricata ou formatos proprietários como NetFlow, JFlow, NetStream, registros de conexão Zeek, sFlow, etc. 

Útil para criação de perfil: 

• Volume de tráfego/largura de banda 

• Início, parada e duração das conexões 

• IPs de origem e destino da conversa 

• Portas de origem e destino 

• Protocolos (sob a suposição de que as portas são usadas com serviços típicos – não é uma garantia) 

Dados de transação 

Os dados de transação (também chamados de logs de serviço de rede) fluem dados em nível de log e os estende até a camada 7 do OSI, a camada de aplicativo. 

Este tipo de dados é produzido por ferramentas que analisam o pacote completo e fazem uma análise verdadeira dos protocolos em uso e do detalhamento das informações. Esse a análise fornece informações sobre certificados TLS, transações HTTP e muito mais, e é muito mais útil para identificar ataques, uma vez que muitos IOCs coletados por um SOC para correspondência (como hashes, nomes de domínio, detalhes de certificados TLS, agentes de usuários e muito mais) só se tornam visíveis ao analisar o tráfego neste nível de profundidade.  

Os SOCs devem se esforçar para coletar, no mínimo, dados de transações, já que os dados da transação ainda são um log baseado em texto que é apenas um pouco maior que logs de fluxo e, portanto, podem ser gerados e armazenados de forma relativamente barata. 

Ferramentas e formatos comuns: Logs baseados em texto produzidos por ferramentas como Zeek, Suricata, inúmeras soluções de monitoramento de rede comercial e NDR. 

Útil para criação de perfil: 

• Tudo, desde a seção de logs de fluxo até… 

• Protocolos da camada de aplicação em uso 

• Detalhes da camada de sessão e apresentação (exemplo: detalhes do certificado TLS) 

• Detalhes das conversas da camada de aplicação (exemplo: HTTP métodos, agentes de usuário, URLs, nomes de host e muito mais) 

• Possíveis correspondências para IOCs sabidamente maliciosos 

Captura completa de pacotes 

Às vezes, mesmo os metadados da camada de aplicação não são suficientes para fazer uma declaração verdadeira/ chamada de falso positivo durante uma investigação de incidente. Nestes casos, pacote completo a captura fornece cada byte enviado pela rede e pode ser usada por equipes de segurança para descobrir a verdade sobre o que aconteceu em uma investigação. 

Existem dois grandes problemas comuns com a captura completa de pacotes – criptografia e o tamanho dos dados. A criptografia pode tornar a captura de pacotes muito menor útil, a menos que a descriptografia TLS seja usada para decodificá-lo antes da gravação (se você fizer não possui recursos de descriptografia, filtros estilo BPF podem ser usados para não registrar dados que de outra forma seriam inúteis). 

Devido à natureza de conteúdo completo do pacote captura, os dados também são significativamente maiores em tamanho em comparação com o fluxo e registros de transações. Portanto, os períodos de retenção para captura de pacotes normalmente ser significativamente mais curto do que para logs de transações e fluxos.  

Observe que embora a captura de pacotes era difícil de adquirir para serviços em nuvem no passado, a maioria plataformas já criaram soluções para captura de pacotes para ativos em nuvem. 

Ferramentas e formatos comuns: PCAP e PCAP-NG são de longe os predominantes formatos de armazenamento para dados completos de captura de pacotes. Ferramentas para registrar captura de pacotes continuamente são numerosos tanto em código aberto quanto comercialmente. 

As opções gratuitas incluem ferramentas como Moloch, Google Stenographer e netsniffing usado por distribuições NSM, como Security Onion. Para nuvem serviços Amazon VPC Traffic Mirroring, Azure Network Watcher e Google O espelhamento de pacotes do GCP pode fornecer visibilidade ao tráfego de rede na nuvem. 

Útil para criação de perfil: 

• Tudo, desde registros de fluxo e transações até… 

• Análise completa de conteúdo de pacotes (exemplo: conteúdo do corpo HTTP GET/POST) 

• Gravação de arquivos transferidos e malware para análise 

• Análise forense detalhada de transações de rede 

• Análise aprofundada de protocolo 

• Resposta avançada a incidentes e engenharia reversa de ataque 

Oportunidades de coleta de tráfego 

Como tipos de dados com níveis mais altos de detalhe podem ser usados para criar os tipos de dados de nível de detalhe inferior, um único feed de captura de pacote pode ser usado para criar captura completa de pacotes, logs de transações e registros de fluxo.  

Se sua equipe não possui taps de rede ou portas espelhadas disponíveis para pacotes completos capturar feeds, ainda existem muitos dispositivos de rede e sensores IDS que pode produzir logs de nível de serviço e de fluxo (como firewalls de última geração ou ferramentas de código aberto como Suricata). As equipes devem se esforçar para coletar dados de qualquer forma que seja mais eficaz e sustentável para eles. 

Monitoramento de endpoints 

O monitoramento de endpoint é o outro tipo de dados de monitoramento que deve ser coletado por um SOC para garantir que os ataques possam ser identificados e abordados em uma forma precisa e oportuna.  

Coleta de dados de endpoint (referida como “monitoramento contínuo de segurança” ou CSM em muitos cursos SANS) fornece detalhes sobre os processos, logins, serviços e outras informações importantes sobre o que é acontecendo em dispositivos.  

Esses dados, normalmente na forma de registros de texto, são gerados por sistemas operacionais, aplicativos e agentes de segurança presentes no dispositivo e é mais frequentemente coletado por agentes de log e centralizado em um SIEM. 

Categorias de eventos para gravar e coletar  

Execução do Programa 

• Linha de comando e argumentos 

• Nome do programa e caminho do arquivo 

• Processo pai 

• Hash 

• Assinatura – assinada ou não, detalhes da assinatura 

• Status da lista de controle de aplicativos (permitido ou não permitido) Execução de script 

• Janelas ‒ cscript.exe, wscript.exe, cmd.exe ‒ PowerShell – nomes de arquivos de script, transcrição logs, logs de bloco de script, logs de módulo 

• macOS – osacript (AppleScript) 

• Linux – comandos sh, zsh, bash, etc. 

• Linguagens multiplataforma, como Python Registros de autenticação 

• Quais contas estão fazendo login com sucesso? Não conseguiu fazer login? 

• Que tipo de login está sendo usado? (login local, RDP, SSH, etc.) 

• Mecanismos de autenticação – Kerberos vs NTLM, etc. 

• Se for remoto, de onde vem o login? 

Configuração e monitoramento de linha de base 

• Executando serviços
• Itens de execução automática
• Tarefas agendadas
• Adições, exclusões, leituras e modificações confidenciais de arquivos e registros

Status de vulnerabilidade 

• Sistema operacional – versão e patches instalados
• Aplicativos – O que está instalado e qual versão?

Nota: Os logs do firewall do host são uma fonte incrível de visibilidade, mas muitas vezes devem ser fortemente filtrados antes da coleta – selecionando apenas portas comumente usadas para movimento e origens/destinos onde o tráfego seria inesperado. 

• Tráfego de entrada/saída para portas comumente exploradas ou incomuns (SMB, RDP, SSH, comunicação remota do PowerShell, VNC, WMI, FTP, etc.) 

• Tráfego de entrada/saída de/para locais inesperados (procurando movimento lateral, como conexões de dispositivo de usuário para dispositivo de usuário) 

• Portas de escuta e os programas que as utilizam  

• Tráfego de saída/entrada por processo (uma chave diferenciadora para logs de firewall de rede) 

Fontes de log do Windows 

As fontes de log do Windows são divididas em canais no Evento do Windows Visualizador. Embora a política de auditoria do Windows determine quais eventos criam um gravar em um dos canais, ainda cabe à equipe de segurança selecionar qual canais e quais eventos dentro de cada canal serão coletados.  

Observe que enquanto a configuração mais padrão é começar coletando os dados de Segurança, Sistema, e canais de aplicativos, isso não é suficiente para detectar muitos canais avançados ataques. Para permitir melhor que sua equipe detecte ataques, o seguinte Windows canais de registro e além (quando aplicável) também devem ser considerados para coleção.  

Observe que muitos desses canais exigirão um evento detalhado política de filtragem implementada pelo seu agente de coleta de logs com base no EventID e/ou outros campos para coletar apenas eventos relevantes para a segurança. 

Canais de interesse de registro do Windows:

• AppLocker 

• DeviceGuard 

• EMET 

• PowerShell 

• Mitigações de segurança/Modo Kernel (Windows Exploit Guard) 

• Sysmon 

• Windows Defender 

• Firewall do Windows com Segurança Avançada 

• Atividade WMI 

Fontes de log Linux/Unix 

Os logs do sistema baseado em Unix são normalmente registrados em arquivos de texto, conforme mostrado abaixo, ou no diário do sistema para distribuições usando o diário do systemd. Os seguintes itens estão começando sugestões pontuais para construir uma estratégia de log do Linux. 

• /var/log/auth.log ou /var/log/secure 

• /var/log/syslog ou /var/log/messages 

• /var/log/audit/kern.log – Registros do kernel (valor altamente detalhado e potencialmente limitado) 

• /var/log/audit/audit.log – logs de auditoria 

• /var/log/audit/ufw.log – Registros de firewall 

• /var/log/apache2 (ou httpd) /access.log – logs do Apache 

• /var/log/httpd/mysqld.log – registros do MySQL 

Registro em nuvem 

O registro e o monitoramento de sistemas baseados em nuvem podem ser feitos de diversas maneiras diferentes maneiras, dependendo de como os sistemas em nuvem são gerenciados. As duas áreas principal estão acompanhando a administração da própria plataforma em nuvem, e monitorar os servidores, plataformas ou aplicativos executados na nuvem. 

Registro de IaaS 

Para sistemas que podem ser considerados IaaS, o registro e o monitoramento se resumem ao uso dos mesmos mecanismos que você usaria como se estivesse executando esse sistema localmente. 

Como você tem controle quase total do sistema, o registro pode ser implementado como qualquer outra máquina virtual, muitas vezes usando agentes de log que coletam informações sobre o sistema, o sistema operacional e a atividade do aplicativo e, em seguida, enviadas para um SIEM centralizado. 

Logs do plano de gerenciamento de nuvem são uma grande área de preocupação para todos os serviços em nuvem são as interfaces de administração eles mesmos. Cada organização tem indivíduos que têm permissões, por exemplo, fazer login no console Amazon AWS e ler, modificar, criar ou destruir serviços e dados.  

Um invasor que obtiver acesso a essas funções administrativas pode facilmente causar danos de muitas maneiras diferentes. Portanto, o monitoramento do sistema em nuvem deve sempre incluir a auditoria de quem está fazendo login na administração plataforma e quais ações eles estão realizando. Registro em log do plano de gerenciamento de nuvem as fontes incluem itens como Amazon CloudTrail e Logs de atividades do Azure. 

Registro de PaaS e SaaS 

Mesmo que sua organização não controle o sistema subjacente em uma plataforma ou software como configuração de serviço, as preocupações com sua segurança devem ser tão alta prioridade como qualquer outro sistema.  

Os fornecedores de PaaS e SaaS normalmente habilitam o registro coleta por meio de chamadas de API ou logs de serviço gravados em uma área especial dentro do fornecedor plataforma de nuvem (como um bucket S3, Amazon CloudWatch, Azure Event Hub ou semelhante).  

Essas APIs e pontos de coleta de logs devem então ser configurados em seu SIEM como uma origem de log que é pesquisada automaticamente. Os registros coletados devem incluir atividades para o serviço, bem como os usuários que interagem com o software, e devem auditar as ações que foram tentadas/realizadas (alterações, login/logoff, ações, etc.). 

A diferença entre Saas e IaaS/PaaS é que a segurança desses sistemas é fora do seu controle, deixando esses logs como única opção de monitoramento, e somente incluindo o que seu fornecedor está disposto a compartilhar com você.  

Organizações que utilizam SaaS devem considerar cuidadosamente os casos de uso para ataques a esses sistemas e potenciais objetivos do invasor, além de mapear como esses eventos seriam, dada a visibilidade disponível para você a partir da API do fornecedor. As regras de análise e alertas em torno desses casos de uso devem em seguida, serão criados, testados e verificados continuamente para garantir uma cobertura completa. 

Modelos e métricas para SOC 

Esta seção contém algumas das referências mais importantes para compreender e modelar ataques cibernéticos, construir inteligência sobre ameaças, além de executar e medir suas operações de segurança. 

Referências de Framewoks 

A seguir está uma lista de alguns dos modelos mentais mais úteis comumente referenciados no InfoSec, bem como estruturas incrivelmente úteis que estão sendo desenvolvidas para padronizar e organizar as principais técnicas de ataque e defesa cibernética, inteligência e dados sobre ameaças. 

• Cadeia de Cyber Kill da Lockheed Martin 

• Ciclo de Resposta a Incidentes (NIST SP800-61r2) 

• Pirâmide da Dor de David Bianco 

• O Modelo Diamante de Análise de Intrusão 

• MITRE ATT&CK – lista de táticas, técnicas, procedimentos, ferramentas do invasor, grupos de ameaças, opções de mitigação e detecção e muito mais! ‒ ATT&CK Navigator – Ferramenta de visualização complementar  

• MITRE Shield – Táticas, técnicas e uma base de conhecimento para defesa ativa 

• ATC RE&CT – Uma estrutura, coleta e dados fonte para técnicas de resposta a incidentes ‒ RE&CT Navigator – Ferramenta de visualização complementar 

Conhecendo a si mesmo e  seu inimigo 

Definir seu inimigo em diversas capacidades é fundamental para alinhar o orçamento defensivo contra os ataques mais prováveis. Os objetivos, capacidades, táticas do seu inimigo, técnicas, procedimentos e IOCs específicos devem ser extraídos de incidentes e informações externas, e rastreadas o mais de perto possível.  

Isto ajudará a produzir uma imagem bem definida de quem e o que sua equipe enfrentará. Quanto melhor esse conhecimento pode ser coletado e organizado, mais eficaz será a equipe será, e mais eficientemente o orçamento da defesa poderá ser alocado.  

Essa seção apresenta alguns dos modelos e conceitos importantes que uma equipe deve estar familiarizada para aproveitar ao máximo a inteligência sobre ameaças. 

Três níveis de inteligência contra ameaças 

A inteligência contra ameaças vem em vários “sabores” e todos serão necessários para uma defesa eficaz. Os SOCs e os analistas SOC geralmente operam no nível mais baixo níveis de inteligência de ameaças “operacional” e “tática”.  

Mas isso por si só não é suficiente. Um SOC bem-sucedido precisa produzir, adquirir ou comprar todos os três níveis de inteligência contra ameaças para melhor defender sua organização. 

Nível Estratégico 

• Consumidores: Executivos e formuladores de políticas 

• Analisa amplamente o cenário de ameaças, impulsiona investimentos, políticas e riscos 

Nível Operacional 

• Consumidores: respondentes seniores, gerentes 

• Metas e tendências, rastreamento de campanha, capacidades do adversário, dados de atribuição 

Nível Tático 

• Consumidores: analistas SOC, analistas de inteligência de ameaças, respondedores de incidentes 

• Nível IOC: IPs/domínios, artefatos de host + análise 

• O tipo mais comum para uso em nível de analista 

Modelagem de ameaças 

Cada organização e indivíduo deve considerar os detalhes do seu modelo de ameaça como um primeiro passo na construção de sua defesa. 

Parte da construção de um modelo de ameaça envolve responder a perguntas como as seguintes: 

1. O que você está protegendo?
2. De quem você está protegendo isso?
3. Qual é a probabilidade de você precisar protegê-lo?
4. Quão ruins serão as consequências se você falhar?
5. Quantos problemas você está disposto a enfrentar para evitar essas consequências?

Árvores de ataque 

As árvores de ataque são um método de visualizar os detalhes da sua ameaça modelo e como os invasores podem abordar o alcance de seus objetivos em seu ambiente. 

Criar um para vários objetivos presumidos do atacante é útil exercício de brainstorming sobre os caminhos que os invasores podem seguir e revela os principais pontos de coleta de evidências para ajudar a melhorar sua postura defensiva. 

Criar uma árvore de ataque é fácil, basta começar listando o objetivo assumido de um ataque em uma caixa no topo da página e depois “dar um passo para trás”, listando todos os métodos conhecidos que permitiriam que isso acontecesse. 

Então repita desça a página com tantos detalhes quanto desejar. Você pode colocar probabilidades, classificações ou probabilidades em cada item, se desejado, mas isso não é obrigatório. 

Quando concluído, você terá produzido, ao contrário, um mapa de como invasores podem iniciar seu ataque de maneira viável, abrir caminho através de seu ambiente e, em última análise, alcançar seu objetivo no final.  

Fazendo este exercício de pensamento pode iluminar pontos cegos e outros pontos fracos na defesa da sua organização antes que o invasor os encontre, dando a tempo da equipe para resolver o problema antes que ele seja descoberto durante um verdadeiro ataque.  

O Loop OODA 

O Loop OODA, projetado pelo piloto de caça John Boyd na década de 1940, pretendia ser um modelo mental mostrando os quatro estágios em que quaisquer duas partes envolvidas em qualquer competição frente a frente estão constantemente passando. 

Também prevê quem pode sair vencedor com base na velocidade com que cada lado pode iterar através do laço. Para equipes de operações de segurança, esse modelo é uma forma útil de pensar sobre a importância do ritmo das operações e como a velocidade através cada função SOC contribuirá para o seu sucesso na luta contra um invasor. 

O Loop OODA e tempo de operações 

Observar  

Esta etapa trata da coleta de informações do meio ambiente. Para um SOC, isso se traduz na função de coleta, na capacidade de ver os dados de rede e endpoint necessários para detectar um ataque. 

Orientar 

De todas as fases, a fase oriental tem um dos maiores impactos, pois é onde tentamos interpretar a situação face aos dados apresentados para nós. Para operações de segurança, isso significa retirar o conteúdo dos dados de rede e endpoint disponíveis e usá-los para formar uma hipótese do que pode estar ocorrendo.  

Sem uma equipe treinada para entender ataques ou as informações disponíveis, esta etapa pode levar a uma avaliação incorreta da interpretação dos dados ou uma resposta mais lenta do que o necessário. 

Decidir 

Nesta fase é hora de decidir, dada a sua interpretação dos eventos da fase de orientação, o próximo melhor movimento a ser feito contra seu oponente. Para segurança de operações, trata-se de decidir a melhor forma de interromper os invasores, de modo que possamos ter uma vantagem sobre eles nas próximas iterações do loop. 

Para um SOC, a eficácia nesta fase muitas vezes se resume à experiência e treinamento sobre como responder melhor a qualquer situação. Manuais e os procedimentos de resposta a incidentes podem ser de grande ajuda nesta fase. 

Agir 

O estágio de ação trata de seguir o curso da ação decidido na fase de decisão. No SOC, isso pode ser traduzido à sua capacidade de responder rapidamente a um ataque. Você tem permissão, ferramentas e procedimentos em vigor para agir rapidamente e minimizar dano?  

A fase de ação leva ao feedback do impacto da sua ação para a próxima iteração da etapa do observador, onde o SOC irá precisar ver se a ação tomada teve as consequências desejadas. 

Caça a ameaças 

A ameaça é uma peça-chave das operações diárias e é a outra peça-chave da função de “detecção” conforme descrito anteriormente. Embora qualquer SOC tenha uma grande biblioteca de ataques conhecidos e assinaturas para identificar os ataques, é garantido que existem muitos malwares e métodos de ataque desconhecidos lá fora também para os quais não existe assinatura. Portanto, a caça às ameaças é uma atividade necessária para todas as equipes SOC, independentemente do tamanho ou experiência. 

A caça a ameaças deve ser vista como a “outra metade” da operação de detecção. Em vez de ser reativo com base em IOCs correspondentes, é um processo proativo. Caçar sem assinaturas de malware conhecidas, portanto, muitas vezes envolve coletar e analisar cuidadosamente grandes quantidades de dados ou atividades em busca de anomalias que possam nos levar na direção certa.  

Embora todas as equipes possam caçar as ameaças, a natureza das táticas de caça às ameaças muitas vezes significa que aqueles com coleta e análise de dados extensa e bem planejada, bem como inteligência sólida sobre ameaças para usar como referência, será a mais eficaz em encontrar o risco. O processo pode ser dividido nas seguintes etapas: 

Formular hipótese	O que nossos adversários poderão fazer?
Definir evidências	Que tipo de evidência esse ataque deixaria?
Identificação de fonte de dados	Quais fontes de dados estão disponíveis em nosso ambiente que identificaria este tipo de pessoa?
Colete e examine dados	Nossos dados mostram comprometimento?
Responder à descoberta	Invoque resposta a incidentes, se necessário
Melhoria de análise e proteção	Feche o ciclo!

Métricas 

As métricas são usadas em um SOC como um mecanismo de feedback extremamente importante. 

Este feedback serve tanto para o SOC avaliar a si mesmo quanto para servir de meio de comunicação entre o SOC e a alta administração. Métricas internas rastreadas e assistidas por aqueles dentro do SOC precisam mostrar ambas as medições e dizer aos membros do SOC se as coisas estão operando na faixa de “business as usual”, bem como como as iniciativas e projetos de melhoria estão progredindo.  

As métricas externas devem se concentrar em dar à alta administração informações necessárias para tomar decisões de risco e orçamentárias, bem como claramente demonstrar o retorno do investimento produzido pela equipe.  

Esta seção contém conceitos e considerações de avaliação para suas métricas. Lembre-se, o sucesso no SOC depende da eficácia tanto das tarefas operacionais do dia a dia quanto da melhoria contínua. 

Tipos de métricas 

Métricas 

Uma medição de um processo de negócios não inclui um ponto de referência ou contexto. As métricas são usadas como componente-chave próximos de dois itens (exemplo: alertas na fila de triagem). 

Objetivos e resultados-chave (OKRs)  

Uma estrutura de gerenciamento de metas estratégicas para medir avanços e iniciativas. O sistema OKR pode ser uma forma de geração de métricas para iniciativas de melhoria no SOC. 

• Objetivo – A meta a ser alcançada
• Resultados-chave – Maneiras específicas e mensuráveis que você conhece você está progredindo em direção ao objetivo
• Iniciativas – Ações específicas que serão tomadas para “mover a agulha” do início ao objetivo final
• Componentes Mensuráveis

‒ Valor inicial – Métrica de interesse no início do projeto 

‒ Valor atual – Métrica do status a partir do período de medição mais recente 

‒ Valor alvo – Valor da métrica quando o projeto será considerado concluído 

Indicadores Chave de Desempenho (KPIs) 

Uma métrica + os limites ou limites desejados dessa métrica. Usado para medir e manter o status quo ou “business as usual”. Um KPI fora do intervalo geralmente significa que alguma ação deve ser tomada para corrigir o problema. 

Os KPIs devem ser desenvolvidos e usados para itens operacionais diários do SOC para saber se as ferramentas e processos de segurança estão operando conforme o esperado  

Exemplos: integridade da telemetria, taxas de incidentes, falsos positivos e qualquer outra área em que uma meta ou um valor “normal”/“médio” ”pode ser estabelecido. 

Exemplos 

• Objetivo: “Reduzir o risco e o impacto de ataques de phishing bem-sucedidos” 

• Resultado principal 1: menos de 1% dos e-mails de spam entregues nas caixas de entrada 

• Resultado principal 2: tempo de resposta máximo de 30 minutos, desde o alerta de onda de phishing até a contenção e proteção em vigor 

• Resultado principal 3: menos de três ocorrências por semana de e-mails maliciosos afetando usuários 

• Iniciativas: implementação de sandbox de e-mail malicioso, treinamento de conscientização de usuários, monitoramento de e-mail SOC e caça a ameaças 

Considerações práticas sobre métricas  

Embora métricas, KPIs e OKRs específicos de interesse possam mudar de equipe para equipe, o que é amplamente aceito é que todas as métricas devem estar alinhadas aos objetivos.  

Em outras palavras, a métrica que você está gerando ajuda a responder a uma pergunta sobre se você atingiu uma meta operacional ou de melhoria? Caso contrário, essa métrica pode não ser uma boa seleção para coletar. 

Mesmo as métricas alinhadas às metas podem ter problemas. Algumas considerações adicionais para cada número que você gera e coleta estão abaixo: 

• Quanto tempo leva para gerar essa métrica? É um processo manual ou automatizado? 

• O método de coleta da métrica está bem definido? Duas pessoas produzirão o mesmo resultado se forem solicitadas a coletá-lo? 

• Está claro o que fazer quando essa métrica está fora dos limites desejados? Em outras palavras, é acionável? 

• A métrica é coletada com frequência suficiente para agir com rapidez suficiente caso saia dos limites desejados? É coletado com muita frequência? 

• Ao relatar uma métrica, você está removendo desnecessariamente a fidelidade e substituindo-a por uma cor ou descrição qualitativa que pode dificultar a interpretação? 

O que medir 

Conceitualmente, o SOC deve ter como objetivo medir as entradas e saídas dos processos para garantir que estejam funcionando conforme o esperado.  

Pense em como você pode quantificar o sucesso nas funções SOC – coleta, detecção, triagem, etc. – e como as métricas podem ser facilmente, automáticas e continuamente 

produzido que dará uma visão simples se algum item importante foi alterado ou quebrado, ou se anomalias estão ocorrendo no tipo ou frequência do incidente. Isso forma um ciclo de feedback pequeno e rapidamente reativo que pode promover a rápida descoberta e correção de problemas.  

Considere tanto as métricas de eficácia (estamos fazendo as coisas certas?) quanto as métricas de eficiência (quão bem estamos executando as coisas que decidimos fazer?). 

De qualquer forma, a maneira mais fácil de garantir um NOC de qualidade é contratando uma empresa de TI com boas referências. 

Diferenc ais da Infonova 

A Infonova tem 20 anos de experiência em tecnologia, infraestrutura de TI, e pessoas. Temos clientes internacionais como HBO, AirBnb, Linkedin, Tempo Assist, Nissin, entre outros. Ou seja, estamos aptos a atender qualquer segmento e tamanho de negócio com maestria. 

BACKUP 

Todas as posições de profissionais da Infonova têm backup. Temos um ditado interno que é: “quem tem um… não tem nenhum”. Portanto, somos obcecados em ter continuidade nas operações para que nós e os nossos clientes possam focar na parte mais importante: explorar oportunidades e gerar crescimento. 

VALOR FINANCEIRO 

O valor da Infonova é intencionalmente menor quando comparado com empresas no mesmo nível de maturidade. No entanto, fazemos isso para ter a possibilidade de escolher os nossos clientes e ter uma base de clientes satisfeitos, e por bastante tempo. 

LIBERAÇÃO DO RH 

O RH é uma das áreas mais importantes de qualquer empresa. Afinal, ele deve estar focado em gerir a cultura, desenvolvimento dos colaboradores e atração de talentos; e não apenas com a reposição de profissionais. Sendo assim, terceirizar a TI oferece a possibilidade de fazer com que o RH esteja mais livre para se tornar um vetor de crescimento para a empresa. 

FLEXIBILIDADE – HUB DE TECNOLOGIA 

A Infonova não faz só Infra, ela pode fazer de tudo. Na verdade, para alguns clientes que não podem resolver algumas questões diretamente, a Infonova atua como Hub, indo para o mercado, encontrando parceiros e fornecedores e interagindo com eles. Esses serviços incluem áreas diversas, como:  

• Ar-condicionado; 

• Outsourcing de impressão; 

• Links de internet; 

• Compra de materiais e mais. 

ALOCAÇÃO DE DESENVOLVEDORES 

A Infonova já foi uma fábrica de software no passado. Contudo, em 2012 escolhemos focar em Gestão de TI, Infraestrutura e Segurança. No entanto, como era de se esperar, esse conhecimento e familiaridade permanecem até hoje no time. Portanto, realizamos consultorias de DevOps para alguns clientes, atuamos como mediador entre clientes e desenvolvedores, e também alocamos desenvolvedores para alguns clientes. 

RETENÇÃO DE COLABORADORES 

Demoramos mais de 10 anos para entender e construir as ferramentas para atrair e manter profissionais de tecnologia no nosso time. Então, seja o profissional alocado no cliente ou não, temos a vivência de como reter, desenvolver e satisfazer tanto os profissionais quanto os clientes. E essa é uma necessidade para o sucesso da empresa. 

LIBERAR BRAIN POWER DA ORGANIZAÇÃO PARA APROVEITAR OPORTUNIDADES 

Não dá para fazer tudo. Então, faz mais sentido focar no que faz a empresa crescer, mas isso requer um recurso escasso: tempo e atenção. Terceirizar a TI significa retomar esse recurso, contudo, não é de graça. Terceirizar é mais caro do que contratar direto, mas faz sentido se você pode usar a atenção e o tempo para realizar mais valor, inclusive financeiro. 

NÃO TEM MULTA DE CONTRATO 

A Infonova tirou as multas dos seus contratos há muitos anos. Afinal, entendemos que para o cliente, muitas vezes mudar é uma situação nova. Portanto, escolhemos tirar o risco do cliente e trazer este risco apenas para o nosso lado. 

PODE PARAR QUANDO QUISER 

Os primeiros 90 dias de contrato com a Infonova não tem multa e nem aviso prévio. Ou seja, basta pedir para parar. Contudo, após os 90 dias, também não temos multa, porém, solicitamos um aviso com 30 dias de antecedência. 

CONTINUAMOS AMIGOS 

Na Infonova a relação continua mesmo sem contrato. Ou seja, mantemos o relacionamento com os clientes e continuamos ajudando, trocando experiências e apoiando, independente de existir um documento de contrato ou não. Afinal, o nosso interesse é na parceria. 

DORMIR TRANQUILO 

Stress faz parte do crescimento. Afinal, crescer não é um caminho fácil. No entanto, você pode escolher o tipo de stress que quer ter. Ou seja, pode decidir entre o stress de fazer a empresa “funcionar”, ou o de focar em aproveitar as oportunidades enquanto dorme tranquilo sabendo que o dia a dia está garantido.