1.     Objeto

A necessidade consiste na contratação de segurança cibernética composta de serviços e fornecimento de soluções de Network Detection and Response (NDR), micro segmentação de rede,  Correlação de Eventos de Segurança e Resposta a Incidentes (SIEM), Gestão de Ativos, Gerenciamento de Vulnerabilidades, Simulação de Ataques, Segurança de Identidades e Gerenciamento de Acessos Privilegiados (PAM) com serviços básicos e avançados; e transferência de conhecimento, em atendimento às necessidades do Ministério da Gestão e Inovação e demais órgãos solicitantes.

Cabe destacar que o objeto atenderá toda estrutura definida no Centro de Serviços Compartilhados do Ministério da Gestão e da Inovação em Serviços Públicos - ColaboraGov.

2.     Vigência

A vigência pretendida é de 12 meses prorrogáveis até 10 anos, conforme a nova Lei de licitações.

3.     Especificações Técnicas

3.1.        Serviços e produtos

4.     SOLUÇÃO DE NDR (NETWORK DETECTION AND RESPONSE)

4.1.        Características Gerais da Solução de Inspeção de Rede Contra Ameaças Avançadas com Detecção e Resposta (NDR)

4.1.1.    A solução deverá ser instalada de modo a detectar ameaças avançadas e persistentes (APT) no ambiente da CONTRATANTE, inspecionando o tráfego de rede, independente de agentes instalados.

4.1.2.    A solução de análise de rede deve ser licenciada a fim de inspecionar o Throughput e as infraestruturas das redes da CONTRATANTE.

4.1.3.    Deverá ser garantido ao CONTRATANTE o direito para atualização, inclusive dos ¿rmwares, durante o período de vigência contratual da solução, incluindo versões maiores, versões menores, versões de manutenção e atualizações (updates) que forem disponibilizadas.

4.1.4.    Caso o equipamento apresente defeito ou não suporte uma nova versão de firmware ou atualizações lançada dentro do período de vigência contratual, deverá ser substituído por um novo equipamento equivalente que suporte a versão de firmware mais recente sem ônus para a Contratante;

4.1.5.    A solução deve atuar em todas as redes da CONTRATANTE, estendendo visibilidade sob tráfego.

4.1.6.    A solução deve aplicar técnicas de análise de tráfego avançadas baseadas, no mínimo, em aprendizagem de máquina, em inteligência artificial ou comportamental.

4.1.7.    A solução deve atuar com técnicas de detecção e resposta específicos para modelos de detecção focados em rede, de forma a identificar comportamentos maliciosos.

4.1.8.    A solução deve permitir que seja implantado em linha com o tráfego de rede e em modo de espelhamento.

4.1.9.    Caso a solução seja implementada em linha, o sensor deve permitir a criação de regras de by-pass.

4.1.10.A solução deve suportar o uso de portas espelhadas nos ativos de rede (mirror port) para monitorar o tráfego e detectar potenciais riscos à Segurança.

4.1.11.A solução, durante a inspeção do tráfego de rede em tempo real, deverá ser capaz de identificar anomalias na rede e gerar alertas em casos de tráfego suspeito.

4.1.12.A solução deve ter a capacidade de analisar tráfego criptografado, sem necessidade de licenciamento adicional.

4.1.13.A solução deve analisar, preferencialmente de forma automática, as fases de um ataque direcionado, persistente e avançado, identificando, no mínimo, tentativas de coletas de informação, movimentação lateral, exfiltração de dados, descoberta de dispositivos e comunicações de comando e controle (C&C), e ainda ser capaz de apresentar em seus logs, visibilidade de acordo com a matriz ATT&CK MITRE, pontuando características de táticas e técnicas de acordo com a ameaça detectada pela solução.

4.1.14.A solução deve identificar e mapear possíveis pontos de entrada nas redes que possam ser exploradas por atacantes.

4.1.15.A solução deve ser capaz de detectar ameaças web derivadas de vulnerabilidades e downloads de conteúdo malicioso.

4.1.16.A solução deve analisados protocolos, portas e serviços, incluindo ainda os protocolos mascarados ou tunelados.

4.1.17.A solução deve permitir analisar arquivos e arquivos binários em sandbox, permitindo identificar, no mínimo, ataques avançados (APT), Zero Days, códigos de exploração (exploits) embutidos, tentativas de escaneamento, propagação de malwares, tentativas de ataques de força bruta, movimentação lateral, tentativas de roubo de informação, ameaças que se replicam, comportamentos maliciosos, vulnerabilidades conhecidas e arquivos maliciosos no tráfego de rede, de forma automática, quando aplicável, e com capacidade de operar vários ambientes simultâneos e integrados.

4.1.18.A solução deve analisar em tempo real o comportamento através de simulação de execução de arquivos provenientes do tráfego de rede incluindo arquivos executáveis e scripts.

4.1.19.Os módulos que compõem a solução devem atuar de forma integrada, inclusive com o XDR.

4.1.20.A solução deve possuir atualização automática de regras, políticas, patchs enginers, ou outros.

4.1.21.Não serão aceitos appliances de Unified Threat Management (UTM) e Next-Generation Firewall (NGFW) para monitoramento do tráfego, ainda que possua recurso e licenciamento específico para análise de ameaças em rede.

4.1.22.A solução deve possuir funcionalidades de rastrear malwares ou comportamentos maliciosos.

4.1.23.A solução deve suportar o monitoramento de múltiplas interfaces de rede conectadas a diferentes VLANs e Switches.

4.1.24.A solução deve possibilitar que modelos de detecção a nível de rede sejam customizados de acordo com as necessidades da CONTRATANTE.

4.1.25.A solução deve possuir regras que identifiquem comunicações dos ativos de informação com serviços não autorizados.

4.1.26.A solução deve permitir o upgrade e downgrade de versão de firmware.

4.1.27.A solução deve ser capaz de identificar, no tráfego de rede (Wifi) ameaças de dispositivos móveis.

4.1.28.A solução deve ser capaz de identificar ameaças evasivas em tempo real atuando com análise profunda e inteligência para identificar e prevenir ataques.

4.1.29.A solução dever ser capaz de correlacionar, inclusive com a solução de XDR, regras de detecção de conteúdo malicioso durante todas as fases de um ataque e possibilitar a visualização de toda a cadeia de ataque ou da tentativa de exploração de uma vulnerabilidade permitindo analisar, no mínimo: sua origem com data e hora, identificar as ameaças relacionadas, linha de tempo dos logs, os ativos de informação relacionados e comprometidos, os metadados relevantes à análise dos incidentes, e que gere informação para proteção efetiva do ambiente e para análise sólida das ações.

4.1.30.A solução deve mapear os métodos HTTP/HTTPS de requisições detectados ao longo de uma comunicação inspecionada.

4.1.31.A solução deve inspecionar os domínios e subdomínios trazendo informações sobre possíveis comprometimentos que possam subsidiar as ações de contenções.

4.1.32.A partir dos alertas gerados, a solução deve correlacionar, inclusive com a solução de XDR, os ativos de informação, contendo, no mínimo: IPs, hashs envolvidos, nome do ativo, data e hora, apontando possíveis indicadores de comprometimento (IOCs) nos ambientes.

4.1.33.O fornecimento da solução de NDR será por demanda e através de solicitação da CONTRATANTE como a seguir:

4.1.33.1.                1 Gbps: - O modelo de 1 Gbps atende ambientes com tráfego de rede moderado, processando até 1 Gigabit por segundo de dados da rede.

4.1.33.2.                2 Gbps: O modelo de 2 Gbps atende ambientes com tráfego de rede significativo, processando até 2 Gigabits por segundo de dados da rede.

4.1.33.3.                4 Gbps: O modelo de 4 Gbps atende ambientes com alto tráfego de rede e necessidade de alta capacidade de processamento, suportando até 4 Gigabits por segundo de dados da rede.

4.1.33.4.                Todos os modelos devem seguir a especificação técnica da solução de NDR descritas acima.

4.1.33.5.                Deverá ser possível realizar composição utilizando um ou mais itens dos modelos acima mencionados, de tal forma a suprir as necessidades de throughput da contratante;

4.1.33.6.                Deverá ser possível alteração do volume de throughput solicitado durante a vigência do contrato.

4.2.        Especificações Técnicas da Console de Gerenciamento - Solução de NDR

4.2.1.    A solução de gerência deve ser fornecida em nuvem, quando aplicável, pela Contratada, configurada em alta disponibilidade.

4.2.2.    A console deve possuir integração com o serviço de diretório Microsoft Active Directory e EntraID do O365, para importação da estrutura organizacional e autenticação dos Administradores com a funcionalidade de MFA (Multi Fator de Autenticação), bem como para aplicação de políticas.

4.2.3.    A solução deve registrar os logs e esses devem ser acessíveis por canais criptografados ou por meio de APIs.

