DAS QUANTIDADES, ESPECIFICAÇÕES E GARANTIAS DOS EQUIPAMENTOS

DAS QUANTIDADES, ESPECIFICAÇÕES E GARANTIAS DOS EQUIPAMENTOS 1. QUANTIDADES ITEM QTD GARANTIA DESTINAÇÃO EQUIPAMENTO DE SEGURANÇA MULTIFUNÇÃO TIPO 1 EQUIPAMENTO DE SEGURANÇA MULTIFUNÇÃO TIPO 2 EQUIPAMENTO DE GERÊNCIA CENTRALIZADA 4 48 meses 16 48 meses 2 para firewall externo para o MJ em Brasília-DF; 2 para firewall interno para o MJ em Brasília-DF;. 2 para o DRCI em Brasília-DF; 2 para o CCBB em Brasília-DF; 2 para o Arquivo Central em Brasília-DF; 2 para a Força Nacional em Brasília-DF; 2 para a Penitenciaria Federal de Catanduvas-PR; 2 para a Penitenciaria Federal de Campo Grande-MS; 2 para a Penitenciaria Federal de Porto Velho-RO; 2 para a Penitenciaria Federal de Mossoró-RN. 2 48 meses 2 Gerências Centralizadas em Brasília-DF; 2. ESPECIFICAÇÕES 2.1. CARACTERÍSTICAS COMUNS AOS EQUIPAMENTOS DE SEGURANÇA MULTIFUNÇÃO: 2.1.1. Características gerais

2.1.1.1. Equipamento do tipo appliance, dedicado a firewall, terminação de túneis IPSEC e com suporte à terminação de conexões SSL-VPN (modelos clientless e client-based ); 2.1.1.2. Deve ser montável em rack de 19 polegadas (devem ser fornecidos os kits de fixação necessários). A altura máxima dos equipamentos fornecidos deve ser de duas unidades de rack (2 RUs). 2.1.1.3. Deve ser fornecido com fontes redundantes internas ao equipamento. 2.1.1.4. Deve possuir porta serial para acesso console ao equipamento. 2.1.1.5. Deverá permitir integração com solução de gerência centralizada de forma a permitir a visualização de eventos. 2.1.1.6. A solução deve permitir exportar os relatórios para pelo menos dois dos seguintes formatos HTML, MHTML, DOC, XLS, PDF e TXT. 2.1.1.7. Deve ser gerenciável por meio dos protocolos HTTPS e SSH. 2.1.1.8. Deve suportar protocolo AAA para controle de acesso administrativo aos equipamentos. Deve ser possível especificar conjuntos de comandos acessíveis a cada grupo de usuários administrativos e cada comando deve ser autorizado individualmente no servidor AAA. Todos os comandos executados bem como todas as tentativas não autorizadas de execução de comandos devem ser enviados ao servidor AAA. 2.1.2. Características de Firewall 2.1.2.1. Deve suportar funcionalidade de Stateful Firewall. Não deve haver restrição de número de usuários simultâneos através do equipamento para a licença de software fornecida para a funcionalidade de Stateful Firewall; 2.1.2.2. Deve suportar a definição de VLAN trunking conforme padrão IEEE 802.1q. Deve ser possível criar as interfaces lógicas (L3) associadas às VLANs e estabelecer regras de filtragem (Stateful Firewall) entre estas; 2.1.2.3. Deve construir registro de fluxos de dados relativos a cada sessão iniciada, armazenando para cada uma destas sessões informações tais como endereços de origem e destino dos pacotes, portas TCP (e UDP) de origem e destino, bem como números de sequência dos pacotes TCP, status dos flags ACK, SYN e FIN ; 2.1.2.4. O equipamento deve permitir a randomização do número de sequência TCP, ou seja, funcionar como um proxy de número de sequência TCP de modo a garantir que um host situado em uma interface considerada externa (insegura), sob o ponto de vista de política de segurança do firewall, nunca tenha acesso ao

