termo de referÊncia 1. objeto: 2. especificaÇÃo … · 2014-09-26 · campo (tipo de dado,...

TR_Web_Aplication_Firewall ver. 9 29/08/2014 Página 1 de 23

"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); 2.5.1 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);

2.7.1 Possuir, pelo menos, 2 (duas) conexões independentes, permitindo a

sua ligação a circuitos elétricos externos distintos;


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: 2.13.1 Monitoramento (Sniffing);

2.13.2 Bridge (Inline);

2.13.3 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;


2.18 Permitir a aplicação de novas políticas em tempo real, sem interrupção do tráfego.

2.19 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;

2.19.1 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;

2.19.2 O suporte ao protocolo IPv6 deverá ser evidenciado e comprovado através da certificação IPv6 Ready Logo.

2.19.3 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:

• RFC2460 - Internet Protocol, Version 6 (IPv6) Specification • RFC4291 - IP Version 6 Addressing Architecture • RFC3484 - Default Address Selection for Internet Protocol version

6 (IPv6) • RFC4443 - Internet Control Message Protocol (ICMPv6) for the

Internet Protocol Version 6 (IPv6) Specification • RFC4862 - IPv6 Stateless Address Autoconfiguration • RFC1981 - Path MTU Discovery for IP version 6 • RFC4861 - Neighbor Discovery for IP version 6 (IPv6)

2.20 Possuir porta independente para gerência, padrão 1000Base-T Gigabit 2.21 Ethernet.

2.22 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


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 800-90).

2.27 Todos os equipamentos devem estar em linha de produção e sem perspectiva de fim de produção na data de entrega dos equipamentos.

2.28 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;


� 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;


� 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;

3.8.1 O Firewall de Aplicação deve aprender a estrutura e os elementos das aplicações web automaticamente (campos, valores, cookies e URLs)

3.8.2 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;


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;

3.8.4 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;

3.10.1 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:

3.11.1 Assinatura dos mesmos, evitando que sejam modificados;

3.11.2 Garantir a integridade do cookie sem alteração do mesmo;

3.11.3 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:


• 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).

3.16 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.

3.20 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.

3.22 Permitir a criação de assinaturas de ataques.


3.23 Proteger contra as 10 maiores vulnerabilidades da lista OWASP.

3.24 Exportar requisições que contém os ataques, nos formatos PDF ou CSV.

3.25 Realizar localização geográfica do IP, identificando pais de origem da requisição.

3.26 Utilizar o campo HTTP X-Forwarded-For sem modificar seu conteúdo de

origem, permitindo a diferenciação em ambientes com NAT.

3.27 Suportar SSL offload.

3.28 Remove as mensagens de eventos do conteúdo que será enviado aos usuários.

3.29 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:

4.2.1 Requisição HTTP; 4.2.2 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:


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;

4.6.2 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;

4.6.3 Perfil de utilização;

4.7 A solução deve ser capaz de identificar ataques do tipo força bruta (brute force) onde:

4.7.1 O atacante solicita repetidamente o mesmo recurso;

4.7.2 O atacante realiza repetidas tentativas não autorizadas de acesso;

4.7.3 São utilizados ataques automatizados de login, ou seja, as tentativas de login têm um intervalo de tempo muito pequeno entre elas;

4.7.4 Controles de acesso da aplicação (Erro 401 – unauthorized).

4.7.5 Solicitações repetidas ao mesmo recurso, em qualquer parte/URL da aplicação.

4.7.6 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);

4.7.7 Gerenciamento de sessão (muitas sessões de um único endereço IP ou a um range de IP's).

4.7.8 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;


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:

6.1.1 Monitoramento (sniffing);

6.1.2 Bridge (inline);

6.1.3 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):

6.3.1 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;

6.3.2 O administrador deve ser capaz de visualizar os alertas, as tentativas de ataques, erros retornados pelos servidores de aplicações e demais


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.


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 e-mail;

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.


• 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:

10.1. Todos os equipamentos necessários deverão ser dimensionados e

fabricados para fixação em rack padrão 19”.

10.2. 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 10.000 RPM.


v. Possuir pelo menos 2 (duas) portas GbE 1000Base-T. vi. Possui fonte de alimentação 110/220V, redundantes N+1.

10.3. 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.

10.4. 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).

10.5. Permitir correlacionar eventos baseados nos sistema operacional, Porta/Protocolo, Banners e vulnerabilidades.

10.6. Permitir detectar vulnerabilidades em aplicações baseadas em WEB, bases de dados, aplicações comerciais, sistemas operacionais e dispositivos de rede.

10.7. Suportar efetuar varredura à procura de vulnerabilidades e exploits.

10.8. Não haverá limites de varreduras por ação ou endereçamento IP.

10.9. Possuir módulos de varredura diferenciados para análise intrusiva e não intrusiva.

10.10. Analisar aplicações web para detecção de vulnerabilidades, tais como

Cross-Site-Scripting.

10.11. Efetuar varredura por endereço IP e nome DNS;

10.12. Deve permitir a filtrar a varredura por: i. Destino. ii. Serviço. iii. Vulnerabilidade.

10.13. 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 2.0.

10.14. 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.


10.15. 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.

10.16. Suportar pontuação que permite medir o nível de risco dos sistemas e

dos recursos de rede.

10.17. Permitir levantamento e classificação quanto à criticidade de todos os ativos protegidos.

10.18. Permitir a apresentação do nível de criticidade de cada ativo, indicando

seu grau de exposição à worms, exploits e malwares em geral.

10.19. 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.

10.20. Realizar periodicamente procedimentos ou atualizações de ferramentas

necessárias para mitigar vulnerabilidades dos componentes da solução de segurança.