4.2.4.    A solução deverá ser acessível através de tecnologia Web HTTPS e permitir configuração de TLS para autenticação, com recurso de múltiplo fator de autenticação (MFA).

4.2.5.    A solução deve possuir gerenciamento para aplicação das políticas de segurança, administração e controle das funcionalidades dos serviços.

4.2.6.    A solução deve ter a capacidade de implementar integração entre a gerência e plataformas de terceiros (ferramentas para BI, XDR, SIEM entre outros). 

4.2.7.    A solução deve gerenciar com perfis de acessos distintos para administração de funcionalidades, acesso, visualização de status de serviços, logs e emissão de relatórios.

4.2.8.    A solução deve gerenciar com recurso de informações estatísticas incluindo fluxo de tráfego, consumo de recursos, quantidade de alertas, throughput e desempenho da solução.

4.2.9.    A solução deve permitir auditar as alterações de configurações e acesso à ferramenta de administração, incluindo usuário, data e horário de acesso e ações realizadas.

4.2.10.A solução deve informar quaisquer atualizações a serem feitas nas soluções e deverá também aguardar validação de data e hora, permitindo agendamento dessa atualização juntamente com a Contratante.

4.2.11.A solução deve possibilitar a restauração das configurações em caso de falhas críticas na solução.

4.2.12.A solução deve possibilitar a criação de dashboards personalizados.

4.2.13.A solução deve possibilitar a monitoração e geração de relatórios a partir da console de administração, com a possibilidade de envio por e-mail e exportação.

4.2.14.A solução deverá fornecer acesso gráfico aos eventos e alertas detectados, com opção de salvaguardar os logs ou direcioná-los para um servidor de log, além de oferecer mecanismos de emissão de alarmes.

4.2.15.A solução deve possibilitar o envio de notificações de eventos.

4.2.16.A solução deverá fornecer atualizações e permitir o agendamento para realização dessas atualizações.

4.2.17.A solução deve notificar os administradores por e-mail caso a solução não receba atualizações por um determinado período.

4.2.18.A solução deve apresentar alertas caso os dados analisados tenham relação com algum tipo de campanha de ameaças globais.

4.2.19.A solução deve possuir logs com um alto nível de detalhes.

4.2.20.A solução deverá permitir a parametrização de horário, no padrão brasileiro, a fim de manter o sincronismo no horário dos logs.

4.2.21.As atualizações do produto (filtros e outros componentes) não devem causar interrupção do serviço.

4.2.22.A solução deve possibilitar o envio, via protocolo seguro, de arquivos da área de isolamento ou capturados em uma análise de incidente, para o fabricante da solução, sob responsabilidade e supervisão da Contratada, desde que não infrinja a Lei Geral de Proteção de Dados (LGPD).

4.2.23.A solução deve suportar a atribuição de papéis funcionais, para implantação de política de controle de acesso baseada em papéis (RBAC - Role-based access control).

4.2.24.Todos os eventos gerados pela solução devem ser armazenados por um período mínimo de 6 (seis) meses.

4.2.25.A solução deverá suportar integração com os principais sistemas de monitoramento, tais como: Zabbix, Nagios ou outros.

4.2.26.A solução deve possuir interface gráfica que apresente em tempo real estatísticas de ameaças detectadas.

4.2.27.A solução deve ter capacidade de agregação e correlação de logs de eventos de segurança de maneira evidente possibilitando coleta de fontes de monitoração para proporcionar informação e identificação de ameaças, correlacionando com a solução de XDR.

4.2.28.A solução deve permitir busca por informações de destino e origem de comunicações.

4.2.29.A solução deve ser capaz de salvar os dados e eventos maliciosos de uma análise, possibilitando restaurar a mesma para continuá-la, consultá-la ou encerrá-la.

4.2.30.A solução deve permitir a notificação de eventos e envio de alertas de forma proativa para os administradores.

4.2.31.O gerenciamento da solução deve estabelecer uma correlação de eventos com o módulo de XDR possibilitando uma análise inteligente dos eventos relacionados para uma análise sólida das ações.

4.2.32.A solução deve possuir detalhes técnicos dos incidentes detectados, das estatísticas do tráfego analisado e dos indicadores de risco do ambiente.

4.2.33.Todos os eventos e ações realizadas na console de gerenciamento precisam ser registrados para fins de auditoria.

4.2.34.A solução deve relacionar e organizar os ataques baseados na matriz do MITRE ATT&CK, identificando técnicas e táticas.

4.2.35.A solução deve prover pontuação de risco para o ambiente de redes da CONTRATANTE e deve ser possível analisar seu comportamento ao longo do tempo.

4.2.36.A solução deve apresentar as vulnerabilidades que estão sofrendo algum tipo de exploração, elencando quanto as CVEs relacionadas com seu grau de risco.

4.2.37.A solução deve ser baseada em inteligência artificial e aprendizagem de máquina, e possuir uma rede global de inteligência de ameaças a fim de potencializar os níveis de detecção de comportamentos anômalos.

4.2.38.A solução deve apresentar alertas caso os dados de telemetria gerados tenham relação com algum tipo de campanha de ameaças globais.

4.2.39.A solução deve mapear via rede os ativos de informação existentes e apontar aqueles que não são gerenciados pelos agentes da solução.

4.2.40.A solução deve informar o escopo, o impacto e os componentes afetados nos ativos de informação envolvidos em um incidente.

4.2.41.A solução deve ainda possibilitar, no mínimo:

4.2.42.Configurações que correlacione alertas em um incidente.

4.2.43.Que o administrador atribua o alerta a outro usuário/administrador.

4.2.44.Inserir informações adicionais.

4.2.45.Classificar status dos alertas.

4.2.46.Customizar indicadores de comprometimento (IOCs).

4.2.47.Incluir e remover: URLs, IPs, domínios e endereços de e-mail a lista de objetos suspeitos.

4.2.48.A solução deve possibilitar a monitoração e geração de relatórios a partir da console de administração, com a possibilidade de envio por e-mail e exportação.

4.3.        Serviço Básico e Avançado (Software/Equipamento)

4.3.1.    Os serviços de suporte técnico básico e especializado é fundamental para a continuidade e integridade dos sistemas e plataformas digitais, a fim de manter sua constante evolução e adequação aos cenários de ataques cibernéticos.

4.3.2.    O Serviço Básico e Avançado escrito no presente item é relacionado à implantação, configuração, operação, monitoramento e sustentação das soluções instaladas no ambiente tecnológico do CONTRATANTE, bem como apoiar a prevenção, a análise e a resposta a incidentes cibernéticos.

4.3.3.    A partir da ocorrência de um incidente de segurança, realizar as seguintes atividades de resposta aos incidentes, não se limitando a essas:

4.3.3.1.  Detecção: identificar o evento, realizar abertura do chamado e comunicação do incidente;