número de sequência TCP real do host seguro (interno ao firewall) em uma sessão estabelecida entre os referidos hosts; 2.1.2.5. Deve ser fornecido com todos os acessórios e licenças para funcionamento em cluster; 2.1.2.6. Possuir suporte a filtragem stateful para pelo menos os seguintes protocolos de aplicação: Oracle SQL*Net Access, Remote Shell, FTP, HTTP, SMTP, H.323, H.323 v2, ILS (Internet Locator Service), LDAP e ESMTP. 2.1.2.7. Deve implementar remontagem virtual de fragmentos ( Virtual Fragment Reassembly ) em conjunto com o processo de inspeção stateful. Deve ser possível estabelecer o número máximo de fragmentos por pacotes e timeouts de remontagem. 2.1.2.8. Deve prover proteção contra IP spoofing (por interface), sem necessidade de configuração de listas de controle de acesso. 2.1.2.9. Deve suportar operação stateful em modo transparente (bridge mode). 2.1.2.10. Deve proteger aplicações de VoIP suportando os protocolos de sinalização H323, SIP, MGCP e SCCP. Devem ser suportadas, no mínimo, as seguintes funcionalidades: Criação e terminação dinâmica das conexões de sinalização assim como abertura/fechamento das portas de mídia (RTP/RTCP) negociadas dentro da sessão de sinalização. Filtragem stateful dos protocolos de Telefonia IP citados em ambientes com NAT e PAT (NAT hide). Logging das conexões dinâmicas criadas e visualização das conexões criadas (sinalização e mídia) em ambientes com e sem NAT. 2.1.2.11. Possuir capacidade de limitar o número de conexões TCP simultâneas para um endereço de destino especificado. 2.1.2.12. Possuir capacidade de limitar o número de conexões TCP incompletas ( half-open ) simultâneas para um endereço de destino especificado. 2.1.2.13. Possuir capacidade de limitar o número de conexões TCP simultâneas para cada IP de origem (sem necessidade de especificar tal endereço IP). 2.1.2.14. Possuir capacidade de limitar o número de conexões TCP incompletas ( half-open ) simultâneas para cada IP de origem (sem necessidade de especificar tal endereço IP). 2.1.2.15. Possibilitar o registro de toda a comunicação realizada através do firewall e de todas as tentativas de abertura de sessões e conexões que por ele forem recusadas.

2.1.2.16. Deve suportar agrupamento lógico de objetos ( object grouping ) para criação de regras de filtragem. Deve ser possível criar grupos de pelo menos os seguintes tipos de objetos: hosts, redes IP, serviços. Deve ser possível verificar a utilização ( hit counts ) de cada regra de filtragem ( Access Control Entry ) individualmente, independentemente do fato de a configuração da política ter utilizado o conceito de agrupamento lógico de objetos. 2.1.2.17. Deve suportar regras de filtragem L3/L4 (listas de controle de acesso) aplicáveis de forma global (válidas para todas as interfaces simultaneamente) e regras que sejam válidas apenas para uma interface lógica específica 2.1.2.18. Deve suportar a tradução do endereço IP carregado em uma mensagem DNS Reply (NAT na camada de aplicação) juntamente com a tradução do endereço IP presente no cabeçalho L3. 2.1.2.19. Implementar políticas de controle de acesso baseadas em informações de horário ( time-based access control ); 2.1.2.20. Devem ser implementadas políticas de firewall por usuário. O firewall deve ser capaz de obter as credenciais do usuário através de um prompt padrão HTTP/HTPPS e, após validação das credenciais em um servidor RADIUS, aplicar as listas de controle de acesso ( downloadable ACLs ) informadas pelo servidor RADIUS e que especificam o tráfego permitido para o usuário autenticado. 2.1.2.21. Devem ser implementadas políticas de acesso por usuário obtidas a partir da integração com servidor Active Directory (AD). Caso tal integração requeira agentes externos, estes deverão ser fornecidos. 2.1.2.22. Deve suportar a operação stateful em ambientes IPv6, atendendo, no mínimo os seguintes requisitos: Deve suportar a criação simultânea de regras IPv4 e IPv6. Deve suportar roteamento estático de pacotes IPv6. Deve suportar anti-spoofing (sem necessidade de configuração de ACLs) para endereços IPv6. Deve implementar randomização do número de sequência TCP para conexões TCP que trafegam sobre IPv6. Deve suportar agrupamento lógico de objetos IPv6 (redes, hosts, serviços) e criação de regras (ACLs) usando tais objetos.

