"TERMO DE REFERÊNCIA" - PDF
Download ""TERMO DE REFERÊNCIA""
Ísis Aires Sabala
1 "TERMO DE REFERÊNCIA" 1. OBJETO: 1.1 Aquisição de Appliance (hardware dedicado) de Firewall de Aplicação WEB - WAF, bem como instalação, ativação, licenças, suporte, treinamento assistência técnica especializada e gestão de vulnerabilidades. 2. ESPECIFICAÇÃO TÉCNICAS MÍNIMAS: 2.1 Firewall appliance (hardware dedicado) de Aplicação WEB com software licenciado, do mesmo fabricante, com todas as funcionalidades listadas neste Termo de Referência; 2.2 A solução de hardware deve ser baseada em appliance com Sistema Operacional customizado para garantir segurança e melhor desempenho; 2.3 Deve vir acompanhado de todas as licenças de software ou hardware necessárias para atendimento às funcionalidades exigidas neste documento. 2.4 Possuir quantidade de memória e capacidade de processamento suficiente para atendimento de todas as funcionalidades e desempenho solicitados neste documento; 2.5 Gabinetes para instalação em rack padrão 19 polegadas, devendo cada equipamento possuir altura máxima de até 4U (unidade de rack); Deve ser acompanhado de todos os cabos e suportes (gavetas, bandejas e braços) necessários para a instalação do equipamento em conformidade com as normas ABNT, quando se aplicar; 2.6 Fontes de alimentação redundantes e internas, hot-swappable, do tipo auto-sense, para operar de 100 a 240 VAC. Implementar redundância de fontes do tipo N + N, operando em frequência de 50/60Hz; 2.7 Implementar redundância de alimentação elétrica através de balanceamento de carga, com capacidade de substituição sem interrupção do funcionamento do equipamento (hot-swappable); Possuir, pelo menos, 2 (duas) conexões independentes, permitindo a sua ligação a circuitos elétricos externos distintos; TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 1 de 23
2 2.7.2 Realizar a comutação entre as fontes de forma automática e sem qualquer interrupção no funcionamento do equipamento; 2.8 A solução oferecida deverá possuir no mínimo 6 (seis) portas Ethernet 1000 BaseT, específicas para as funções de balanceamento de carga; 2.9 A solução oferecida deverá possuir no mínimo 2 (duas) portas 10Gbps, em transceiver do tipo SR (Short Range), com conector SFP+/XFP; 2.10 Permitir a configuração da solução em alta disponibilidade; 2.11 Implementar solução de redundância de dispositivos em modo ativo-ativo, ou ativo-passivo de maneira que, em caso de falha de um dos equipamentos, o estado de todas as conexões seja remanejado para o equipamento redundante, preservando o estado original de todas as tabelas de conexões e de persistência; 2.12 Implementar a sincronização entre os equipamentos redundantes, assegurando que não haverá downtime e queda de sessões em caso de falha de um dos equipamentos; 2.13 A solução ofertada deverá suportar as seguintes opções de implementação: Monitoramento (Sniffing); Bridge (Inline); Proxy (Reverso e Transparente); 2.14 Deve ser possível implementação distribuída, com appliances geograficamente afastados, e gerenciamento de forma centralizado através de uma console única; 2.15 Agregação de portas baseado no protocolo LACP; 2.16 Transporte de múltiplas VLAN por uma única porta (ou por um conjunto agregado de portas) utilizando o protocolo 802.1q; 2.17 Suporte a otimização do protocolo TCP para ajustes a parâmetros das conexões clientes e servidor; TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 2 de 23
3 2.18 Permitir a aplicação de novas políticas em tempo real, sem interrupção do tráfego Deverá operar com os protocolos IPv4 e IPv6 simultaneamente. O desempenho deverá ser semelhante para ambos os protocolos em termos de entrada, saída e rendimento do fluxo de dados, transmissão e processamento de pacotes; O firewall deverá possuir paridade de funcionalidade de filtragem e tratamento de pacotes tanto no IPv4 e IPv6, exceto no caso de funcionalidades não definidas pela IETF para ambos os protocolos, e das funcionalidades de NAT e tunelamento; O suporte ao protocolo IPv6 deverá ser evidenciado e comprovado através da certificação IPv6 Ready Logo Os equipamentos que não foram submetidos aos procedimentos de teste do programa IPv6 Ready, deverão estar em conformidade com as RFCs listadas abaixo: RFC Internet Protocol, Version 6 (IPv6) Specification RFC IP Version 6 Addressing Architecture RFC Default Address Selection for Internet Protocol version 6 (IPv6) RFC Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC IPv6 Stateless Address Autoconfiguration RFC Path MTU Discovery for IP version 6 RFC Neighbor Discovery for IP version 6 (IPv6) 2.20 Possuir porta independente para gerência, padrão 1000Base-T Gigabit 2.21 Ethernet Implementar no mínimo 1 Gbps de tráfego de Camada 7 operando tanto em IPv4 como em IPv6; 2.23 A solução deve suportar throughput igual ou maior à capacidade de transmissão do ambiente e introduzir latência da ordem de grandeza de NO MÁXIMO sub-milissegundos a fim de não impactar o desempenho das aplicações WEB; 2.24 A solução não deve possuir backdoors de qualquer espécie, particularmente não deve possuir nenhum dispositivo de hardware ou software que permita acesso remoto não autorizado, que comprometa o TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 3 de 23
4 funcionamento do gerador de números aleatórios, que exponha material secreto (como chaves privadas), ou que de alguma forma reduza a segurança ou a privacidade de conexões cifradas; 2.25 A solução não deve, sob nenhuma hipótese, utilizar gerador de números aleatórios baseado apenas em funções matemáticas e processos determinísticos, sendo obrigatória a utilização de gerador de números aleatórios constantemente ou periodicamente realimentado por processos físicos inerentemente não determinísticos, devidamente submetidos a processo de debiasing e whitening; 2.26 Não deve, sob nenhuma hipótese, utilizar o gerador de números aleatórios Dual_EC_DRBG (NIST SP ) Todos os equipamentos devem estar em linha de produção e sem perspectiva de fim de produção na data de entrega dos equipamentos A Contratada deverá suportar toda manutenção necessária para o perfeito funcionamento da solução durante o período contratado, mesmos com o fim de produção dos equipamentos ofertados. 3 ESPECIFICAÇÕES MÍNIMAS DE SEGURANÇA E FUNCIONALIDADE 3.1 A solução deve ser capaz de armazenar para fins de rastreamento, informações de identificação dos usuários autenticados na aplicação; 3.2 Suportar análise de tráfego HTTP/0.9, HTTP/1.0 e HTTP/1.1; 3.3 A solução deve detectar ataques em diferentes camadas, incluindo rede, sistema operacional, servidor HTTP e camada de aplicação; 3.4 A solução deve ser capaz de proteger o ambiente de aplicações WEB dos seguintes tipos de ataques: Injection (no mínimo as seguintes opções): OS Command; SQL; LDAP; Xpath ou NoSQL; SMTP Header; XML Analysers; Quebra de Autenticação (no mínimo as seguintes falhas de sistema): Logout; Gestão de Senhas; Tempo de Expiração; TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 4 de 23
5 Pergunta Secreta; Lembrete de Senha; Atualização de Conta; Cross-Site Scripting (XSS) (no mínimo as seguintes falhas): Persistente; Refletido; Baseado em DOM; Referência Insegura e Direta a Objetos; Configuração Incorreta de Segurança (no mínimo as seguintes falhas): Falta de atualizações; Erros de configuração; Uso de contas padrão; Serviços desnecessários; Exposição de Dados Sensíveis (no mínimo as seguintes falhas): Dados sensíveis não criptografados; Vulnerabilidade na geração e gerenciamento de chaves de criptografia; Vulnerabilidade na utilização de algoritmos e técnicas de hashing; Falta de Função para Controle do Nível de Acesso; Cross Site Request Forgery (CSRF); Utilização de Componentes Vulneráveis Conhecidos; Redirecionamentos e Encaminhamentos Inválidos; Manipulação de Ambiente Restrito: Cookie Poisoning; Buffer Overflow; Data Destruction; Directory Traversal; Form Field Tampering; Forceful Browsing; Ataques HTTP: HTTP Denial of Service; HTTP Response Splitting; HTTP Verb Tampering; HTTP hidden field manipulation. HTTP parameter pollution. HTTP request smuggling. Códigos Maliciosos: Illegal Encoding; Malicious Encoding; Malicious Robots; Phishing Attacks; Zero Day Web Worms/Malwares; Ataques a Servidores WEB: Web Scraping; TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 5 de 23
6 Web server software and operating system attacks; Web Services (XML) attacks; Anonymous Proxy Vulnerabilities; Brute Force Login; Drive-by-Downloads; Google Hacking; Parameter Tampering; Remote File Inclusion Attacks; Session Hijacking; Site Reconnaissance; Directory Traversal. Sensitive Data Leakage (Social Security Numbers, Cardholder Data, PII, HPI). 3.5 Ao se detectar um ataque ou qualquer atividade não autorizada, o firewall de aplicação web deve ser capaz de tomar uma das ações apropriadas, sendo elas (e devendo suportar todas): derrubar (drop) requests e responses, bloquear uma sessão TCP, bloquear um determinado IP, ou ainda, bloquear um determinado IP durante um determinado intervalo de tempo, sem impactar nas aplicações. 3.6 Deve ser capaz de configurar granularmente para cada aplicação protegida, restrições de métodos HTTPS permitidos, tipos ou versões de protocolos, tipos de caracteres, versões utilizadas de cookies; 3.7 Assinar cookies digitalmente e edita endereços de URL ( URL Rewriting ). 3.8 A solução deve possuir mecanismo de aprendizado automatizado capaz de identificar todos os conteúdos das aplicações, incluindo URLs, parâmetros URLs, campos de formulários, o que se espera de cada campo (tipo de dado, tamanho de caracteres), cookies, arquivos XML e ações SOAP; O Firewall de Aplicação deve aprender a estrutura e os elementos das aplicações web automaticamente (campos, valores, cookies e URLs) Uma vez que as aplicações web mudam constantemente, o Firewall de Aplicação deve ser capaz de reconhecer tais alterações enquanto simultaneamente protege os aplicativos; TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 6 de 23
7 3.8.3 A solução deve ser capaz de identificar e criar um perfil de utilização dos aplicativos mesmo que as páginas e conteúdos sejam dinâmicos, como os desenvolvidos em Javascript, CGI, ASP ou PHP; O perfil aprendido de forma automatizada deve permitir que seja ajustado, editado ou bloqueado (para que não haja alterações) pelo administrador; 3.9 A solução deve possuir uma base de assinatura de ataques com mais de 1200 assinaturas inclusas, as quais deverão ser atualizadas periodicamente pelo próprio fabricante via Internet; 3.10 A solução deve oferecer um serviço baseado na reputação do IP de origem, protegendo as aplicações internas impedindo que estas sejam acessadas por usuários maliciosos que são frequentemente responsáveis por ataques automatizados ou através de botnets, ou ainda, acessos originados por endereços IP's de baixa reputação e endereços de proxys anônimos; Entende-se como usuários maliciosos aqueles que incluem endereços de IP s maliciosos ou endereços de proxys anônimos; 3.11 A solução deve possuir funcionalidade de proteção de cookies, contemplando: Assinatura dos mesmos, evitando que sejam modificados; Garantir a integridade do cookie sem alteração do mesmo; Proteger a criptografia de cookies; 3.12 A solução deverá ser capaz de compreender e proteger aplicações criptografadas com SSL (HTTPS); 3.13 O Firewall de Aplicação deve ser capaz de correlacionar múltiplos eventos de segurança em conjunto para que possa distinguir de forma precisa tráfego permitido de tráfego malicioso; 3.14 O Firewall de Aplicação deve permitir a customização de regras da segurança; 3.15 A solução deve suportar os seguintes critérios de decisão para realizar um bloqueio ou gerar um alerta, sendo que uma política pode conter um ou mais critérios simultaneamente: TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 7 de 23
8 Tamanho da resposta de uma página web; User-agent (navegador); Horário; IP de origem; Assinatura de ataque; Conteúdo do payload; Conteúdo do cabeçalho; Conteúdo do cookie; Código de response; Hostname; Tipo de protocolo (HTTP ou HTTPS); Parâmetro; Número de ocorrências num intervalo de tempo; Método HTTP/HTTPS; Tipos e versões de protocolos Quantidade de transações por segundo (TPS) O Firewall de Aplicações deve ser capaz de diferenciar entre bots e usuários humanos para parar os ataques automatizados; 3.17 O WAF deve ser capaz de identificar atividade suspeita, como as fontes de ataques na Web e redes de ataques e compartilhar esses dados com outros Web Application Firewalls para validar e bloquear ameaças emergentes; 3.18 O Firewall de aplicações deve ser capaz de identificar malwares fraudulentos usados para realizar ataques man-in-the-middle; 3.19 Suportar aplicações que utilizam autenticação com estes métodos: Autenticação básica. NTLM. Certificados SSL Para implementações de grande porte e distribuídas, o WAF deve suportar gerenciamento de cluster centralizado e relatórios de múltiplos equipamentos na mesma gerência centralizada; 3.21 Permitir a criação de políticas diferenciadas por aplicação e por URL, onde cada aplicação e URL poderão ter políticas totalmente diferentes Permitir a criação de assinaturas de ataques. TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 8 de 23
9 3.23 Proteger contra as 10 maiores vulnerabilidades da lista OWASP Exportar requisições que contém os ataques, nos formatos PDF ou CSV Realizar localização geográfica do IP, identificando pais de origem da requisição Utilizar o campo HTTP X-Forwarded-For sem modificar seu conteúdo de origem, permitindo a diferenciação em ambientes com NAT Suportar SSL offload Remove as mensagens de eventos do conteúdo que será enviado aos usuários A criação das políticas deve possuir as formas: Automático por meio da observação do tráfego para a aplicação. Automático por meio da observação do tráfego em ambiente controlado. 4 BLOQUEIO DE TRÁFEGO 4.1 Realizar bloqueio através da intermediação e interrupção da conexão, ou seja, o tráfego é interceptado e a comunicação é finalizada no firewall de aplicação, não alcançando assim os aplicativos web; 4.2 Deve ser possível configurar uma política de bloqueio baseada no mínimo (mas não se limitando a essas) nas seguintes variáveis: Requisição HTTP; Endereço IP; 4.3 Quando realizado um bloqueio, deve ser possível comunicar o usuário sobre o fato através de uma página HTML informativa e customizável; 4.4 A solução deve ser capaz de analisar o tráfego de saída (outgoing) a fim de evitar o vazamento ou roubo de informações confidenciais; 4.5 Prevenir contra vazamentos dos códigos dos servidores. 4.6 A solução deve ser capaz de identificar e bloquear ataques baseados em: TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 9 de 23
10 4.6.1 Assinaturas: funcionamento semelhante à de um IPS, onde uma combinação de caracteres ou a presença de uma característica no tráfego através de uma expressão regular identifica o tráfego como um ataque; Regras: similar à base de assinaturas, porém realizando uma análise mais complexa e detalhada, uma regra pode identificar um ataque analisando partes específicas da transação (como pequenos trechos de cabeçalho) e ainda ser configurada de forma composta onde mais de uma regra é analisada logicamente (OR ou AND) para caracterizar ou não um determinado tráfego como ataque; Perfil de utilização; 4.7 A solução deve ser capaz de identificar ataques do tipo força bruta (brute force) onde: O atacante solicita repetidamente o mesmo recurso; O atacante realiza repetidas tentativas não autorizadas de acesso; São utilizados ataques automatizados de login, ou seja, as tentativas de login têm um intervalo de tempo muito pequeno entre elas; Controles de acesso da aplicação (Erro 401 unauthorized) Solicitações repetidas ao mesmo recurso, em qualquer parte/url da aplicação Aplicações WEB que não retornam o erro 401 por meio da identificação de expressão regular no retorno/página de erro da aplicação); Gerenciamento de sessão (muitas sessões de um único endereço IP ou a um range de IP's) Clientes automatizados (robôs, requisições muito rápidas). 4.8 Quando detectado uma tentativa de ataque, deve ser possível realizar um atraso (delay) ao atacante, ou o bloqueio imediato do tráfego ou da sessão; TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 10 de 23
11 4.9 Permitir o bloqueio de tentativas de ataque do tipo Cookie Poisoning e Cookie Injection; 5 TRATAMENTO DE TRÁFEGO CRIPTOGRAFADO 5.1 A solução deve suportar aplicações web que utilizam autenticação do cliente por via de certificados; 5.2 Suportar SSL v3 e TLS v1; 5.3 Para as soluções que utilizam SSL para transferência de dados, os certificados e pares de chaves público-privada devem ser importadas ao appliance, atuando como man-in-the-middle para tráfego SSL. 5.4 Quando houver a necessidade de proteção de aplicativos criptografados (HTTPS), a solução deverá ser capaz de decriptografar o tráfego entre o cliente e o servidor para análise do mesmo e opcionalmente ser capaz reencriptando-o antes de encaminhá-lo ao seu destino final; 6 MODOS DE IMPLEMENTAÇÃO 6.1 A solução de ofertada deverá suportar as seguintes opções de implementação: Monitoramento (sniffing); Bridge (inline); Proxy (Reverso e Transparente); 6.2 Quando em modo monitoramento (sniffing) o Firewall de Aplicação deve suportar implementação não-inline para finalidade de monitoramento bem como implementação em linha com a finalidade de atuação no tráfego e bloqueio do mesmo quando necessário; 6.3 Quando em modo de monitoramento (sniffing): A solução deve realizar análise e avaliação do tráfego, gerar relatórios e informar necessidade de bloqueios para efeito de avaliação, oferecendo nenhum risco, latência ou qualquer tipo de impacto ao ambiente de produção; O administrador deve ser capaz de visualizar os alertas, as tentativas de ataques, erros retornados pelos servidores de aplicações e demais TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 11 de 23
12 atividades suspeitas e não autorizadas; 6.4 Quando implementado como um Proxy (transparente ou reverso), o Firewall de aplicação deve ser capaz de assinar cookies digitalmente, encriptá-las e editar endereços de URL ( URL Rewriting ); 6.5 A licitante deverá fornecer os equipamentos e softwares da solução com todos os itens acessórios necessários à sua perfeita instalação e funcionamento da solução 6.6 O profissional que atuará do início da execução do Contrato até a conclusão da implantação como Gerente de Projeto, deverá possuir certificação PMP (Project Management Professional). 7 ADMINISTRAÇÃO 7.1 Possuir interface de gerenciamento gráfica acessível via browser; 7.2 Possuir interface de gerenciamento; 7.3 Permitir a definição de diferentes níveis de administração, no mínimo, um nível completo e outro somente de visualização de configurações e logs. 7.4 Permitir a replicação de configurações e a aplicação de atualização de softwares para os elementos dos nós do cluster. 7.5 Suportar implementação distribuída (cluster) com gerenciamento e emissão de relatórios centralizada; 7.6 A solução deve possuir opção de instalação transparente, para que possa ser implementado ou retirado da rede sem que haja qualquer alteração de topologia e configuração dos dispositivos que compões o ambiente; 7.7 O Firewall de aplicação deve permitir que assinaturas de ataque sejam modificadas e/ou acrescentadas à lista existente pelo Administrador; 7.8 O Firewall de Aplicação deve suportar updates automáticos da base de assinaturas de ataques, garantindo completa proteção contra as mais recentes ameaças; 7.9 Permitir auditoria detalhada das alterações de configuração efetuadas, indicando usuário, ação e horário. TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 12 de 23
13 7.10 Prover informações estatísticas de quantidade de conexões completadas, bloqueadas, fluxo de tráfego, quantidade de sessões ou conexões. 8 ALTA-DISPONIBILIDADE 8.1 Para implementação inline, a solução deve suportar failover nativamente além de opções de fail-open (bypass); 8.2 Deve suportar modo ativo-ativo ou ativo-passivo de funcionamento; 8.3 Deve ser possível implementar alta-disponibilidade stateful, ou seja, sem perda de conexão quando ocorrer o failover uma sessão passar de um appliance para o outro; 9 LOGS E RELATÓRIOS 9.1 O Firewall de Aplicação deve inspecionar e monitorar, até a camada de aplicação, todo tráfego de dados HTTP, incluindo cabeçalhos, campos de formulários e conteúdo, além de inspecionar os requests e responses HTTP; 9.2 As checagens devem ser realizadas em todos os tipos de entrada de dados, como URLs, formulários, cookies, campos ocultos e parâmetros, consultas (query), métodos HTTP e elementos XML; 9.3 Devem ser oferecidas integradas à solução de Firewall de Aplicação, ferramenta própria de gerenciamento e emissão de relatórios e armazenamento de logs; 9.4 Deve ser possível exportar eventos a servidores Syslog ou SNMP; 9.5 Nível de log e filtros devem ser configuráveis; 9.6 A solução deve gerar, no módulo integrado, relatórios pré-definidos e relatórios customizados; 9.7 Os relatórios devem ser disponibilizados sob demanda ou programados via agendamento e enviados por ; 9.8 Permitir a seleção de período para emissão dos relatórios, 9.9 Os relatórios devem no mínimo Identificar o ataque acontecido com detalhes, com as seguintes informações: Tentativa do ataque. TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 13 de 23
14 Endereços IP que originaram os ataques. Localidade geográfica do IP atacante URL atacada Horário do ataque. Nome do ataque. Qual campo foi atacado. Quantas vezes esse ataque foi realizado. Tipo de violação/ataque Severidade 9.10 A interface gráfica de gerenciamento deve prover painel de visualização em alto nível, com informações em tempo real sobre o status do sistema e da atividade do tráfego web monitorado; 9.11 A solução deve integrar-se nativamente com ferramentas de gerenciamento e correlação de eventos do tipo SEM (Security Event Management); 10 GESTÃO DE VULNERABILIDADES As funcionalidades de gestão de vulnerabilidades poderão ser fornecidas independentes do appliance do Firewall de Aplicações Web (WAF), em equipamentos independentes e redundantes, porém alinhados com as especificações já descritas anteriormente, atendendo os seguintes requisitos mínimos: Todos os equipamentos necessários deverão ser dimensionados e fabricados para fixação em rack padrão Serão aceitas soluções em forma de appliance, porém caso a solução de gestão de vulnerabilidades exija servidor físico de uso genérico para sua instalação, o equipamento ofertado deverá atender aos seguintes requisitos: i. Servidor tipo rack, para instalação em rack padrão de 19, limitado a 2U de altura. ii. Possuir pelo menos 1 (um) processador de 8 (oito) núcleos, arquitetura de 64 bits. iii. Possuir pelo menos 32GB de memória RAM DDR3. iv. Possuir pelo menos 2 (dois) discos internos com configuração mínima de 300 GB, tecnologia SAS, velocidade de RPM. TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 14 de 23
15 v. Possuir pelo menos 2 (duas) portas GbE 1000Base-T. vi. Possui fonte de alimentação 110/220V, redundantes N Os componentes da solução deverão ocupar no máximo 20U (Vinte Rack Units) de espaço no rack, considerando o somatório dos espaços utilizados por todos os componentes da solução Permitir efetuar descoberta de topologia dos ativos da rede (qualquer servidor ou ativo de rede que possua endereço IP ou que seja alocado no escopo desta contratação) Permitir correlacionar eventos baseados nos sistema operacional, Porta/Protocolo, Banners e vulnerabilidades Permitir detectar vulnerabilidades em aplicações baseadas em WEB, bases de dados, aplicações comerciais, sistemas operacionais e dispositivos de rede Suportar efetuar varredura à procura de vulnerabilidades e exploits Não haverá limites de varreduras por ação ou endereçamento IP Possuir módulos de varredura diferenciados para análise intrusiva e não intrusiva Analisar aplicações web para detecção de vulnerabilidades, tais como Cross-Site-Scripting Efetuar varredura por endereço IP e nome DNS; Deve permitir a filtrar a varredura por: i. Destino. ii. Serviço. iii. Vulnerabilidade Suportar mecanismos para varredura de vulnerabilidades de hosts, bancos de dados e aplicações web, incluindo a detecção de vulnerabilidades em AJAX e WEB Suportar a verificação de vulnerabilidades: i. De forma não invasiva. ii. Por tipo de risco. iii. Categoria. iv. Por correlação de bases CVE. TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 15 de 23
16 Suportar análise de aplicação WEB a procura de informações em comentários HTML, hyperlinks, endereços de correio, keywords, campos escondidos e scripts Suportar pontuação que permite medir o nível de risco dos sistemas e dos recursos de rede Permitir levantamento e classificação quanto à criticidade de todos os ativos protegidos Permitir a apresentação do nível de criticidade de cada ativo, indicando seu grau de exposição à worms, exploits e malwares em geral Permitir a geração de alertas com informações detalhadas sobre o nome da vulnerabilidade, descrição detalhada, hosts afetados incluindo endereço IP e nome comum, os serviços abertos no host e as vulnerabilidades afetadas Realizar periodicamente procedimentos ou atualizações de ferramentas necessárias para mitigar vulnerabilidades dos componentes da solução de segurança Disponibilizar relatórios analíticos contendo dados, informações, indicadores e métricas que permitam avaliar a exposição dos ativos aos riscos identificados com, pelo menos, as seguintes informações: i. Hosts descobertos. ii. Nível de risco por plataforma e por vulnerabilidade. iii. Score com o nível de risco. iv. Serviços descobertos. v. Sumário. vi. Vulnerabilidades em aplicações WEB. vii. Vulnerabilidades em Windows. viii. Vulnerabilidades encontradas Permitir o gerenciamento de baselines de configuração dos ativos, que podem ser comparados com as novas avaliações para a determinação de desvios e envio de alertas por Possuir ferramenta de administração com interface gráfica remota segura, a partir de plataforma Windows 7 ou interface WEB, e permitir a definição de diferentes níveis de administração, no mínimo, um nível completo e outro somente de visualização de configurações e logs. TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 16 de 23
17 11 QUANTIDADE: 02 (dois) equipamentos Firewall de Aplicação WEB, novos, licenças de software ou hardware necessárias para atendimento às funcionalidades descritas, suporte, instalação, assistência técnica e treinamento; 12 PROVA DE CONCEITO A CONTRATADA poderá ser solicitada, a critério exclusivo da CONTRATANTE, prova de conceito da solução ofertada à empresa classificada em primeiro lugar após a fase de lances, com o objetivo de realizar testes de comprovação de atendimento às especificações e requisitos exigidos nesse Edital, caso a documentação entregue pela LICITANTE seja considerada insuficiente para comprovar o atendimento a todos os itens exigidos Para a realização da prova de conceito da solução integrada de segurança, a LICITANTE deverá disponibilizar conjunto de elementos que atendas as funcionalidades de gerenciamento/controle/bloqueio de ameaças e gestão de vulnerabilidades, devendo ser da mesma marca, modelo e especificações detalhadas na proposta A realização da prova de conceito deverá ser presencial e realizada, preferencialmente em uma das unidades da PRODAM-SP, devendo iniciar no prazo de até 10 (dez) dias úteis, contados a partir da data de convocação da CONTRATANTE para a realização da prova de conceito A CONTRATADA deverá comprovar todas as funcionalidades descrita no Termo de Referência em até 5 (cinco) dias úteis contados do início da prova de conceito A CONTRATANTE, a seu critério, poderá prorrogar a duração da prova de conceito por mais 05 (cinco) dias úteis A prova de conceito utilizará como base as especificações técnicas constantes do Termo de Referência do Edital Será rejeitada a prova de conceito que: a) Não comprovar o atendimento de, pelo menos, 01 (um) TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 17 de 23
18 requisito técnico descrito no Termo de Referência, executada nos equipamentos e softwares entregues para a prova de conceito. b) Apresentar divergências entre as especificações dos equipamentos e softwares entregues para a prova de conceito em relação às especificações técnicas da proposta entregue pela LICITANTE Não será aceita a proposta da LICITANTE que tiver a prova de conceito rejeitada ou não entregue no prazo estabelecido Nesse caso, a proposta subsequente será examinada e, assim, sucessivamente, na ordem de classificação. 13 ATESTADO DE CAPACIDADE TÉCNICA: A CONTRATADA deverá apresentar ATESTADO DE CAPACIDADE TÉCNICA, emitido por entidade da Administração Federal, Estadual ou Municipal, direta ou indireta e/ou empresa privada que comprove ter a LICITANTE fornecido e implementado a contento, para órgão ou entidades públicas ou privadas, solução de firewall de aplicação WEB (WAF), composta por equipamentos que atenda a essas funcionalidades descritas nesse processo, nos termos da Lei Deverá constar, no atestado, a identificação do emitente, especificação completa do fornecimento/serviço executado, prazo de vigência do contrato, local e data de expedição, data de início e término do contrato. 14 VISTORIA TÉCNICA: A Licitante caso julgue conveniente para o correto dimensionamento e cumprimento das obrigações, poderá realizar vistoria nas instalações da PRODAM para tomar conhecimento dos serviços a serem realizados, conforme - Termo de Referência As vistorias deverão ser realizadas em dias úteis, no horário de 9:00 às 11:00 e das 14:00 às 16:00, até 3 (três) dia antes da abertura da licitação, no endereço Av. Francisco Matarazzo, 1500, edifício Los Angeles. O agendamento das vistorias deverá ser feito pelo telefone (11) ou (11) TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 18 de 23
19 14.3. A visita técnica deverá ocorrer por horário marcado, e será agendada pela área de Segurança da Informação através dos telefones acima, em até 4 dias da data e horário de abertura do processo licitatório Detalhes da topologia lógica da rede de dados da PRODAM serão apresentados durante a vistoria somente mediante assinatura de Termo de Confidencialidade e Sigilo da Licitante a ser preenchido e assinado pelo representante legal da empresa A Vistoria não é obrigatória, porém não se admitirá em hipótese alguma, alegações posteriores de desconhecimento dos serviços e de dificuldades técnicas não previstas, em razão da falta de sua realização. 15 DO PRAZO DE ENTREGA E INSTALAÇÃO: 15.1 O prazo máximo de entrega dos equipamentos será de 60 (Sessenta) dias corridos, contados a partir da data de assinatura do contrato; 15.2 A contratada deverá entregar o plano de trabalho em até 30 dias contados a partir da assinatura do contrato, contendo detalhes da instalação, configuração, cronograma, recursos humanos, topologia físico/lógico e testes da solução ofertada O prazo máximo de instalação e ativação da solução será de 60 (sessenta) dias após a entrega dos equipamentos. 16 ACEITE: A equipe técnica da Prodam emitirá o Termo de Aceite da solução WAF em até 5 dias úteis após a formalização pela Contratada da finalização do processo de instalação/operação da solução e confirmação que todos os quesitos do Edital foram cumpridos. 17 CONDIÇÕES DE PAGAMENTO: O pagamento será realizado em até 30 dias após recebimento da fatura e aprovado mediante Termo de Aceite emitido pela equipe técnica da Prodam responsável pelo projeto. 18 LOCAL DE ENTREGA TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 19 de 23
20 Cada equipamento será entregue em uma das unidades da PRODAM- SP, abaixo relacionados, ou a critério da Contratante (dentro do município de São Paulo): - Av. Francisco Matarazzo, º - Ed. Los Angeles - Rua Pedro de Toledo, Obrigações mínimas da CONTRATADA: 19.1 A Contratada deverá oferecer garantia, suporte e licenças dos equipamentos e suas funcionalidades contratadas por um prazo mínimo de 36 (trinta e seis) meses, a contar da data de sua efetiva instalação; durante o período de cobertura, a CONTRATADA devera prestar Serviços de Manutenção On Site, para os componentes do objeto deste edital, incluindo configuração técnica do produto; 19.2 Durante período de garantia a CONTRATADA obriga-se a fornecer todas as atualizações necessárias, incluindo as de versões de firmware e atualizações de assinaturas necessárias; 19.3 Disponibilizar profissional certificado pelo fabricante para implantação e ativação dos produtos contratados; 19.4 Instalar, configurar e acompanhar os testes de funcionamento antes da entrada de produção dos equipamentos; 19.5 Orientar tecnicamente os responsáveis pela operação dos equipamentos, fornecendo os esclarecimentos necessários ao seu perfeito funcionamento; 19.6 Disponibilizar número de telefone (local ou DDG) para suporte telefônico (24x7x365) e abertura de chamados técnicos; 19.7 Proceder à entrega dos equipamentos, devidamente embalados, de forma a não serem danificados durante a operação de transporte e de carga e descarga, com as especificações detalhadas para conferência; 19.8 Fornecer equipamentos ofertados em linha normal de produção; 19.9 O tempo máximo para retorno sobre a abertura de um chamados para manutenção por defeitos deverá ser de 1 (uma) hora e de solução em até 6 h (seis horas) a contar do registro de abertura do chamado no Centro de Atendimento Técnico da Contratada, realizando testes e corrigir TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 20 de 23