O V SOC Forum, o maior evento sobre a prática de detectar e analisar incidentes na Rússia, começará amanhã. Estou certo de que muitos leitores deste hub estarão lá e ouvirão muitos relatórios profissionais nesta área de segurança da informação. Mas, além dos termos, definições e práticas estabelecidas, abordadas no Fórum do SOC, na vida real, cada um de vocês provavelmente ouviu muitas opiniões diferentes sobre o funcionamento do SOC, proteção contra ataques do APT, etc. Hoje, discutiremos vários mitos e lendas populares.
Estamos interessados em sua opinião sobre cada um deles, por isso estamos aguardando seus comentários. Bem-vindo ao gato.
Mito 1 - SOC em uma string ou a mágica de analisar o tráfego de rede
Frequentemente, ao discutir com o cliente uma proteção abrangente contra invasores externos, ouvimos: "E temos o hardware A, que é enriquecido pela experiência e informações do fornecedor sobre novas ameaças e nos protege completamente contra ataques externos". Tudo bem, se depois dessas palavras nos foi mostrada uma solução multi-módulo Anti-APT - haveria perguntas, mas haveria muito menos. Na maioria das vezes, por trás desse "dispositivo universal" existe um IDS comum, às vezes com funcionalidade básica para analisar o tráfego https. Não questionamos a experiência dos fornecedores no campo da segurança cibernética e seus conhecimentos sobre hackers, bem como a utilidade de registrar e analisar o tráfego de rede (esse tópico certamente será levantado repetidamente no Fórum), mas, no entanto, queremos focar nas limitações da abordagem, com cujo SOC se concentra apenas em eventos de rede.
- Vamos começar com a base e alguns já danificados. Desde 2013, observamos ataques de hackers realizados sem o uso de malware e, pelo menos, sem um módulo para interagir com o servidor de gerenciamento. Para os invasores, vêm ferramentas legítimas de administração remota (Remote Access Tools), que com o arquivo de configuração correto se comportam de maneira indistinguível dos usuários que gostam de trabalhar em casa, ou do trabalho de administradores remotos em empresas com baixo nível de maturidade em TI. No nível dos eventos de rede, é simplesmente impossível distinguir uma sessão da outra e, para uma análise completa do método e dos motivos para iniciar uma sessão, são necessárias informações dos sistemas finais.
- Se a ideia de RAT é repugnante para o invasor ou se não é aplicável em um caso de ataque específico, o protocolo https chega ao resgate como uma forma de interação. Em uma cópia do tráfego, a descriptografia do protocolo não é possível; portanto, o sensor deve se contentar apenas com as informações sobre os cabeçalhos dos pacotes. Isso é útil apenas quando o centro de controle está em uma área específica e pode ser calculado por IP. Mas, mais frequentemente, estamos falando de grandes serviços de hospedagem ou serviços públicos (escrevemos anteriormente sobre invasão de páginas do Wordpress), o que não nos permite identificar onde está a conexão legítima e onde está comprometida.
- Por toda a sua utilidade, as conexões de rede (e geralmente falamos de um pedaço de ferro na área de perímetro) registram apenas o relacionamento entre o centro de controle e a cadeia principal de clientes bot. Freqüentemente, os atacantes atuais usam uma cadeia de servidores C&C proxy (o primeiro nível de captura de infraestrutura) para se comunicar com clientes bot internos. Nesse ponto, as restrições na localização do equipamento não detectam completamente o ataque.
- Com toda a variedade de ações de um invasor, ele periodicamente não precisa vir da Internet. É possível comprometer uma conta de acesso remoto e trabalhar com os direitos legítimos de um administrador ou usuário. Cada vez mais, os grupos usam a metodologia da cadeia de suprimentos, iniciando um ataque invadindo um contratado, que geralmente possui um canal estático e mal controlado para a infraestrutura e as mesmas contas privilegiadas. Há mais e mais vetores a cada ano, e estão cada vez mais longe dos remédios clássicos.
- Em geral, o SOC não se trata apenas de combater hackers. Os invasores internos, a violação das políticas de SI ou fraude, o upload ou o comprometimento de dados do cliente e muito mais também fazem parte de uma abordagem abrangente do SOC. E isso requer técnicas e ferramentas muito mais complexas em seu trabalho.
Mito 2 - SOC sem pernas ou Trabalho sem a primeira linha
Uma das nossas lendas favoritas. Piadas sobre o SOC, onde apenas 1 pessoa trabalha, ele é um pouco da 1ª, uma pequena 2ª e uma pequena 3ª linha de suporte, já inundaram a Internet. Mas muitos clientes, ouvindo vários relatórios diferentes e lendo artigos, começam a falar sobre a necessidade de uma peça mágica de ferro / procedimento / tecnologia (sublinhe conforme necessário) que automatizará e resolverá todos os problemas da primeira linha. E, como muitas vezes na cabeça do cliente, a 1ª linha é equivalente ao modo de operação 24 horas por dia, 7 dias por semana (todas as outras, como regra, funcionam de acordo com o cronograma padrão), isso cria automaticamente a sensação de uma redução significativa nos custos com pessoal e gera conversas na chave "A primeira linha não necessário, vamos começar a construir imediatamente com o segundo ".
O principal problema dessa lenda, em nossa opinião, é a confusão na terminologia. Freqüentemente, quando o palestrante fala sobre a 1ª linha, ele é guiado pelas práticas da ITIL, onde tarefas atômicas realmente caem nas mãos dos operadores:
- recepção de tarefas
- classificação
- adicionando contexto (ativo ou sistema de informação)
- priorização ou priorização
- nomeação para a pessoa responsável pelo sistema / exame / linha.
Quando se trata desse tipo de tarefa, é claro, nenhuma primeira linha dedicada é necessária: esses processos, embora não sejam fáceis, são completamente automatizados. O que queremos dizer com a primeira linha, já escrevemos várias vezes - por exemplo,
aqui ). Ainda assim, a primeira linha não substitui a automação e nem mesmo uma equipe trabalhando exclusivamente em um manual. Esses funcionários são curiosos e procuram, embora tenham apenas habilidades básicas na análise de eventos e na investigação de incidentes. Em termos de ITIL, essa linha seria chamada 2nd, o que remove imediatamente todas as perguntas e discrepâncias.
Eu não gostaria de ignorar as perguntas 24 * 7. Sobre a organização do turno, a eficiência dos operadores e analistas à noite, a cegueira psicológica ao visualizar eventos, muito foi dito. As conclusões integrais são aproximadamente as mesmas - a primeira linha SOC e um turno ininterrupto tornam-se ineficientes e desnecessárias. Por nossa parte, por muitos anos, também tentamos métodos diferentes e, no momento, o nível federal do SOC nos permite minimizar os riscos de fadiga especializada durante o turno da noite (um incidente crítico é simplesmente enviado para um fuso horário diferente), no entanto, gostaria de observar alguns pontos.
- Reduzir o tempo de turno para o operador é uma ótima idéia. É praticamente impossível trabalhar no princípio do dever de TI por um dia ou três em segurança da informação. No entanto, manter o foco em incidentes é muito importante ...
- MAS ... o operador da 1ª linha não senta, como o operador do filme "The Matrix", olhando para o fluxo de eventos brutos em busca de anomalias. Pelo menos em nenhum SOC conhecido por nós encontramos essa abordagem. Seu trabalho é analisar relatórios e buscas regulares ou elaborar cenários para identificar incidentes. Nesse modo de mudar a atenção e os tipos de atividade (com o equilíbrio certo de números em jogo), os riscos de uma rápida cegueira psicológica nos parecem mínimos.
E, para concluir - não importa o quão longe a automação tenha sido, é habitual deixar um especialista que monitora a situação com máquinas e robôs em qualquer local crítico de produção. E se a sua bifurcação, neste caso, é "a automação pode me ajudar a não alocar taxas de 5 a 6 para o turno de turno", nossa resposta é inequívoca: não pode.
Mito 3 - SOC perfeito sem uma única interrupção, ou Trabalhamos sem falsos positivos
Quanto mais você cria o SOC ou trabalha com um provedor MSSP / MDR, mais deseja o ideal. Agora, muitos clientes passaram por tubos de incêndio, água e cobre nas primeiras abordagens independentes para o projétil ou pilotos / contratos com fornecedores externos e todos estão tentando, de alguma forma, buscar o ideal. E o ideal aos olhos da pessoa responsável pelo serviço externo geralmente é expresso pela frase "todo alerta é um incidente confirmado" ou "não estamos monitorando suspeitas - estamos registrando ataques". E em termos de aspectos-chave da eficiência, é difícil argumentar com essa afirmação. Mas, como sempre, o diabo está nos detalhes.
A maioria dos SOCs visa a uma análise eficiente e profunda do incidente possível em todas as informações disponíveis. E eles estão cada vez mais se aproximando da perfeição, quando têm a oportunidade de receber registros de
conchas para ela. Vamos examinar um exemplo de um incidente sobre os fatos da operação de indicadores de rede de software antivírus (o endereço de comunicação com o centro de controle) - para identificá-los, você só precisa de algumas informações sobre os fluxos de rede da Internet, por exemplo, logs de firewall, mas eles geralmente dão um resultado falso. É suficiente para o invasor ocultar seu servidor de gerenciamento de malware na hospedagem e encontraremos automaticamente um grande número de falsos positivos. Para filtrar e analisar efetivamente o incidente, é necessário localizar a atividade no host inicial (processos acionados, soquetes abertos etc.). E isso nos leva à necessidade de conectar eventos de todos os hosts da rede.
Total: para que o SOC chegue perto da possibilidade de identificar ataques exclusivamente, sem falsos positivos, precisamos garantir a cobertura máxima de monitoramento da infraestrutura - idealmente, para coletar TODOS os logs de TODOS os objetos.
Isso nos leva a vários problemas ao mesmo tempo.
- A oposição real dos departamentos de TI à elevação do nível de auditoria ou à instalação de sistemas adicionais para coleta (para evitar o mal, nem tocaremos no tópico de conectar segmentos e tecnólogos do ACS). Testes de compatibilidade, um aumento imprevisível da carga nos sistemas e outros fatores que podem afetar a disponibilidade geral da infraestrutura são o gatilho para a próxima rodada da guerra entre TI e segurança da informação. E na maioria das vezes eles apenas deixam grandes manchas brancas no mapa de monitoramento de infraestrutura do SOC.
- Manutenção da cobertura completa. Não é possível coletar todos os logs de todos os servidores. Por exemplo, em novos sistemas, os logs podem simplesmente não ser incluídos. Frequentemente, no processo de alteração de servidores, as configurações de auditoria nas estações de trabalho e as restrições de acesso são parcial ou completamente perdidas. Além disso, as configurações devem ser atualizadas à medida que novos vetores de ataque aparecem. Tudo isso cria custos operacionais para fornecer cobertura total, significativamente mais alto do que os riscos de uma revisão incompleta pelo monitoramento e certamente mais alto do que os custos de uma possível resposta falsa positiva.
- O terceiro problema nos leva ao antigo jogo DOOM. Porque, entre outras coisas, a cobertura completa exige a inserção de códigos.
a. IDKFA - munição completa na forma de infinitas capacidades de servidor para coletar e armazenar eventos e, o que é muito mais triste do ponto de vista econômico, - licenças infinitas para SIEM e outras ferramentas SOC.
b. O IDDQD é uma equipe SOC imensa e imortal que, em cada incidente, será capaz de analisar todos os seus recursos óbvios e indiretos.
A coincidência de tais fatores, tarefas e a quantidade de orçamentos para segurança da informação é considerada o caso de uma reunião de um elefante verde e, portanto, não é considerada uma situação típica na vida do SOC. Portanto, identificar apenas ataques confirmados (com todo o desejo de analisar o mais profundamente possível com ferramentas automáticas) é um sonho fantástico dos guardas de segurança modernos.
Em vez de um posfácio
Tentamos discutir apenas os mitos mais comuns da indústria de construção de SOC. Portanto, em remansos complexos de processos de inicialização para monitorar e responder a incidentes, recomendamos que você seja cético quanto às informações recebidas, verifique-as em diferentes fontes e maximize o medo de
falsificar julgamentos não confirmados.
E que a Força esteja com você;).