Deve suportar gerenciamento sobre IPv6. Devem ser suportados pelo menos os seguintes protocolos de gerência: SSH e HTTPS. Deve suportar stateful failover de conexões IPv6 2.1.2.23. Possuir suporte a tecnologia de Firewall Virtual, sendo fornecido com, pelo menos, duas instâncias totalmente isoladas entre si. Dentro de cada instância de Firewall deve ser possível definir regras independentes de filtragem, regras de NAT, rotas e VLANs alocadas. Dentro de cada instância de Firewall deve ser possível alocar no mínimo os seguintes tipos de recursos: número conexões simultâneas, número de endereços IP traduzidos, número de sessões de gerenciamento simultâneas, número de endereços MAC. Dentro de cada instância de Firewall deve ser possível limitar (promover rate limiting ) os seguintes recursos: taxa de estabelecimento de novas conexões, taxa de inspeção de aplicações, taxa de transmissão de mensagens Syslog. A exaustão dos recursos alocados para uma dada instância de Firewall não deve ter influência sobre a operação das demais instâncias. 2.1.3. Características de IPS 2.1.3.1. Deve analisar cada um dos pacotes que trafegam pela rede a que está conectado e também a relação de tais pacotes com os adjacentes a ele no fluxo de dados da rede (análise de contexto); 2.1.3.2. Deve utilizar assinaturas construídas com base em informações de vulnerabilidade e não somente em exploits específicos; 2.1.3.3. Deve suportar a modificação de assinaturas, isto é, permitir a edição de assinaturas existentes na base de dados, ajustando-se ao perfil de tráfego de rede; 2.1.3.4. Deve suportar a criação de assinaturas, isto é, permitir que se possam criar novas assinaturas e anexá-las à base de dados existente, adaptando-se as reais necessidades de tráfego de rede (na criação das novas assinaturas deve ser permitida a utilização de parâmetros de nível 2 a nível 7 do modelo OSI); 2.1.3.5. Deve ser possível criar assinaturas do tipo string-match e associá-las a qualquer porta TCP para verificação da ocorrência de conjunto de caracteres definidos pelo administrador de política de segurança no conteúdo dos pacotes IP que trafegam pela rede. 2.1.3.6. Deve suportar Protocol Anomaly Detection como método de análise de tráfego;

2.1.3.7. Deve suportar verificação de adequação dos protocolos que trafegam na rede às definições destes constantes nas RFCs (análise de RFC compliance ); 2.1.3.8. Deve suportar análise stateful de pacotes para garantir maior acurácia de detecção; 2.1.3.9. Deve detectar ataques associados a protocolos que não estejam usando as portas canônicas de serviço (portas padrão reservadas para os protocolos de aplicação); 2.1.3.10. Deve promover reordenação e remontagem de fragmentos IP antes de efetuar análise; 2.1.3.11. Deve possuir estrutura de normalização de tráfego para que possam combater as técnicas de evasão; 2.1.3.12. Devem ser suportados no mínimo os seguintes tipos de reação (configuráveis por assinatura de ataque): geração de alerta, gerar trap SNMP, fazer logging dos pacotes gerados pelo sistema vítima, fazer logging dos pacotes gerados pelo sistema que está efetuando o ataque, promover reset da conexão TCP, bloquear o pedido de conexão, bloquear o endereço que está gerando o ataque de conexão, negar in-line os pacotes associados ao ataque; 2.1.3.13. Deve suportar logging de sessão via IP ( IP session logging ). Os logs devem ser compatíveis com formato TCPDump ; 2.1.3.14. Deve suportar filtragem de assinaturas por endereço IP de origem/destino (possibilidade de definir que uma dada assinatura de ataque deverá ser disparada somente quando estiver associada a endereços IP origem/destino específicos); 2.1.3.15. Deve possuir capacidade de bloquear tráfego de pelo menos os seguintes protocolos peer-to-peer (kazaa, gnutella, soulseek e bittorrent); 2.1.3.16. Deve possuir capacidade de bloquear tráfego de instant messagers ; 2.1.3.17. Deve ser capaz de detectar pelo menos os seguintes tipos de ataques: Simplex-Mode TCP hijacking, E-mail Spam, BackOriffice 2000 StealthMode, Unicode Decodes, IIS Unicode exploit, cross-site scripting, directory traversal, command injection, SQL Injection, Header Spoofing; 2.1.3.18. Deve ser capaz de detectar atividade de Port Scanning ( Full connect, SYN Stealth, FIN Stealth, UDP); 2.1.3.19. Deverá ter uma base de assinaturas com descrição da utilização de cada uma delas e tipos de ataques detectados. Deverá ser possível a atualização de assinaturas em caso de detecção de novas vulnerabilidades durante o período de vigência do contrato de suporte e atualizações da licença adquirida.