10.21. 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.

10.22. 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 e-mail.

10.23. 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.


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 12.1. 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.

12.2. 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.

12.3. 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.

12.4. 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.

12.5. A CONTRATANTE, a seu critério, poderá prorrogar a duração da prova de conceito por mais 05 (cinco) dias úteis.

12.6. A prova de conceito utilizará como base as especificações técnicas

constantes do Termo de Referência do Edital. 12.7. Será rejeitada a prova de conceito que:

a) Não comprovar o atendimento de, pelo menos, 01 (um)


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.

12.8. Não será aceita a proposta da LICITANTE que tiver a prova de conceito rejeitada ou não entregue no prazo estabelecido.

12.9. Nesse caso, a proposta subsequente será examinada e, assim,

sucessivamente, na ordem de classificação.

13 ATESTADO DE CAPACIDADE TÉCNICA: 13.1. 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.

13.2. 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:

14.1. 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.

14.2. 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) 3396-9119 ou (11) 3396-9144.


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.

14.4. 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.

14.5. 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.

15.3 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


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, 1500 – 14º - Ed. Los Angeles - Rua Pedro de Toledo, 983

19 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


defeitos, inclusive com a sua substituição quando necessário, sem ônus para a CONTRATANTE, durante o período de garantia;

19.10 A cada visita técnica realizada nas dependências da CONTRATANTE a

CONTRATADA deverá emitir um relatório de execução das atividades, relacionando os serviços executados e lista de equipamentos que eventualmente sejam deixados ou retirados das dependências da CONTRATANTE;

19.11 Caso a Contratada não consiga recuperar o equipamento em até 72

horas após a abertura do chamado, o appliance com problema deverá ser substituído por outro novo;

19.12 Toda a documentação técnica (configurações/topologias/padrões de

testes/manuais/procedimentos, etc.) sobre o projeto deverá ser entregue em até a data do aceite. A não entrega será considerada como não conformidade.

19.13 O processo de ativação/ativação e testes poderá ser realizado em

horários estabelecidos pela contratada, incluindo fim de semanas e feriados.

19.14 A Contratada deverá iniciar a operação assistida, onde um técnico

capacitado em toda a solução estará presente na PRODAM-SP durante 30 dias (úteis) provendo suporte, acompanhamento e ajustes na solução em produção. Os dias da operação assistida serão definidos pela Contratada, podendo ser estabelecida inúmeras visitas em dias não consecutivos.

19.15 Cessões de direito de uso perpétuo dos softwares fornecidos. Os termos

de licenciamento de todos os softwares fornecidos, emitidos pelo fabricante, deverão ser entregues pela CONTRATADA e os mesmos serão direito pertencentes ao CONTRATANTE.

20 DOCUMENTAÇÃO TÉCNICA

20.1 Deverão ser fornecidos juntamente com os produtos e licenças os manuais técnicos de referência, contendo todas as informações sobre os produtos com as instruções para instalação, configuração e operação, preferencialmente em Português (Brasil), ou, na inexistência de tradução em Português, podem ser escritos em Língua Inglesa;

21 ITENS GERAIS


• Kit para montagem em RACK de 19” (caso necessário); • Deverão ser fornecidos cabos de interconexão elétrica e rede;

22 TREINAMENTO

22.1 Deverá ser fornecido treinamento, ministrado por empresa certificada e

autorizada pelo fabricante, para até 6 (seis) funcionários da PRODAM-SP, divididos no mínimo em 2 turmas de 3 funcionários, agendadas em datas distintas a critério da CONTRATANTE e em acordo com a CONTRATADA;

22.2 O treinamento poderá ser ministrado dentro do município de São Paulo

em ambiente próprio e dedicado para este fim. Caso o treinamento seja realizado fora do município, a CONTRATADA será responsável pelas despesas de transporte, hospedagem e alimentação;

22.3 A carga horária mínima deverá ser de 24 horas (ou período estipulado

como treinamento oficial do fabricante constante em lista de venda para os itens adquiridos) e o treinamento deverá abranger todas as facilidades do equipamento adquirido;

23 PENALIDADES PARA NÃO ATENDIMENTO

23.1 Caso haja atraso na entrega, haverá multa de 3% por dia de atraso, calculado sobre o valor do contrato;

23.2 Caso haja atraso na instalação, haverá multa de 2% por dia de atraso, calculado sobre o valor do contrato;

23.3 Caso haja atraso no período de resposta para abertura de um chamado, haverá multa de 0,1% por hora de atraso, calculado sobre o contrato;

23.4 Caso haja atraso no período de solução para um chamado de manutenção, haverá multa de 0,5% por hora de atraso, calculado sobre o valor do contrato;

23.5 Caso haja atraso na substituição do equipamento avariado por um novo após 72horas da abertura do chamado sem solução, será cobrado multa de 5% por dia de atraso, cobrado sobre o valor do contrato.

24 CONFIDENCIALIDADE

24.1 A CONTRATADA deverá zelar pelo sigilo de quaisquer informações referentes à estrutura, sistemas, usuários, contribuintes, topologia, e ao modo de funcionamento e tratamento das informações da CONTRATANTE, durante e após fim do contrato, salvo se houver autorização expressa da Contratante para divulgação;


24.2 Não haverá nenhum tipo de facilidade de acesso remoto, tão menos

envio de forma automática ou controlada de informações (backdoor) originadas de software/hardware contratado ou adquirido sem o conhecimento e formal autorização da Contratante. A não observância desse fato poderá ser considerada espionagem e será motivo de processo civil e criminal conforme legislação vigente.

termo de referÊncia 1. objeto: 2. especificaÇÃo … · 2014-09-26 · campo (tipo de dado,...

Documents