4.3.3.2.  Triagem: realizar a análise inicial do incidente (revisão de logs, confirmação de origem com data e hora, avaliação se falso positivo e identificação, complexidade;

4.3.3.3.  Análise: realizar análise do evento ocorrido para mensurar o impacto real do incidente, a linha do tempo, as ações a serem tomadas.

4.3.3.4.  Contenção: direcionar procedimentos de resposta a incidentes conforme categorização e criticidade do incidente para que as equipes técnicas possam executar as ações de respostas efetivas.

4.3.3.5.  Recuperação: apoiar, quando for o caso, com o envio de procedimentos e recomendações de segurança que devem ser adotados para retornar os serviços e sistemas, bem como aplicar configurações e políticas nas soluções contratadas.

4.3.3.6.  Documentação e Revisão: documentar o incidente e sugerir melhorias para aumento da resiliência em segurança da informação;

4.3.4.    Deverá a CONTRATADA viabilizar suporte técnico básico e especializado nos termos a seguir:

4.3.4.1.  Possuir portal de serviços para abertura de chamados e acesso à base de conhecimento, sendo possível o uso de ITSM (GSTI ? Gerenciamento dos Serviços de TI) indicado pela CONTRATANTE.

4.3.4.2.  O suporte a usuários deverá seguir o horário oficial de funcionamento da Contratante, e atividades de monitoramento e simulações de ataques, operação, gestão, sustentação da solução e resposta a incidentes deverá atender em escala 24x7x365;

4.3.4.3.  Deve ser possível extrair, através do portal de serviços, relatórios por período selecionado, sendo obrigatório a extração mensal para fins de fiscalização, sobre chamados e incidentes e outras informações relevantes ao MGI;

4.3.4.4.  A CONTRATADA deverá prover documentação para acionamento do suporte técnico e operação da solução de abertura de chamado, caso necessário.

4.3.5.    Outras ferramentas além das descritas na especificação técnica da presente contratação que sejam necessárias à execução desses serviços serão de responsabilidade da CONTRATADA, sem custos adicionais para a Contratante.

4.3.6.    O suporte técnico a ser prestado pela CONTRATADA tem por objetivo a instalação, configuração, atualização, correção de falhas ou inconsistências detectadas sejam elas na gerência ou na solução dos ativos de informação, para garantir o pleno, correto e seguro funcionamento das soluções, além do esclarecimento de dúvidas dos servidores e prestadores de serviços da Contratada, para garantir a melhor utilização e maximização dos recursos contratados.

4.3.7.    Os serviços compreendem, ainda, o apoio em itens de configuração da Contratada (Sistema Operacional, Serviços, Sistemas, Banco de Dados) a fim de indicar as melhores práticas de segurança a serem adotadas.

4.3.8.    As solicitações de atendimento técnico deverão ser realizadas através de abertura de chamados.

4.3.9.    Para cada solicitação de atendimento técnico, inclusive chamados de resposta a incidentes, deverá ser gerado um identificador único (chamado) para fins de controle e acompanhamento. A CONTRATADA deverá informar esse identificador a CONTRATADA, bem como manter o histórico de ações e atividades nos chamados realizados durante toda a vigência contratual.

4.3.10.A contratante poderá efetuar um número ilimitado de chamados de suporte durante a vigência contratual.

4.3.11.O serviço de suporte será prestado em idioma português do Brasil, os casos em que o suporte envolver analistas ou especialistas em que o suporte seja prestado em outro idioma, a Contratante deverá prover um tradutor para o idioma português do Brasil.

4.3.12.Os serviços de suporte técnico/manutenção da solução deverão ser fornecidos diretamente pela CONTRATADA devidamente reconhecida por autorização direta e oficial do fabricante para os serviços descritos nesse Termo de Referência, além de certificação que comprove a habilitação para execução do serviço;

4.3.13.Os serviços de suporte técnico/manutenção da solução deverão ser prestados por técnicos devidamente certificados pelo fabricante na solução ofertada e com experiência de, no mínimo, 24 (vinte e quatro) meses,  em suporte/manutenção da solução e de 48 meses para o gerente técnico, devendo a experiência ser comprovada por meio de registros em carteira de trabalho, contratos de prestação de serviços ou outros meios considerados idôneos pelo CONTRATANTE, excluindo-se desse rol a simples informação em currículo e meras declarações.

4.3.14.A exigência de experiência mínima de 24 (vinte e quatro) meses para os técnicos e de 48 meses para os gerentes justifica-se pela especificidade e complexidade dos serviços a serem prestados, que envolvem a necessidade de sólidas e testadas competências em segurança cibernética e na própria solução. Esses períodos de experiência os colocam nas categorias pleno e sênior de experiência profissional.

4.3.15.Mesmo se a prestação do serviço envolver recursos técnicos do fabricante, caberá à CONTRATADA o cumprimento de todas as condicionantes contratuais, bem como a manutenção dos níveis contratados, e, em caso de descumprimentos, a responsabilidade recairá integralmente sobre a CONTRATADA;

4.3.16.O serviço deve analisar campanhas de malwares e incidentes gerados na gerência de administração da solução, com foco em vetores de ataque e exploração de vulnerabilidades no ambiente da Contratada;

4.3.17.Os serviços devem ser realizados através de análise humana e automatizada, contínua, 24x7x365, em busca de anomalias e potenciais atividades maliciosas no ambiente que fogem do escopo de detecção das ferramentas de segurança tradicionais.

4.3.18.Os serviços devem ser fornecidos utilizando as plataformas e soluções ofertadas. A CONTRATADA deverá apresentar e justificar a necessidade de qualquer integração externa para aprovação prévia do CONTRATANTE.

4.3.19.Os serviços de detecção e tratamento de ameaças deverá atuar de forma proativa a fim de descobrir a presença e prevenir possíveis atacantes, mesmo sem a existência de uma detecção ferramental, ou seja, a equipe não deverá restringir o início de suas atividades com base em detecções de alertas automatizados.

4.3.20.Os relatórios de incidentes deverão ser entregues de acordo com alinhamento junto a equipe de resposta a incidentes da Contratante, conforme a legislação vigente.

4.3.21.É de responsabilidade da Contratada, priorizar e fazer a triagem de alertas e possíveis incidentes de segurança.

4.3.22.Os serviços devem contemplar customizações nas soluções contratadas para o ambiente do CONTRATANTE, incluindo regras de detecção personalizadas, políticas de segurança, exceções e integrações com outras ferramentas de segurança, conforme a necessidade e aprovação prévia do CONTRATANTE;

4.3.23.Reportar os incidentes de segurança na rede do CONTRATANTE dentro da classificação do incidente e considerando o SLA estabelecido;

4.3.24.Apoiar as equipes técnicas do CONTRATANTE na resolução dos incidentes de segurança, incluindo ações de contenção, remediação e hardening nos ativos de informação, bem como recomendar configurações.

4.3.25.Acordar os canais de comunicação, visando rápida atuação entre as equipes para resolução de incidentes de segurança na rede;

4.3.26.Comunicação com as equipes do CONTRATANTE, disponibilizando o detalhamento dos eventos de segurança na rede identificados e ações de contenção recomendadas para o tratamento pelo CONTRATANTE;

4.3.27.A fim de manter o nível de segurança, e como forma de demonstrar regularmente a eficácia dos controles aplicados, a CONTRATADA realizará ou apoiará simulações controladas de intrusão na rede, com objetivo de identificar possíveis pontos fracos na implementação da solução e na postura de segurança da rede. As simulações devem ser executadas de forma automatizada e contínua, com a aprovação prévia do CONTRATANTE;

4.3.28.Analisar as tendências ao longo do tempo para identificar mudanças em padrões de tráfego, acessos e comportamento que possam indicar atividades suspeitas;

4.3.29.As atividades de suporte a usuários e as atividades do processo de resposta a incidentes de segurança deverão ser registradas pelos especialistas da CONTRATADA nas respectivas ferramentas. Para cada incidente de segurança, deverão ser documentadas as conclusões e lições aprendidas e melhorias.

4.3.30.A CONTRATADA apoiará na elaboração de operação e procedimentos no tratamento dos incidentes de segurança.

4.3.31.Mensalmente, deverão ser elaborados, no mínimo, os seguintes relatórios sobre o ambiente de rede do CONTRATANTE:

4.3.31.1.                Visão baseada na matriz ATT&CK do instituto de pesquisa MITRE, com foco em táticas e técnicas de ataque e ações tomadas.

4.3.31.2.                TOP 10 endereços IP de origem de atividades maliciosas e ações tomadas.

4.3.31.3.                TOP 10 endereços IP de destino de atividades maliciosas e ações tomadas.

4.3.31.4.                TOP 10 portas e protocolos utilizados em atividades maliciosas e ações tomadas.

4.3.31.5.                TOP 10 vulnerabilidades exploradas em ataques à rede e ações tomadas.

4.3.31.6.                TOP 10 ações dos atores de ameaça na rede e ações tomadas.

4.3.31.7.                Demonstração crítica das análises de tráfego de rede realizadas, com suas respectivas correções ou blindagens (huntings de destaque).

4.3.31.8.                Demonstração crítica do cruzamento de incidentes e ameaças na rede capturadas pela equipe de inteligência, com suas respectivas correções ou blindagens (ex: CVEs de campanhas de ransomware que exploram vulnerabilidades em redes).

4.3.31.9.                Procedimentos e regras de segurança, sejam elas automatizadas ou manuais, criadas no período.

4.3.32.O catálogo de serviços pode sofrer alterações durante a vigência do contrato.

4.3.33.Apoiar o Contratante com materiais, recursos técnicos em campanhas de conscientização sobre o uso seguro dos ativos de informação.

4.3.34.Os Níveis Mínimos de Serviço seguirão o que está estabelecido no corpo do TR (Termo de Referência).

5.     SOLUÇÃO DE MICROSEGMENTAÇÃO DE AMBIENTE CORPORATIVO

5.1.        A solução de TIC consiste no fornecimento das seguintes plataformas, componentes e serviços conforme especificações técnicas  detalhadas abaixo:

5.1.1.    A solução ofertada deve fornecer uma console centralizada que possibilite a visualização e segmentação de ambientes on-premises, incluindo servidores físicos e virtuais, clusters Kubernetes (e suas principais variações), equipamentos de OT e IoT, estações de trabalho e notebooks. Além disso, a solução deve operar de forma ?agentless? para os provedores de nuvem pública AWS, Azure e OCI.

5.1.2.    Deve suportar a microssegmentação tanto em dispositivos físicos quanto em dispositivos virtualizados (independente da tecnologia utilizada para virtualização).

5.1.3.    Deverá também estar licenciado para todos os servidores e estações de trabalho que estão no objeto desta contratação.

5.1.4.    Deve possibilitar a criação de ilhas no ambiente, onde os ativos tenham sua comunicação restrita apenas ao que for previamente identificado e liberado, principalmente no contexto de aplicações que devem ter sua comunicação liberada apenas no contexto estritamente necessário.

5.1.5.    Deverá suportar, minimamente, a instalação de agentes nos seguintes sistemas operacionais:

·        AmazonLinux;

·        Alma Linux 8 ou superior;

·        CentOS5ousuperior;

·        Debian7ousuperior;

·        OracleLinux5.8ousuperior;

·        MacOS11 (Big Sur)ousuperior;

·        Redhat5ousuperior;

·        Solaris x86 (64 bit) 10 U8 ou superior

·        Solaris SPARC (64 bit) 11.1 ou superior

·        SUSE 11 SP3 ou superior

·        Ubuntu14.04ousuperior;

·        WindowsServer 2003 (OS Windows 5.2 SP1 and SP2)

·        WindowsServer 2008 (OS Windows 6.0 SP1 and SP2)

·        WindowsServer2008R2SP1ousuperior;

·        Windows 7, 8, 10 e 11

5.1.6.    No caso de dispositivos que não possam receber os agentes, a solução deve disponibilizar um mecanismo que permita cadastrar os mesmos e criar regras para ditar como estes recursos podem interagir com a rede protegida.

5.1.7.    Deve suportar a instalação dos agentes em nuvens públicas ou privadas, independente do provedor, baseando-se apenas na compatibilidade de sistemas operacionais já citada.

5.1.8.    Deverá suportar a segmentação de ambientes em contêineres, atendendo minimamente as seguintes plataformas e tecnologias relacionadas:

5.1.9.    Plataformas de Orquestração:

·        AWS Elastic Kubernetes Service (EKS)

·        Azure Kubernetes Service (AKS)

·        Azure Red Hat OpenShift (ARO)

·        Google Kubernetes Engine (GKE)

·        IBM Cloud Kubernetes Service (IKS)

·        K3s

·        Kubernetes

·        OpenShift

·        Rancher Kubernetes Engine (RKE)

5.1.10.Container Runtime:

·        Containerd;

·        Docker;

·        CRI-O.

5.1.11.Plugins de rede:

·        AWS VPN CNI;

·        Kubenet;

·        Azure CNI;

·        Calico;

·        Flannel;

·        OpenShift SDN (OVS);

·        OVN-Kubernetes (OVN);

·        Canal.

5.1.12.A solução proposta deve permitir a segmentação das Plataformas de Orquestração mencionadas acima sem a necessidade de sidecars ou plugins CNI, como Calico e Flannel. Em vez disso, deve utilizar DaemonSets para configurar as regras de IPtables nos Pods e recorrer à API do Kubernetes para garantir visibilidade dos componentes do cluster, incluindo namespaces e serviços.

5.1.13.Deverá ser independente de hardware, ou seja, funcionar em qualquer infraestrutura de rede composta pela compatibilidade requerida já especificada.

5.2.        Características de visibilidade

5.2.1.    A solução deverá, a partir da instalação dos agentes, fornecer um mapa de dependência de aplicativos em tempo real de como a comunicação de rede está acontecendo, de forma a proporcionar o completo entendimento dos administradores para uma melhor tomada de decisão.

5.2.2.    Além do mapa visual de comunicações, a solução ainda deverá fornecer meios para filtragem específica de comunicações em modo de log na console, contendo todos os detalhes de origem, destino, portas, protocolos e aplicações internas que realizaram a comunicação.

5.2.3.    A visão detalhada dos logs deve permitir a criação de regras para fluxos detectados como bloqueados a partir de interação com os logs, apenas selecionando as comunicações desejadas.

5.2.4.    A solução deve realizar sugestões inteligentes de como a regra deverá ser criada, de forma a facilitar a ação do administrador da ferramenta.

5.2.5.    A visão detalhada do tráfego de rede deverá mostrar quais os processos do sistema operacional foram responsáveis por aquela comunicação, permitindo ainda que as regras possam controlar essa comunicação apenas quando esse mesmo processo iniciar a comunicação, garantindo que aquela comunicação de fato corresponde a aplicação de origem para a plataforma do sistema operacional.

5.2.6.    Os agentes da solução deverão alimentar continuamente a console central, de forma que o administrador de rede sempre tenha contexto atualizado sobre as comunicações que estão ocorrendo.

5.2.7.    A visibilidade gerada pela solução deverá suportar conceitos de RBAC, ou seja, segmentar a possibilidade de controle e visibilidade na console baseado no nível de permissão atribuído ao administrador autenticado na plataforma.

5.2.8.    Os dados de visibilidade deverão estar disponíveis para consulta na console por pelo menos 90 dias.

5.3.        Regras de segmentação e visibilidade

5.3.1.    A solução deverá permitir a criação de rótulos a serem aplicados nas cargas de trabalho, de maneira que a identificação dos servidores e aplicações do ambiente sejam facilmente reconhecidos.

5.3.2.    Os rótulos deverão suportar o conceito de escopo da rede, ou seja, produção, homologação e desenvolvimento, assim como a qual ambiente e localização o ativo está incluso.

5.3.3.    As regras deverão ser criadas baseadas em dois critérios principais, sendo eles: Escopo interno, ou seja, apenas entre serviços pertencentes a mesma aplicação identificada ou também no contexto de escopo externo, no caso de aplicações diferentes que precisam de comunicação de rede entre si.

5.3.4.    Todos os rótulos e atributos definidos nos tópicos anteriores deverão estar disponíveis amplamente para criação de políticas, seja pelo papel que o ativo executa, ou aplicação representada, ambiente ou localização.

5.3.5.    As regras deverão possibilitar a criação granular, baseado nos rótulos e atributos solicitados, baseados em origem, destino, porta, protocolo, aplicação e processos do sistema operacional.

5.3.6.    As regras também deverão conseguir utilizar listas de IPs, sub redes, FQDNs, range de portas e portas customizadas para controles específicos.

5.3.7.    Deverá suportar a utilização de portas dinâmicas, ou seja, baseado no processo do sistema operacional e não em um range específico.

5.3.8.    A solução deverá permitir a duplicação de políticas por parte do administrador, de forma a facilitar o processo de criação de regras.

5.3.9.    A solução deverá possuir, de forma nativa, templates de política para serviços como Microsoft Active Directory, SQL Server, SharePoint, Exchange, Microsoft System Center, Sharepoint e Windows Server Update Service, já contendo todas as portas, protocolos e processos catalogados e com regras criadas, de forma a facilitar a implementação inicial sem impactos na rede corporativa.A solução deverá suportar a importação e exportação de políticas pela console administrativa.

5.3.10.A solução deverá permitir a atribuição de políticas em grupos específicos de hosts ou em hosts específicos.

5.3.11.No caso de remoção do agente da solução, todas as regras criadas deverão ser imediatamente removidas.

5.3.12.A solução deverá possuir integração nativa com scanners de vulnerabilidade para controle contextual de ativos com base nas vulnerabilidades que ele possui.

5.3.13.A solução deverá permitir integração com Active Directory para controle de regras de acesso baseado em grupos do Active Directory.

5.3.14.A solução deverá suportar meios para visualização de impacto das políticas antes de aplicação de modificações das mesmas.

5.3.15.A visibilidade da solução deverá permitir facilmente a identificação de quais tráfegos estão ocorrendo por qual política de definida e até mesmo se não existe uma política para o tráfego identificado.

5.3.16.A aplicação de políticas não deverá impor a criação de nenhuma camada de firewall nos hosts protegidos, ou seja, visando não gerar sobrecarga nos mesmos, o agente da solução deverá apenas orquestrar o firewall nativo dos sistemas operacionais para aplicação de todas as regras definidas na console.

5.3.17.No caso de dispositivos Windows, a aplicação das políticas (enforcement) deverá ser realizada por meio da orquestração do Microsoft Windows Filtering Platform nativo do sistema operacional, sem a necessidade sobrecarregar o mesmo com camadas de software adicionais.

5.3.18.No caso de dispositivos Linux, o enforcement das políticas deverá ser realizado através da orquestração do Linux IP Tables nativo do sistema operacional, sem a necessidade sobrecarregar o mesmo com camadas de software adicionais.

5.3.19.O enforcement de políticas e instalação do agente não deverá requerer nenhum tipo de modificação no kernel do sistema operacional.

5.3.20.A solução deverá suportar o controle de políticas para regras de inbound e outbound no firewall dos ativos protegidos.

5.3.21.Deverá ser possível a criação de regras para ?isolamento? de ativos na rede, de forma que a comunicação dos mesmos seja restrita apenas ao que tenha sido previamente definido, impedindo, por exemplo, que ativos contaminados por ameaças possam se comunicar na rede com os demais servidores do datacenter.

5.3.22.Deve possibilitar a integração com recursos IPSEC nativos do sistema operacional para criptografar o tráfico entre componentes protegidos pela solução.

5.3.23.As políticas da solução devem possibilitar a coexistência com políticas de firewall que já existam em determinados hosts protegidos.

5.3.24.Deve permitir a identificação e proteção do ambiente a partir de componentes que não tenham o agente instalado.

5.3.25.O agente da solução deve se automonitorar quanto a falhas de processo ou eventos de adulteração e reiniciar, se necessário, para garantir a funcionalidade contínua.

5.3.26.O agente da solução deve monitorar continuamente as regras aplicadas evitando assim que as mesmas sejam modificadas ou mesmo eliminadas (?anti tampering?).

5.3.27.O agente deve ser protegido por uma senha adicional prevenindo a remoção acidental ou proposital do mesmo.

5.3.28.Deverá reter ao menos as 1.000 versões da política para rollback em caso de necessidade e remoção automática das versões mais antigas para melhorar o desempenho.

5.4.        Gestão de vulnerabilidades

5.4.1.    A solução deverá possuir integração nativa com scanners de vulnerabilidade para realizar o controle contextual de ativos com base nas vulnerabilidades identificadas nos mesmos.

5.4.2.    Deve possuir integração com os seguintes fabricantes de scanners de vulnerabilidade: Nessus Professional, Qualys, Tenable Security Center, Tenable.io e Rapid7.

5.4.3.    A solução deverá gerar visões específicas, a partir da ingestão de dados de vulnerabilidades, sobre como as portas e aplicações vulneráveis estão se comunicando na rede corporativa.

5.4.4.    A partir desta integração, deverá ser possível visualizar o nível de risco do ativo durante a análise de tráfego da rede corporativo.

5.4.5.    O risco de exposição deverá ser calculado para cada carga de trabalho, fornecendo uma medição numérica com base no número e na gravidade das vulnerabilidades em uma carga de trabalho combinada com todos os caminhos que conectam uma porta vulnerável.

5.4.6.    Quando não existir a possibilidade de correção da vulnerabilidade do ativo, a solução deverá fornecer sugestões de ajustes para regras de micros segmentação daquele ativo, de forma a mitigar o maior número possível de brechas do mesmo.

5.5.        Arquitetura e implementação

5.5.1.    A solução deverá ser compatível com o modelo SaaS ? Software as a Service, ou seja, não deve requerer nenhum tipo de instalação de componentes ou máquinas virtuais no ambiente para funcionamento de seus componentes administrativos.

5.5.2.    A plataforma SaaS do fornecedor deve possuir certificação SOC 2 Tipo 2 emitido por auditor independente.

5.5.3.    Os agentes devem se comunicar diretamente com a plataforma SaaS sem a necessidade de agregadores caracterizando- se assim uma aplicação de duas camadas.

5.5.4.    O agente deverá suportar a utilização de servidores proxies caso o seguimento de rede não possua comunicação direta com a internet.

5.5.5.    Os componentes administrativos da solução não deverão possuir dependência de nenhum outro componente de rede ou infraestrutura para o seu perfeito funcionamento.

5.5.6.    A implementação do agente deverá ser compatível com ferramentas de deployment de software de uso geral como SCCM, Chef, Ansible, Puppet ou outra que seja passível de execução de um script shell ou PowerShell.

5.5.7.    Deve proporcionar a instalação do agente de forma manual, através de msi e scripts já elaborados e disponibilizados pelo fabricante da solução.

5.5.8.    O processo de remoção e atualização de versão dos agentes deverá seguir os mesmos modelos já definidos de instalação.

5.5.9.    Deve ser possível a implementação dos agentes em modo apenas de monitoramento, fornecendo visibilidade do tráfego para que o administrador da solução criar regras e planejar a mudança para modo bloqueio com visibilidade e contexto de todo o tráfego de rede.

5.5.10.A solução deverá permitir a criação de políticas, fornecendo apenas a visibilidade e impacto das mesmas, para posterior provisionamento da mesma e enforcement das regras.

5.5.11.Deve permitir integração via SAML 2.0 com IDPs externos, como no mínimo o Microsoft Azure ADEntra, possibilitando autenticação na console administrativa a partir de um usuário gerenciado internamente pela CONTRATANTE.

5.5.12.Deve possuir auditoria para rastreamento de todas as modificações realizadas na console administrativa.

5.5.13.Deve possibilitar a capacidade de filtragem de tráfego com base em aplicações, rótulos, ambientes, período de tempo, status da política, etc. Permitindo ainda exportação dos logs para consumo externo a ferramenta.

5.5.14.Não deve haver limitação de número de regras e quantidade de tráfego a ser analisado pela ferramenta.

5.5.15.A comunicação entre o agente e a console central deve ser criptografada.

5.6.        API e integrações

5.6.1.    A solução deve possuir uma API forte e bem documentada.

5.6.2.    Via API dever ser possível realizar operações em políticas e controlar os ativos da solução.

5.6.3.    Deve ser baseada em HTTP e ser compatível com métodos GET, PUT, POST e DELETE.

5.6.4.    Deve ser autenticada via chave a ser gerada no portal da solução.

5.6.5.    Deve possibilitar integração com ferramentas DevOps como Chef, Puppet, Ansible, Terraform e SCCM.

5.6.6.    Deve possuir integração com ferramentas de SIEM, sendo no mínimo suportado as soluções Sentinel, QRadar, Splunk ou Arcsight.

5.6.7.    Deve possuir integração com as seguintes ferramentas de SOAR: IBM QRadar (SOAR), e Palo Alto Cortex (SOAR)

5.6.8.    Deve possuir integração com Servicenow CMDB

6.     SOLUÇÃO DE CORRELAÇÃO DE EVENTOS DE SEGURANÇA E RESPOSTA A INCIDENTES - SIEM

6.1.        Arquitetura

6.1.1.    Deve ser baseada em nuvem (Cloud), de forma a manter todos os eventos armazenados na nuvem do fabricante da solução.

6.1.2.    Não serão aceitos serviços entregues por meio de software livre ou open-source.

6.1.3.    A solução deve fornecer componentes já licenciados para coleta e envio de logs/tráfego até a plataforma central.

6.1.4.    O componente para coleta de logs/tráfego deve fornecer a possibilidade de instalação em servidores Windows, Linux ou imagens prontas previamente fornecidas.

6.1.5.    Deverá estar licenciada, em nome do Ministério de forma a manter o processamento em tempo real ou realizar o buffer dos eventos, mesmo que o tráfego de eventos ultrapasse o volume licenciado nas horas de pico.

6.1.6.    Deve possuir capacidade de recebimento e armazenamento, mínimo, de todos os logs de ativos de segurança, alertas de segurança, tráfego de pacotes, dentre outras informações relacionadas, em formado bruto (raw) e/ou metadados, necessárias para fins de correlacionamento e forense, conforme especificação abaixo:

6.1.7.    Deve ter a capacidade de manter os itens coletados indexados para buscas rápidas por pelo menos 7 dias. Itens a serem buscados em datas superiores ao período de indexação devem respeitar o período de retenção do tópico anterior.

6.2.        Requerimentos Gerais

6.2.1.    Deverá ser capaz de gerenciar de forma eficiente incidentes de segurança. O software de gerenciamento de incidentes de segurança deve permitir a definição de um processo abrangente desde o registro e triagem inicial de um incidente até sua resolução e prevenção.

6.2.2.    Deve permitir a automação de fluxos de forma gráfica, incluindo estágios, tarefas paralelas ou sequenciais, regras de decisão e aprovação, sem a necessidade de programação ou alteração de código fonte para as integrações já existentes.

6.2.3.    Deve permitir automatização e orquestração de fluxos relacionados a resposta de incidentes de segurança, integrando e simplificando as operações.

6.2.4.    Deve fornecer visibilidade, rastreabilidade e indexação dos eventos detectados, integrando as várias ferramentas de segurança que a entidade possui, aumentando a capacidade de detecção e maturidade da segurança cibernética.

6.2.5.    Deve permitir acelerar a resposta às lacunas de segurança cibernética por meio de análise contextual, automação de processos e capacidade de articulação para investigação, utilizando fluxos de análise e inteligência associada às metodologias de ataque de grupos de cibercrime.

6.2.6.    Deve identificar, registrar e indexar incidentes de segurança rapidamente, registrando os eventos relatados pelas soluções que a CONTRATADA atualmente possui.

6.2.7.    Deve permitir integração e interoperabilidade com o ecossistema de segurança da entidade, independentemente da marca dos produtos de segurança utilizados.

6.2.8.    Deve permitir a integração baseada em fluxos de trabalho através do cruzamento de dados das soluções de segurança como Firewalls, IPSs e sistemas de chamados.

6.2.9.    Deve possuir controle granular de níveis de acesso a plataforma.

6.2.10.Deve funcionar, obrigatoriamente, com autenticação de dois fatores nativa, sendo no mínimo eles: OTP, SMS ou voz.

6.2.11.Deve permitir que se configure políticas restritas de senha como período de redefinição, bloqueio por tentativas sem sucesso, histórico de senha e desativação de usuários por tempo de inatividade.

6.2.12.Deve registrar e listar todos os alertas ativos, permitindo filtros e pesquisas sob demanda em uma linguagem de queries.

6.2.13.Deve permitir a criação de listas a serem utilizadas durantes as pesquisas, com objetivo de poder facilmente utilizá-las para inclusão ou remoção de recursos na busca, evitando a repetição de comandos, tornando as ações de caça a ameaças (hunting) mais ágeis.

6.2.14.Deve possuir alertas indicando a gravidade do incidente, permitindo a detecção, validação e investigação, a fim de reconstruir toda a cadeia do ataque.

6.2.15.Deve suportar uma linha do tempo visual em relação aos eventos registrados.

6.2.16.Deve oferecer suporte à integração com soluções de segurança de terceiros. A integração deve ser baseada em syslog, ingestão/absorção de alertas e/ou análise de tráfego de rede.

6.2.17.Deve permitir a criação de painéis e dashboards com gráficos de gestão, de forma ágil e intuitiva, sem a necessidade de programação e alteração do código-fonte.

6.2.18.Deve permitir aos atendentes e solucionadores de incidentes a possibilidade de criação de seus próprios painéis e gráficos dentro da solução, compartilhando sempre que necessário com grupos ou usuários específicos, permitindo gerenciamento das permissões de compartilhamento de acordo com os perfis de cada usuário.

6.2.19.Deve permitir a criação de gráficos, utilizando como origem de dados, as informações de diferentes soluções de segurança da organização.

6.2.20.Deve permitir configurar o envio automático e agendado de relatórios e gráficos gerenciais para grupos de usuários ou usuários específicos.

6.2.21.Deve incluir painéis unificados, buscas e relatórios, para facilitar a transição da detecção para a investigação e a resposta subsequente ao incidente relatado.

6.2.22.O coletor da solução deverá ser capaz de coletar, aplicar parsing, normalizar e categorizar os eventos dos dispositivos monitorados em tempo próximo ao real.

6.2.23.Deve possuir parsing, para interpretação automática de logs, para pelo menos as seguintes marcas/soluções:

·        Aerohive;

·        Akamai;

·        AWS;

·        Apache;

·        Arbor;

·        ArcSight;

·        Aruba;

·        Barracuda;

·        BeyondTrust;

·        BlueCoat;

·        Broadcom;

·        Brocade;

·        Carbom Black;

·        CheckPoint;

·        Cisco;

·        Citrix;

·        Crowdstrike;

·        CyberArk.

·        Cylance;

·        Docker;

·        Eset;

·        F5;

·        FireEye;

·        Forcepoint;

·        Forescout;

·        Fortinet;

·        Graylog;

·        Huawei

·        HP;

·        IBM;

·        Imperva;

·        Juniper;

·        Mandiant;

·        McAfee;

·        Microsoft;

·        Nagios;

·        Nginx;

·        Oracle;

·        Palo Alto;

·        Proofpoint;

·        Pulse Secure;

·        Riverbad;

·        RSA;

·        SonicWall;

·        Sophos;

·        Splunk;

·        Symantec;

·        Tenable;

·        Trend Micro;

·        Varonis;

·        Digital Guardian;

·        Veritas

·        Vmware;

·        WatchGuard;

·        Zscaler.

6.2.24.Deve fornecer um módulo de UEBA ao qual possa ser utilizado para análise avançada do comportamento de entidades (computadores e usuários) aos quais podem estar envolvidos em atividades maliciosas. O módulo de UEBA deve utilizar técnicas avançadas para análise de comportamento sendo possível correlacionar eventos e extrair informações relevantes as quais devem ser utilizadas para definir o perfil de risco das entidades.

6.2.25.Deve analisar os tipos de log enviados e realizar sugestões de envio de importantes fontes de detecção de malware na qual ele não está recebendo logs. Exemplo: a organização não está enviando logs de firewall e DHCP, tais logs ampliam o poder de detecção da plataforma. Este recurso deve estar em execução automaticamente.

6.2.26.Deve possuir dashboards e relatórios que classifiquem os logs que foram devidamente classificados, permitindo também a rápida visualização dos que não foram, para que as ações de "parsing" possam ser planejadas.

6.2.27.Deve possuir dashboards prontos que são alimentados a partir da ingestão de logs para pelo menos, os seguintes fabricantes:

·        AWS;

·        Carbon Black;

·        Checkpoint;

·        Cisco;

·        Crowdstrike;

·        Druva;

·        FireEye;

·        Fortinet

·        Google Cloud Plataform;

·        Huawei

·        Imperva;

·        McAfee;

·        Microsoft;

·        Microsoft Azure;

·        Okta;

·        Palo Alto;

·        Proofpoint;

·        Sophos;

·        Symantec;

·        Veritas

·        VMware

6.2.28.Deve possuir meios de monitoramento de saúde de todos os sensores que enviam logs para a console central.

6.2.29.Caso alguma fonte pare de enviar logs, a plataforma deve informar automaticamente os administradores para verificação.

6.2.30.Deve possuir nativamente integrações para serviços de nuvem, considerando minimamente:

·        AWS CloudTrail;

·        AWS CloudWatch;

·        AWS GuardDuty;

·        AWS S3;

·        AWS Security Hub;

·        AWS VPC Flow Logs;

·        Azure;

·        Azure Active Directory (Para UEBA);

·        Bitglass;

·        Box.com;

·        Canary;

·        CipherCloud CASB+;

·        Cisco Umbrella;

·        Cisco Umbrella S3;

·        Corelight;

·        Crowdstrike Falcon;

·        CSC Global Domain Manager;

·        Digital Guardian;

·        Druva;

·        Duo Auth;

·        Entrust Intellitrust;

·        FireEye Detection on Demand for AWS S3;

·        FireEye Email Threat Prevention;

·        FireEye Message Security for Slack;

·        FireEye Messaging Security for Microsoft 365;

·        FireEye Network Security;

·        Google Cloud;

·        Google Cloud Audit Events;

·        Kentik;

·        McAfee MVision Mobile;

·        Microsoft CASB;

·        Microsoft Graph;

·        Microsoft Office 365;

·        Mimecast;

·        Netskope;

·        Okta;

·        Proofpoint CASB Integration;

·        Proofpoint SIEM Integration;

·        Qualys File Integrity Monitoring;

·        Security Onion;

·        Signal Sciences WAF;

·        Sophos Antivirus SIEM Integration;

·        Symantec Mobile Protection;

·        Symantec Web Security Service;

·        Windows Defender ATP;

·        Zimperium.

6.3.        Inteligência de Ameaças

6.3.1.    Deve incluir regras de correlação e inteligência de ameaças.

6.3.2.    Deve incluir um pacote de regras para detecção. Elas devem ser alimentadas automaticamente, sem gerar impacto ou solicitar intervenção de um analista. Por sua vez, ela deve permitir a criação de regras personalizadas pela CONTRATADA, incluído a entrada manual de novos indicadores de comprometimento.

6.3.3.    Deve fornecer uma boa variedade de regras de inteligência já criadas e disponíveis para detecção de ameaças e permitir customização de novas para atender necessidades específicas.

6.3.4.    Deve incluir inteligência de ameaças que revise, valide e compare as fontes que estão sendo utilizadas para detecção de ameaças.

6.3.5.    Deve incluir a descrição das famílias de malware.

6.3.6.    Deve fornecer atribuição automática de alertas a grupos de APTs.

6.3.7.    O fabricante deve possuir especialistas em segurança que estejam monitorando as ameaças atuais ao redor do mundo, gerando a partir disso, novos pacotes de regras para aprimorar a solução em seu nível de detecção. Tal serviço não deve ocasionar custo adicional para a CONTRATANTE.

6.3.8.    O fabricante deve rastrear grupos de crimes cibernéticos, a fim de aprimorar regras de detecção a partir de incidentes globais.

6.3.9.    Deve utilizar uma rede de inteligência que processa diversas amostras de malware exclusivas por dia.

6.3.10.Deve injetar inteligência nos dados de log registrados.

6.3.11.Deve oferecer análises sobre "beaconing", permitindo no mínimo, a detecção de malwares que tentam estabelecer contato com ?Command and Control?.

6.3.12.Deve incluir como fonte de inteligência as ameaças, plataformas de segurança contratadas e permitir identificar a telemetria e o perfil de proliferação de um ataque, além de ter informações sobre vítimas e táticas, técnicas e procedimentos geralmente utilizados pelo invasor.

6.3.13.Deve possibilitar consultas de segurança específicas (Buscando referências a malwares ou ataques conhecidos), incluindo análise, para no mínimo:

·        URLs;

·        Domínios;

·        Hashes MD5;

·        Endereços IP.

6.3.14.Deve permitir a criação de listas a serem utilizadas com escopo de inteligência, facilitando assim o uso delas em regras ou mesmo para customizar detecções especificas do negócio.

6.3.15.Deve fornecer a possibilidade de análise de malwares, executando o mesmo de maneira controlada (sandbox), a fim de receber um relatório sobre os comportamentos encontrados com a execução.

6.3.16.Depois que uma ameaça for detectada, ela deve relacionar as informações registradas na plataforma central e as vincular fornecendo detalhes de inteligência.

6.3.17.Deve oferecer análises mínimas em:

·        Beaconing;

·        Beaconing Diferencial;

·        Geo-feasibility;

·        Uso indevido de credenciais;

·        Detecção de conexão não reconhecida;

·        Detecção de Fast-Flux DNS;

·        Entropia DNS;

·        Detecção de ataques via PowerShell;

·        Detecção de Exfiltração de Dados;

·        Detecção de conexões de entrada SSH, Telnet, SMB e RDP que sejam anômalas;

·        Detecção de contas comprometidas com VPN;

·        Detecção de movimento lateral.

6.3.18.Deve permitir que sejam realizadas pesquisas em seu ambiente para atividades de "caça" a malwares e atividades maliciosas.

6.3.19.Deve possuir capacidade analítica de eventos/tráfego, independente das regras, para detecção de no mínimo os seguintes comportamentos:

·        Uso suspeito de chave da API Amazon Web Services (AWS);

·        Login de autenticação multifator anormal do Duo com base no histórico de login anterior deste usuário;

·        Atividade anormal do Google Cloud Platform (GCP) por um usuário;

·        Logon anormal no Microsoft Office 365 com base no histórico de logon anterior deste usuário;

·        Login anormal do Okta com base no histórico de login anterior deste usuário;

·        Login anormal do protocolo RDP (Remote Desktop Protocol) com base no histórico de login anterior deste usuário;

·        Download ou upload anormal de arquivo do SharePoint com base no histórico anterior deste usuário;

·        Detecção de força bruta do Citrix NetScaler, realizando verificações de pulverização de senha e logons bem-sucedidos da mesma fonte.

·        Detecção de força bruta no Druva, realizando verificações de pulverização de senha e logons bem-sucedidos da mesma fonte.

·        Tráfego de rede para domínios semelhantes a (permutações) do domínio da organização descoberto. Isso pode indicar um ataque de phishing ou alguma outra atividade suspeita.

·        Detecção de força bruta no Linux, realizando verificações de pulverização de senha e logons bem-sucedidos da mesma fonte.

·        Detecção de força bruta do Office 365, realizando verificações de pulverização de senha e logons bem-sucedidos da mesma fonte.

·        Okta detecção de força bruta. Isso realiza verificações de pulverização de senha e logons bem-sucedidos da mesma fonte.

·        Vários logins de RDP pelo mesmo usuário.

·        Vários logins de RDP no mesmo host.

·        Login de VPN anormal com base no histórico de login de VPN anterior do usuário.

·        Uma conta de usuário foi excluída dentro de 24 horas após sua criação.

·        Detecção de força bruta do Windows NT LAN Manager (NTLM), realizando verificações de pulverização de senha e logons bem-sucedidos da mesma fonte.

·        Vários erros de "usuários únicos não encontrados" de uma fonte. Isso pode indicar uma tentativa de enumeração do usuário.

·        Vários processos exclusivos de um usuário ou host dentro de um curto período. Isso pode indicar atividade de reconhecimento.

6.4.        Capacidades de Investigação

6.4.1.    Deve incluir recursos de workflow para resposta a incidentes de segurança.

6.4.2.    Deve ser capaz de coordenar os processos de segurança atuais no nível de alertas de rede e alertas de outras soluções de segurança.

6.4.3.    Deve fornecer recursos de busca e pesquisa nas estações de trabalho, de acordo com os seguintes exemplos:

·        Ampla pesquisa por comportamentos maliciosos conhecidos;

·        Caça proativa de atividades suspeitas;

·        Investigação completa nos endpoints comprometidos;

·        Procurar evidências de intrusões avançadas como ameaças sem arquivo (fileless).

6.4.4.    Deve fornecer recursos de resposta em tempo real, para no mínimo:

·        Investigar todos as atividades em terminais suspeitos;

·        Reproduzir a linha do tempo completa de um ataque avançado;

·        Capturar detalhes da atividade que ocorreu durante intrusões;

·        Executar uma análise aprofundada no nível de: Acesso ao disco, análise de memória e detecção de rootkit.

6.4.5.    Depois que a solução detectar um alerta, a mesma deve fornecer pelo menos as seguintes informações:

·        A inteligência em torno do alerta detectado;

·        Métodos de detecção da ameaça em questão;

6.5.        Mostrar graficamente uma linha do tempo de eventos relacionados ao alerta detectado;

·        Dicas de pesquisa para orientar os analistas em todo o processo de resposta a incidentes. Essas dicas devem estar associadas à experiência que o fabricante tem em responder a incidentes críticos de segurança em empresas em todo o mundo;

·        Mostrar os eventos brutos (raw data) que geraram o alerta;

·        Histórico de eventos associados.

6.5.1.    A visualização de um caso deve permitir pelo menos, as seguintes ações:

·        Controle do Nome, Status, Prioridade, Classificação e Descrição do caso;

·        Permitir que o caso seja assinado para algum usuário;

·        Permitir que qualquer log/evento relacionado possa ser adicionado e visualizado no mesmo;

·        Permitir a visualização de todos os alertas/incidentes envolvidos no caso;

·        Permitir que o caso seja exportado em formatos CSV e JSON;

·        Permitir a adição e visualização de comentários no caso.

6.5.2.    Deve incluir dicas intuitivas de investigação, trazendo automaticamente no mínimo, os seguintes dados para consulta no alerta:

·        Existem outras regras alertadas para esse IP de origem?

·        Existem regras acionadas que foram baseadas em sensores de inteligência, relacionadas a algum desses índices de comprometimento?

·        Quais logs estão disponíveis para este dispositivo?

·        Quais logs estão disponíveis para este IP?

·        Em quais outros hosts esse malware foi encontrado?

·        Existem outros logs com esse hash?

·        Existem alertas relacionados usando o IP do agente?

·        Existem alertas relacionados usando o este dispositivo?

·        Existem alertas relacionados usando o hash envolvido no incidente?

6.5.3.    No nível analista/operador, Deve fornecer:

·        Um painel de pesquisa, onde são registrados alertas e casos atribuídos aos analistas;

·        Detalhe de alertas como: nível de risco, nome do alerta, tipo de alerta, origem, data da primeira ocorrência, data da última ocorrência, número de eventos, resumo, fontes e destino, status do alerta e opções de: exportação do alerta nos formatos CSV e JSON para excluir eou fechá-lo;

·        Cada alerta deve poder ser atribuído a um analista específico, para iniciar o processo de investigação, contenção, caça, etc.;

·        Deve haver um painel de casos, que permita a criação, gerenciamento e alocação de casos, a fim de rastrear as atividades e o tempo de resposta de cada analista;

·        Cada caso pode conter vários alertas, várias anotações, para validar o estado evolutivo na resposta a um incidente;

·        A ferramenta deve poder atribuir a cada caso níveis de: prioridade, gravidade e, como opção, outro tipo de classificação;

·        Cada caso deve ter: Descrição, Eventos, Alertas, Revisões e Notas, bem como o registro do qual o analista foi designado ou modificou o caso.

6.5.4.    Deve ter a capacidade de realizar pesquisas para o processo de busca proativa e reativa nos eventos e metadados coletados de maneira automática.

6.5.5.    Deve ter um módulo de pesquisa avançada ou indexação de pesquisa que contenha:

·        Um módulo de ajuda de sintaxe;

·        Um módulo de histórico de pesquisas;

·        Um módulo de pesquisa salva como favorita;

·        Capacidade de salvar a pesquisa.

6.5.6.    As pesquisas devem ter uma sintaxe completa baseada em Query Language contemplando documentação completa e atualizada.

6.5.7.    Deve incluir opções de pesquisa, com base em cada um dos campos de metadados, como:

·        Domínio;

·        porta de destino;

·        método HTTP;

·        metaclasses;

·        porta de origem;

·        useragent;

·        IP de Origem;

·        IP de destino, etc.

6.5.8.    Deve possuir um módulo de UEBA ao qual poderá ser utilizado para melhor compreensão dos eventos, identificando possíveis entidades (equipamentos ou usuários) envolvidos anteriormente em outros eventos maliciosos ou suspeitos.

6.5.9.    A visualização de um alerta/incidente deve permitir pelo menos, as seguintes ações:

·        Assinar o incidente para um analista;

·        Marcar como falso positivo;

·        Adicionar o alerta em um caso para um trabalho aprofundado envolvendo mais pessoas e artefatos de investigação;

·        Fechar ou suprimir o alerta;

·        Exportar o alerta para CSV ou JSON;

·        Fazer pesquisas de Índices de comprometimento diretamente em bases externas como VirusTotal e DomainTools;

·        Adicionar através de um clique, artefatos em listas para facilitar o trabalho de investigação e melhorar a assertividade das regras de detecção;

·        Visualizar a correlação de índices de comprometimento em outros incidentes abertos ou fechados;

·        Consultar análises realizadas automaticamente em bases de inteligência cibernética;

·        Analisar o histórico de modificações no incidente;

·        Adicionar comentários no incidente;

·        Quando realiza análise em sandbox para artefatos envolvidos em incidentes, permitir a visualização das modificações que o binário realizou.

6.5.10.Ao visualizar um tipo de evento, a plataforma deve permitir, a partir de cliques com o mouse (Sem necessidade de escrita de query), incrementar as buscas, para pelo menos as seguintes ações:

·        Realizar uma busca por qualquer campo daquela classe. Exemplo: Ip de origem/destino, hash md5, destinatário/remetente, ações aplicadas, etc;

·        No caso de uma busca já estar sendo realizada, deve ser possível adicionar qualquer campo listado na busca atual para seguimento das atividades de hunting;

·        Deve ser possível também realizar exclusões na busca a partir do valor de qualquer campo listado;

·        Dever ser possível realizar um agrupamento de qualquer valor listado, formando automaticamente um dashboard, estabelecendo as contagens e classificações de acordo com os valores dos campos;

·        Quando visualizado algum índice de comprometimento, deve ser possível realizar pesquisas em bases externas como VirusTotal e DomainTools;

·        Deve ser possível adicionar índices de comprometimento em listas para facilitar as buscas e criação de regras.

6.5.11.Deve permitir que as buscas mais realizadas sejam salvas para execução rápida sempre que necessário.

6.5.12.Toda busca realizada deve ter a possibilidade de ser transformada em uma regra para detecção de comportamentos desejados.

6.6.        Orquestração e Automatização

6.6.1.    A arquitetura da plataforma de orquestração deve ser moderna e granular ao ponto de ao menos possuir as seguintes segmentações de seus serviços:

·        Serviço para orquestração;

·        Serviço Web para acesso a interface de gerência;

·        Ambiente virtual para execução de playbooks;

·        Ambiente isolado para interpretações do OS;

·        Serviço de banco de dados para gestão e armazenamento de dados o orquestrador;

·        Serviço de filas;

·        Database para armazenamento de informações do serviço de filas;

·        Serviço para tratativas de I/O do sistema web;

·        Serviço para tratativas de execução do serviço de fila;

·        Serviço de agendamento de comandos.

6.6.2.    Deve possuir uma interface gráfica que contemple ao menos os itens abaixo para melhor organização, gerência e ação durante possíveis investigações ou automatizações de atividades internas.

·        Dashboard;

·        Guia de chamados;

·        Playbooks;

·        Dispositivos;

·        Adaptadores;

·        Tabelas;

·        Tags;

·        Formulários;

·        Scripts;

·        Tipos;

·        Biblioteca.

6.6.3.    Deve possuir plugins predefinidos e compatíveis com as diferentes tecnologias que a entidade possui no nível de segurança cibernética.

6.6.4.    Deve fornecer uma biblioteca de plug-ins que permita integrar fluxos de trabalho e automação com vários tipos de tecnologias, para no mínimo:

·        TIPs - plataformas de inteligência;

·        Ferramentas de análise de malware;

·        EDR - Detecção e resposta do terminal;

·        SIEM;

·        Armazenamento - baseado em nuvem;

·        Sistemas de chamados;

·        Soluções de endpoint;

·        Firewalls;

·        Switches;

·        Ferramentas de sandbox;

·        Servidores de email;

·        Ferramentas de chat;

·        Dispositivos móveis etc.

6.6.5.    A solução deve ter um ambiente gráfico que permita a criação dos fluxos para interação com as diferentes tecnologias.

6.6.6.    A solução deve permitir a automação das atividades de resposta a incidentes com base nas necessidades e processos da entidade.

6.6.7.    A solução deve poder registrar as métricas de desempenho e tempo economizado nas tarefas usando a orquestração.

6.6.8.    Deve permitir etapas para escalação e aprovação em fluxos de trabalho.

6.6.9.    Deve suportar a definição de tarefas ou ações assíncronas.

6.6.10.A solução deve suportar SMTP para envio de e-mails.

6.6.11.Deve permitir nível de acesso a console e componentes de forma granular.

6.6.12.No nível de gerenciamento de caso/ticket a solução deve ser capaz de alterar dinamicamente a prioridade dos casos, alterar a atribuição e o status de acordo com o fluxo definido.

6.6.13.Deve permitir a criação de novos plugins, além de fornecer a habilidade de customização de playbooks através de linguagens de programaçãopara criação de templates.

6.6.14.Deve fornecer um serviço HTTP server para receber informações através de um método POST e então converter o conteúdo recebido para JSON a fim de obter melhores integrações e expandir as capacidades com integrações web.

6.6.15.Deve suportar operações básicas no processamento de fluxo, como:

·        Realizar operações matemáticas básicas (+, -, *, /,%, **), suportando retornar o resultado com decimais ou números exatos (arredondados);

·        Suporte à pesquisa de arquivos, tipo de documento de conteúdo que corresponda a uma expressão regular. Deve suportar documentos do tipo: csv, doc, docx, eml, epub, gif, jpg, json, html, msg, odt, ogg, pdf, png, pptx, ps, rtf, tiff, txt, wav, xlsx, zip;

·        Programar a ocorrência de eventos no futuro semelhante para Windows ou Unix;

·        Conectar-se a um servidor IMAP eou POP3;

·        Executar localmente os seguintes comandos: Ping, Telnet para uma porta, traceroute, whois eou aguardar alguns segundos;

·        Exibir hora local;

·        Operar arquivos locais através das seguintes operações: criar arquivos, adicionar a um arquivo (anexar), excluir arquivos, mover arquivos, ler arquivos, listar diretórios etc.;

·        Ler um feed RSS;

·        Realizar uma captura de tela de uma página do site. Deve suportar o uso de proxy e permitir armazenar a imagem em um arquivo;

·        Enviar dados através de uma porta TCP;

·        Oferecer suporte ao SFTP, através das seguintes operações: Listar diretório, ver se existe um arquivo, ver se existe um diretório, buscar um arquivo, buscar um diretório e seu conteúdo recursivamente, fazer upload de um arquivo;

·        Enviar uma mensagem via SMTP;

·        Executar comandos remotamente via SSH e coletar a saída de execução assim como seus erros de execução;

·        Criar um elemento STIX a partir de um indicador de consolidação do índice de comprometimento (Hash, IP, URL, HostName, Domínio);

·        Gerar uma solicitação HTTP para uma API Web;

·        Oferecer suporte ao uso de cabeçalhos HTTP personalizados;

·        Importar arquivos a serem utilizados em ações do playbook;

·        Adicionar tags para fácil identificação de ativos envolvidos em um playbook;

·        Possuir a capacidade de executar sequências condicionais que mudem a direção ou fluxo de um playbook em execução.

6.6.16.Deve suportar a interpretação de dados como:

·        Extrair o domínio de uma URL;

·        Extrair o domínio de um email;

·        Extrair um ou mais URLs de um texto;

·        Codifique um texto em base64;

·        Decodifique base64 em texto;

·        Decodifique um texto JSON usando uma expressão jsonpath;

·        Extrair um subtexto do XML usando um filtro xpath;

·        Codifique uma string usando urlEncode;

·        Decodifique um URL usando urlDecode;

·        Resolver do IP para o domínio;

·        Resolver do domínio para o IP;

·        Converter de texto em campo Hash MD5;

·        Filtrar de uma lista de textos aqueles que contêm um determinado subtexto;

·        Aplicar uma substituição em expressão regular;

·        Verificar se um texto corresponde a uma determinada expressão regular;

·        Contar os itens em uma lista.

6.6.17.Deve possuir conectores nativos para ao menos os seguintes serviços, visando ampliar a capacidade de resposta automatizada:

·        AbuseIPDB;

·        AlienVault OTX;

·        AlienVault ThreatCrowd;

·        Amazon Alexa;

·        Amazon Athena;

·        Amazon CloudTrail;

·        Amazon EC2;

·        Amazon IAM;

·        Amazon S3;

·        Amazon SNS;

·        Amazon VPC;