2.1.4. Características de VPN 2.1.4.1. Deve implementar a criação de VPNs IPSEC com criptografia 56-bit DES, 168-bit 3DES, 128-bit AES e 256-bit AES. Deve possuir desempenho de no mínimo 300 Mbps para tratamento de conexões IPSEC (padrões AES e 3DES). A criptografia deve ser realizada em hardware; 2.1.4.2. Deve ser suportada a criação de VPNs IPSec usando os padrões IKEv1 e IKEv2. 2.1.4.3. Deve suportar a terminação de SSL VPN. Inicialmente será necessário o fornecimento de licença de software para terminação de apenas 200 (duzentas) sessões simultâneas SSL- VPN; 2.1.4.4. Devem ser suportados os seguintes modos de terminação SSL VPN: SSL VPN sem cliente (modo portal) SSL VPN com cliente com transporte TCP SSL VPN com cliente com transporte UDP (Nesse modo o trafego do cliente SSL VPN é tunelado através do protocolo DTLS, RFC 4748) 2.1.4.5. Deve suportar a terminação simultânea de conexões IPSEC VPN e SSL VPN; 2.1.4.6. Deve suportar o uso de certificados digitais emitidos pela autoridade certificadora ICP Brasil para autenticação das VPNs IPSec e SSL; 2.1.4.7. Características específicas de SSL-VPN: Devem ser suportadas no modo clientless, no mínimo as seguintes aplicações transportadas sobre conexões SSL: HTTP, POP3, IMAP4, SMTP, Telnet, SSH, FTP, Windows Terminal Services, VNC, Outlook/Outlook Express. Deve ser possível especificar as URLs acessíveis através de conexões SSL VPN. Deve ser possível criar diferentes grupos de usuários SSL VPN, com definição por grupo, do tipo de serviço permitido sobre as conexões SSL para o concentrador (WEB, e-mail, sistemas de arquivos). Deve ser possível realizar verificação de parâmetros na máquina do usuário antes da apresentação das credenciais de identificação ("pre-login"). Deverá ser possível verificar pelo menos os seguintes atributos:

Chaves de Registro, Arquivos, e a Versão do Sistema Operacional. Deve ser possível a criação de regras para verificação da conformidade da máquina com a política de segurança. Dever ser possível verificar no mínimo os seguintes elementos: a instalação, habilitação e atualização do software antivírus e anti-spyware e existência de personal firewall habilitado. Deve suportar autenticação SSL-VPN através de teclado virtual apresentado ao usuário. Deve ser possível a criação de políticas de SSL VPN dinâmicas baseadas pelo menos nos seguintes parâmetros: Sistema Operacional Utilizado; Anti-vírus; Anti-spyware; Chave de Registro (existência e valor específico a ela atribuído); Arquivos do sistema; Atributos LDAP. 2.2. CARACTERÍSTICAS DO GERENCIAMENTO DA SOLUÇÃO DE SEGURANÇA 2.2.1. Funcionalidades gerais 2.2.1.1. Equipamento do tipo appliance, ou solução de hardware e software, dedicado à solução de gerenciamento centralizado. Deve ser fornecido com todos os acessórios e licenças para funcionamento; 2.2.1.2. A solução de gerenciamento de segurança deve ser baseada em técnicas de aplicação e gerenciamento de políticas de forma centralizada, as quais podem ser organizadas de forma hierárquica e distribuídas para grupos de dispositivos de segurança ou para todos os dispositivos de segurança já existentes da rede; 2.2.1.3. A solução deve implementar uma tabela única de políticas de segurança, a qual deverá ser utilizada para a distribuição das políticas por todo o ambiente administrado; 2.2.1.4. A solução deve possuir ferramenta de análise de tráfego (Flow); 2.2.1.5. As políticas de segurança dever ser automaticamente adaptadas de acordo com o dispositivo para o qual ela está sendo enviada; 2.2.1.6. A solução deve implementar funcionalidade de agrupamento de políticas que façam referência a um objeto específico a ser analisado de forma a transformar esse grupo de políticas em uma única regra que desempenhará o mesmo papel na política de segurança proposta por um conjunto de regras;

2.2.1.7. A solução deve possuir ferramenta de análise das regras, permitindo que sejam analisadas as regras que estão se sobrepondo ou entrando em conflito com outras regras já existentes; 2.2.1.8. A solução deve implementar a contabilidade das regras que foram atingidas ou entraram em conformidade com o tráfego que está passando pela rede; 2.2.1.9. A solução deve permitir a verificação de qual parte da rede, origem, destino, serviço ou wildcard, está sendo atingido por determinada regra; 2.2.1.10. A solução deve permitir a detecção de alteração e/ou tentativas de alteração nos dispositivos por meio de interfaces out-of-band e avisar ao administrador; 2.2.1.11. A solução deve permitir o gerenciamento de serviços de segurança integrados, entre os quais QoS em VPN, roteamento e Controle de Acesso a Rede; 2.2.1.12. A solução deve permitir o agrupamento de dispositivos, de acordo com a funcionalidade e/ou localização física dos mesmos, com a finalidade de gerenciar todos os dispositivos de uma só vez; 2.2.1.13. A solução deve permitir que um dado equipamento possa pertencer a mais de um grupo simultaneamente; 2.2.1.14. A solução deve permitir a reutilização de objetos a serem analisados e/ou monitorados em um dispositivo por outros dispositivos que vierem a fazer parte do ambiente, sem a necessidade da criação das mesmas políticas novamente; 2.2.1.15. A solução deve permitir o retorno às configurações anteriores dos dispositivos, para a necessidade de recuperação de falhas; 2.2.1.16. A solução deve permitir o gerenciamento operacional da rede monitorada, realizando funções de distribuição de softwares, relatório de inventário de dispositivos. 2.2.1.17. A solução deve ser capaz de testar a conectividade de equipamentos já foram ou estão sendo adicionados; 2.2.1.18. A solução deve permitir a configuração de servidores de Syslog e NTP nos equipamentos suportados; 2.2.1.19. A solução deve suportar configuração de alta-disponibilidade dos equipamentos; 2.2.1.20. A solução deve oferecer a opção de se apresentar uma tela com a topologia dos firewalls, para fins de monitoramento. 2.2.2. Funcionalidades para VPN 2.2.2.1. A solução deve ser capaz de descobrir configurações existentes de VPN site-to-site e acesso remoto;

2.2.2.2. A solução deve permitir as configurações de VPN nas seguintes modalidades: site-to-site, hub-and-spoke, full-mesh e extranet; 2.2.2.3. A solução deve permitir que as VPNs possam ser configuradas remotamente; 2.2.2.4. A solução deve permitir a configuração de dispositivos de VPN com suporte a failover automático e balanceamento de carga. 2.2.3. Funcionalidades para IPS 2.2.3.1. A solução deve permitir que múltiplas VLANs sejam configuradas para uma única interface do IPS; 2.2.3.2. A solução deve implementar a configuração de rate limiting nos IPSs de forma a impedir que certos tipos de tráfego passem a consumir banda em excesso; 2.2.3.3. A solução deve implementar atualização automática das assinaturas, patches e de outras releases nos IPSs monitorados 2.2.3.4. A solução deve permitir a cópia das configurações específicas de cada assinatura de um dispositivo para vários outros; 2.2.3.5. A solução deve suportar a configuração de: Sensores virtuais; 2.2.4. Escalabilidade Detecção de anomalias; Reconhecimento de Sistemas Operacionais; Criação de assinaturas customizadas; Assistente para atualização de assinaturas, pré-visualização e ajustes de novas assinaturas; Gerência de licenças para assinaturas. 2.2.4.1. Suportar pelo menos 5.000 (cinco mil) equipamentos (virtuais ou físicos); 2.2.4.2. Suportar pelo menos 1.600.000 (um milhão e seiscentas mil) de entradas de controle de acessos (ACEs); 2.2.4.3. Suportar pelo menos 50.000 (cinquenta mil) ACEs por regra de firewall; 2.2.4.4. Suportar pelo menos 20 (vinte) usuários simultâneos com acesso somente-leitura; 2.2.4.5. Suportar pelo menos 10 (dez) usuários simultâneos com acesso privilegiado;

2.2.4.6. Suportar a configuração de VPN full-mesh de pelo menos 400 (quatrocentos) ativos; 2.2.4.7. A solução deve suportar operar em modo de workflow, quando é necessária uma aprovação para a distribuição de configurações; 2.2.4.8. A solução deve suportar acesso baseado em perfil de usuário com as permissões de visualizar, modificar, aprovar e distribuir por tipo de objeto e política; 2.2.4.9. O acesso aos equipamentos devem ser também ser separados por perfil de usuário. 2.3. EQUIPAMENTO DE SEGURANÇA MULTIFUNÇÃO TIPO 1 2.3.1. CARACTERÍSTICAS ESPECÍFICAS DO EQUIPAMENTO DE SEGURANÇA MULTIFUNÇÃO TIPO 1 QUANTIDADE: 4 (QUATRO) 2.3.1.1. Deve ser fornecido com fontes redundantes internas ao equipamento; 2.3.1.2. Deve ser fornecido com pelo menos 02 interfaces 10/100/1000 auto-sense e 04 (quatro) interfaces 10 Gigabit Ethernet; 2.3.1.3. Deve suportar o acréscimo de pelo menos 4 (quatro) interfaces 10 Gigabit Ethernet (10GE); 2.3.1.4. Deve suportar o acréscimo de pelo menos 8 (oito) interfaces Gigabit Ethernet 10/100/1000; 2.3.1.5. Deve permitir a criação de no mínimo 1000 interfaces VLAN 2.3.1.6. Deve suportar, no mínimo, 2.000.000 (dois milhões) de conexões simultâneas de firewall em sua tabela de estados; 2.3.1.7. Deve suportar a criação de pelo menos 200.000 (duzentas mil) novas conexões TCP por segundo. 2.3.1.8. Os valores de desempenho especificados nos itens 2.3.1.6 e 2.3.1.7 devem ser fornecidos de forma centralizada. Não serão aceitas soluções baseadas em combinação de módulos de firewalls em um chassi. 2.3.1.9. Deve suportar funcionalidade de Stateful Firewall com desempenho mínimo de 20 Gbps. 2.3.1.10. Deve possuir throughput de IPS de pelo menos 2 Gbps; 2.3.1.11. Deve possuir throughput de VPN de 2 Gbps (com algoritmos criptográficos 3DES e AES); 2.3.1.12. Deve suportar o encaminhamento de pelo menos 4.000.000 (quatro milhões) de pacotes por segundo;

2.3.1.13. Deve implementar pelo menos 4.000 (quatro mil) peers VPN (túneis IPSec) simultâneos. As licenças de software cliente para operação nos modelos IKEv1 e IKEv2 devem ser fornecidas para tal quantidade de usuários. 2.3.1.14. Deve suportar pelo menos 2.000 (dois mil) peers SSL-VPN (qualquer combinação dos modelos clientless e client-based). 2.3.1.15. Deve suportar a adição de novas instâncias virtuais de Firewall através de licenças de software. Devem ser suportados um total de pelo menos 100 licenças virtuais, conforme descrito no item 2.1.2.23 2.4. Equipamento de Segurança Multifunção Tipo 2 2.4.1. CARACTERÍSTICAS ESPECÍFICAS DO EQUIPAMENTO DE SEGURANÇA MULTIFUNÇÃO TIPO 2 QUANTIDADE: 16 (DEZESSEIS) 2.4.1.1. Deve possuir pelo menos 05 (cinco) interfaces UTP 10/100/1000; 2.4.1.2. Deve permitir a criação de no mínimo 200 interfaces VLAN; 2.4.1.3. Deve suportar, no mínimo, 300.000 (trezentas mil) conexões simultâneas de firewall em sua tabela de estados; 2.4.1.4. Deve suportar a criação de pelo menos 25.000 (vinte e cinco mil) novas conexões TCP por segundo; 2.4.1.5. Os valores de desempenho especificados nos itens 2.4.1.3 e 2.4.1.4 devem ser fornecidos de forma centralizada. Não serão aceitas soluções baseadas em combinação de módulos de firewalls em um chassi. 2.4.1.6. Deve suportar funcionalidade de Stateful Firewall com desempenho mínimo de 600 Mbps. 2.4.1.7. Deve suportar o encaminhamento de pelo menos 400.000 (quatrocentos mil) pacotes por segundo; 2.4.1.8. Deve possuir throughput de IPS de pelo menos 600 Mbps; 2.4.1.9. Deve possuir throughput de VPN de 300 Mbps (com algoritmos criptográficos 3DES e AES); 2.4.1.10. Deve implementar pelo menos 1.000 (mil) peers VPN (túneis IPSec) simultâneos. As licenças de software cliente para operação nos modelos IKEv1 e IKEv2 devem ser fornecidas para tal quantidade de usuários. 2.4.1.11. Deve suportar pelo menos 500 (quinhentos) peers SSL-VPN (qualquer combinação dos modelos clientless e client-based). 2.4.1.12. Deve suportar a adição de novas instâncias virtuais de Firewall através de licenças de software. Devem ser suportados

um total de pelo menos 10 (dez) licenças virtuais, conforme descrito no item 2.1.2.23. 3. DA GARANTIA, ASSISTÊNCIA TÉCNICA E NÍVEIS DE SERVIÇO - SLA 3.1. Os equipamentos deverão ter garantia e assistência técnica, no local onde serão instalados, por um período mínimo de 48 (quarenta e oito) meses, contado a partir do recebimento definitivo, sem ônus para o Ministério da Justiça. 3.2. Durante o período de garantia será assegurado o suporte técnico que deverá estar disponível nas 24 (vinte e quatro) horas, a saber, das 0:00 hs às 24:00 incluindo sábados, domingos e feriados. 3.3. A abertura de chamado para suporte técnico, sem ônus para o Ministério da Justiça, deverá ser passível de ser realizado por intermédio de acesso ao suporte no site do fabricante, telefone, correio eletrônico e/ou fax, para dúvidas e solução de quaisquer problemas, enquanto estiver vigorando o prazo de garantia da solução, obrigando-se a contratada iniciar e cumprir os seguintes prazos: 3.3.1. Capitais 3.3.1.1. Indisponibilidade parcial 1 - inicio do atendimento no próximo dia útil, com período de solução de até 8 horas corridas. 3.3.1.2. Indisponibilidade total 2 reestabelecimento em até 4 horas corridas. 3.3.1.3. Serviços de atualização de versão: em até 5 dias, conforme agendamento definido pelo contratante. 3.3.1.4. Suporte técnico nível 1 o suporte via telefone, chat e outros meios de instant-messenger deverá ser 24x7 (vinte e quatro horas por dia, sete dias por semana). 3.3.2. Interior 3.3.2.1. Indisponibilidade parcial¹ - inicio do atendimento no próximo dia útil, com período de solução de até 8 horas corridas. 3.3.2.2. Indisponibilidade total² reestabelecimento em até 12 horas corridas. 3.3.2.3. Serviços de atualização de versão: em até 5 dias, conforme agendamento definido pelo contratante. 3.3.2.4. Suporte técnico nível 1 o suporte via telefone, chat e outros meios de instant-messenger deverá ser 24x7 (vinte e quatro horas por dia, sete dias por semana). 1 A indisponibilidade parcial compreende desde a impossibilidade de aplicação de uma regra, filtro, atualização e etc. até a inoperância de um equipamento redundante, deixando a alta disponibilidade comprometida ou inexistente. 2 A indisponibilidade total compreende a inoperância da solução que pode ser desde o seu gerenciamento, situação na qual não se consiga aplicar as regras, filtros e atualização, até a inoperância dos equipamentos redundantes e, por consequência, impossibilidade de acesso aos sistemas e serviços de rede de dados do contratante.

3.4. A contratada deverá realizar os serviços de suporte técnico a solução, às suas expensas, obrigando-se a trocar os componentes que apresentarem 3 (três) ou mais incidentes repetidos ou intercalados no prazo de 60 dias. 3.5. No caso de remoção de algum componente físico da solução para manutenção por parte da contratada, esta se obriga em colocar um equipamento em atividade com iguais características, cumprindo todas as características da solução. 3.6. Caso o componente físico original não retorne em 5 dias corridos, a contratada fica obrigada a fornecer novo componente que se adeque integralmente a solução. 3.7. A falta de solução do problema conforme indicado nos itens anteriores, sem justificativa aceita pelo MJ, poderá implicar em aplicação de multa no valor correspondente a 0,02% (zero vírgula zero dois por cento) do valor total da contratação, por dia de atraso na solução. 3.8. A indisponibilidade do serviço de suporte técnico, assim como da central de abertura de chamados, poderá implicar em aplicação de multa no valor correspondente a 0,02% (zero vírgula zero dois por cento) do valor total da contratação, por dia de indisponibilidade. 3.9. Os chamados abertos somente poderão ser fechados após autorização do MJ. 3.10. Os chamados deverão ser abertos e fechados somente por pessoal designado pelo MJ para esse fim. 3.11. Caso o chamado seja encerrado pela contratada sem que tenha sido previamente autorizado pelo(s) servidor (es) designado(s), poderá ser aplicada multa à contratada no valor correspondente a 0,01% (zero vírgula zero um por cento) do valor total da contratação, por ocorrência. 3.12. Os preços relativos a deslocamento de técnicos e transporte de componentes e equipamentos devem estar incluídos no valor do serviço. 3.13. A contratada apresentará um relatório de assistência técnica para cada atendimento feito, tenha sido no Ministério da Justiça ou nas instalações da própria Contratada, contendo data, hora de chamada, início e término do atendimento, identificação do problema, as providências adotadas e as informações pertinentes, para acompanhamento e controle da execução do Contrato. 3.14. Cada relatório de assistência técnica deverá ser assinado por técnico do Ministério da Justiça, ou por ele indicado, e pelo responsável pelo atendimento da empresa contratada. 3.15. Entende-se por início do atendimento a hora da abertura do chamado por telefone, correio eletrônico ou fax. 3.16. Entende-se por término do atendimento o momento a partir do qual a solução estiver disponível e em perfeitas condições de funcionamento. 3.17. A garantia será dada através da atualização dos softwares em todas as suas funcionalidades para as novas versões com a disponibilização de arquivos de correções, assinaturas, atualizações e serviços de execução se solicitados pelo contratante.

3.18. As atualizações deverão englobar assinaturas de atualização das funcionalidades do conjunto de softwares, inclusive das assinaturas de filtros.