SERVIÇO SOCIAL DO COMÉRCIO - SESC
SERVIÇO SOCIAL DO COMÉRCIO - SESC
Estância Ecológica Sesc Pantanal
OBJETO: Contratação de empresa especializada para renovação da subscrição de licenças do Palo Alto Threat Prevention, Wildefire e URL Filtering para Cluster Xxxx Xxxx Xxxxxxxx XX-0000 com garantia técnica de hardware e software incluindo serviços instalação e treinamento.
TERMO DE REFERÊNCIA
Sesc | Serviço Social do Comércio | Estância Ecológica Sesc Pantanal | xxx.xxxxxxxxxxxx.xxx.xx Av.Xxxxxxx Xxxxxx, 218 – Jardim Aeroporto – Várzea Grande/MT XXX 00.000.000 TEL 00 0000 0000
TERMO DE REFERÊNCIA
1. ESPECIFICAÇÃO DO OBJETO
Contratação de empresa especializada para renovação da subscrição de licenças do Palo Alto Threat Prevention, Wildefire e URL Filtering para Cluster Xxxx Xxxx Xxxxxxxx XX-0000 com garantia técnica de hardware e software incluindo serviços instalação e treinamento.
Relação dos softwares com PART NUMBER (S/N001801028858 | P/N 750- 000017-00T) (o código e a descrição dos produtos podem sofrer alteração por parte da Palo Alto) e abaixo a quantidade global para atender as solicitações do Sesc Pantanal, todos os com tempo de licenciamento e suporte para 03 anos.
ITEM | PART NUMBER | DESCRIÇÃO | QTDE |
1 | PA-3020 PAN-PA- 3020-URL4-3YR | PAN-PA-3020-URL4-3YR-HA2 | 1 |
2 | PA-3020 PAN-PA- 3020-TP-3YR | Threat prevention subscription 3-year prepaid for device in | 1 |
3 | PA-3020 PAN-PA- 3020-WF-3YR | WildFire subscription 3-year prepaid for device in | 1 |
4 | PAN-SVC-PREM- 3020-3 | Premium support 3-year prepaid, PA-3020 WCSS | 1 |
2. CARACTERÍSTICAS ESPECÍFICAS DE DESEMPENHO E HARDWARE DO FIREWALL DE PRÓXIMA GERAÇÃO
FIREWALL DE PROXIMA GERAÇÃO
2..1. CARACTERÍSTICAS GERAIS DO FIREWALL
2..1.1. Por plataforma de segurança entende-se hardware e software integrados do tipo appliance;
2..1.2. Por cada equipamento que compõe a plataforma de segurança, entende-se o hardware e as licenças de softwares necessárias para o seu funcionamento;
2..1.3. Por console de gerência e monitoração, entende-se as licenças de software necessárias para as duas funcionalidades, bem como hardware dedicado para o funcionamento das mesmas;
2..1.4. A console de gerência e monitoração podem residir no mesmo appliance de proteção de rede, desde que possuam recurso de CPU, memória, interface de rede e sistema operacional dedicados para esta função;
2..1.5. Na data da proposta, nenhum dos modelos ofertados poderão estar listados no site do fabricante em listas de end-of-life e end- of-sale.
2..1.6. A solução deve consistir de appliance de proteção de rede com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;
2..1.7. Por funcionalidades de NGFW entende-se: reconhecimento de aplicações, prevenção de ameaças, identificação de usuários e controle granular de permissões;
2..1.8. As funcionalidades de proteção de rede que compõe a plataforma de segurança,podem funcionar em múltiplos appliances desde que obedeçam a todos os requisitos desta especificação;
2..1.9. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;
2..1.10. O hardware e software que executem as funcionalidades de proteção de rede, bem como a console de gerência e monitoração, devem ser do tipo appliance. Não serão aceitos equipamentos servidores e sistema operacional de uso genérico;
2..1.11. Todos os equipamentos fornecidos devem ser próprios para montagem em rack 19”, incluindo kit tipo trilho para adaptação se necessário e cabos de alimentação;
2..1.12. O software deverá ser fornecido em sua versão mais atualizada; 2..1.13. Os dispositivos de proteção de rede devem possuir pelo menos
as seguintes funcionalidades:
Suporte a 4094 VLAN Tags 802.1q; Agregação de links 802.3ad e LACP;
Policy based routing ou policy based forwarding; Roteamento multicast (PIM-SM);
DHCP Relay;
DHCP Server; Jumbo Frames;
Suporte à criação de objetos de rede que possam ser utilizados como endereço IP de interfaces L3;
Suportar sub-interfaces ethernet logicas.
2..1.14. Deve suportar os seguintes tipos de NAT: Nat dinâmico (Many-to-1);
Nat dinâmico (Many-to-Many); Nat estático (1-to-1);
NAT estático (Many-to-Many); Nat estático bidirecional 1-to-1; Tradução de porta (PAT);
NAT de Origem; NAT de Destino;
Suportar NAT de Origem e NAT de Destino simultaneamente; 2..1.15. Deve implementar Network Prefix Translation (NPTv6),
prevenindo problemas de roteamento assimétrico; 2..1.16. Deve implementar o protocolo ECMP;
2..1.17. Deve implementar balanceamento de link por hash do IP de origem;
2..1.18. Deve implementar balanceamento de link por hash do IP de origem e destino;
2..1.19. Deve implementar balanceamento de link através do método round-robin;
2..1.20. Deve implementar balanceamento de link por peso. Nesta opção deve ser possível definir o percentual de tráfego que será escoado por cada um dos links. Deve suportar o balanceamento de, no mínimo, quatro links;
2..1.21. Deve implementar balanceamento de link através de políticas por usuário e grupos de usuários do LDAP/AD;
2..1.22. Deve implementar balanceamento de link através de políticas por aplicação e porta de destino;
2..1.23. Deve implementar o protocolo Link Layer Dicovery (LLDP), permitindo que o appliance e outros ativos da rede se comuniquem para identificação da topologia da rede em que estão conectados e a função dos mesmos facilitando o processo de throubleshooting. As informações aprendidas e armazenadas pelo appliance devem ser acessíveis via SNMP;
2..1.24. Enviar log para sistemas de monitoração externos, simultaneamente;
2..1.25. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;
2..1.26. Deve permitir configurar certificado caso necessário para autenticação no sistema de monitoração externo de logs;
2..1.27. Proteção contra anti-spoofing;
2..1.28. Deve permitir bloquear sessoes TCP que usarem variações do 3- way hand-shake, como 4 way e 5 way split hand-shake, prevenindo desta forma possíveis tráfegos maliciosos;
2..1.29. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);
2..1.30. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);
2..1.31. Suportar a OSPF graceful restart;
2..1.32. Suportar no mínimo as seguintes funcionalidades em IPv6: SLAAC (address auto configuration), Identificação de usuários a partir do LDAP/AD, Captive Portal, IPv6 over IPv4 IPSec, Regras de proteção contra DoS (Denial of Service), De-criptografia SSL e SSH, PBF (Policy Based Forwarding), QoS, IPSEc, Ativo/Ativo, Ativo/Passivo, SNMP, NTP, SYSLOG, DNS e controle de aplicação;
2..1.33. Os dispositivos de proteção devem ter a capacidade de operar de forma simultânea em uma única instância de firewall, mediante o uso de suas interfaces físicas nos seguintes modos: Modo sniffer (monitoramento e análise do tráfego de rede), camada 2 (l2) e camada 3 (l3);
2..1.34. Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;
2..1.35. Modo Camada – 2 (L2), para inspeção de dados em linha e ter visibilidade e controle do tráfego em nível de aplicação;
2..1.36. Modo Camada – 3 (L3), para inspeção de dados em linha e ter visibilidade e controle do tráfego em nível de aplicação operando como default gateway das redes protegidas;
2..1.37. Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;
2..1.38. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo:
2..1.39. Em modo transparente; 2..1.40. Em layer 3;
2..1.41. A configuração em alta disponibilidade deve sincronizar: Sessões;
Configurações, incluindo, mas não limitado a políticas de Firewall, NAT, QOS e objetos de rede;
Certificados de-criptografados; Associações de Segurança das VPNs; Tabelas FIB;
2..1.42. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link.
2..1.43. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL Decryption e protocolos de roteamento dinâmico devem operar em caráter permanente, podendo ser utilizadas por tempo indeterminado, mesmo que não subsista o direito de receber atualizações ou que não haja contrato de garantia de software com o fabricante.
2..2. CONTROLE POR POLÍTICA DE FIREWALL
2..2.1. Deverá agrupar logicamente interfaces físicas ou virtuais em grupos e utilizar em políticas de firewall, tornando desnecessário a utilização de endereços IP nos parâmetros origem/destino;
2..2.2. Controles de políticas por porta e protocolo;
2..2.3. Controle de políticas por aplicações grupos estáticos de aplicações, grupos dinâmicos de aplicações (baseados em
características e comportamento das aplicações) e categorias de aplicações;
2..2.4. Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança;
2..2.5. Controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS);
2..2.6. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound);
2..2.7. Deve de-criptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2;
2..2.8. Controle de inspeção e de-criptografia de SSH;
2..2.9. Bloqueios dos seguintes tipos de arquivos: bat, cab, dll, exe, pif, e reg
2..2.10. Traffic shaping QoS baseado em Políticas (Prioridade, Garantia e Máximo)
2..2.11. QoS baseado em políticas para marcação de pacotes (diffserv marking), inclusive por aplicações;
2..2.12. Suporte a objetos e regras IPV6; 2..2.13. Suporte a objetos e regras multicast;
2..2.14. Deve suportar no mínino três tipos de negação de tráfego nas políticas de firewall:
Drop sem notificação do bloqueio ao usuário, Drop com opção de envio de ICMP Unreachable para máquina de origem do tráfego, TCP-Reset para o client, TCP-Reset para o server ou para os dois lados da conexão;
2..2.15. Suportar a atribuição de agendamento as políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente.
2..3. CONTROLE DE APLICAÇÕES
2..3.1. Os dispositivos de proteção de rede deverão possuir a capacidade de reconhecer aplicações, independente de porta e protocolo, com as seguintes funcionalidades:
Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos.
Reconhecer pelo menos 1700 aplicações diferentes, incluindo, mas não limitado: a tráfego relacionado a peer-to- peer, redes sociais, acesso remoto, update de software, protocolos de rede, voip, áudio, vídeo, proxy, mensageiros instantâneos, compartilhamento de arquivos, e-mail; Reconhecer pelo menos as seguintes aplicações: bittorrent, gnutella, skype, facebook, linked-in, twitter, citrix, logmein, teamviewer, ms-rdp, vnc, gmail, youtube, http-proxy, http- tunnel, facebook chat, gmail chat, whatsapp, 4shared, dropbox, google drive, skydrive, db2, mysql, oracle, active directory, kerberos, ldap, radius, itunes, dhcp, ftp, dns, wins, msrpc, ntp, snmp, rpc over http, gotomeeting, webex, evernote, google-docs, etc;
Deve inspecionar o payload de pacote de dados com o objetivo de detectar através de expressões regulares
assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo. A checagem de assinaturas também deve determinar se uma aplicação está utilizando a porta default ou não, incluindo, mas não limitado a RDP na porta 80 ao invés de 389;
Deve aplicar heurística a fim de detectar aplicações através de análise comportamental do tráfego observado, incluindo, mas não limitado a Encrypted Bittorrent e aplicações VOIP que utilizam criptografia proprietária;
Identificar o uso de táticas evasivas, ou seja, deve ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas, tais como Skype e ataques mediante a porta 443.
2..3.2. Para tráfego criptografado SSL, deve de-criptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante;
2..3.3. Deve realizar decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo, incluindo, mas não limitado a Yahoo Instant Messenger usando HTTP. A decodificação de protocolo também deve identificar funcionalidades especificas dentro de uma aplicação, incluindo, mas não limitado a compartilhamento de arquivo dentro do Webex. Além de detectar arquivos e outros conteúdos que devem ser inspecionados de acordo as regras de segurança implementadas;
2..3.4. Deve permitir a utilização de aplicativos para um determinado grupo de usuário e bloquear para o restante, incluindo, mas não limitado a Skype. Deve permitir também a criação de políticas de exceção concedendo o acesso a aplicativos como Skype apenas para alguns usuários;
2..3.5. Identificar o uso de táticas evasivas via comunicações criptografadas;
2..3.6. Atualizar a base de assinaturas de aplicações automaticamente; 2..3.7. Reconhecer aplicações em IPv6;
2..3.8. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos do LDAP/AD;
2..3.9. Os dispositivos de proteção de rede devem possuir a capacidade de identificar o usuário de rede com integração ao Microsoft Active Directory, sem a necessidade de instalação de agente no Domain Controller, nem nas estações dos usuários;
2..3.10. Deve ser possível adicionar controle de aplicações em todas as regras de segurança do dispositivo, ou seja, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras;
2..3.11. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas, decodificação de protocolos e análise heurística;
2..3.12. Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;
2..3.13. Permitir nativamente a criação de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante, mantendo a confidencialidade das aplicações do órgão;
2..3.14. A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos:
2..3.15. HTTP, FTP, SMB, SMTP, Telnet, SSH, MS-SQL, IMAP, IMAP, MS-RPC e RTSP;
2..3.16. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;
2..3.17. Deve alertar o usuário quando uma aplicação for bloqueada; 2..3.18. Deve possibilitar que o controle de portas seja aplicado para todas
as aplicações;
2..3.19. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc.) possuindo granularidade de controle/políticas para os mesmos;
2..3.20. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Gtalk, Facebook Chat, etc.) possuindo granularidade de controle/políticas para os mesmos;
2..3.21. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Gtalk chat e bloquear a transferência de arquivos;
2..3.22. Deve possibilitar a diferenciação de aplicações Proxies (ghostsurf, freegate, etc.) possuindo granularidade de controle/políticas para os mesmos;
2..3.23. Deve ser possível a criação de grupos de aplicações baseados em características das aplicações como:
Tecnologia utilizada nas aplicações (Client-Server, Browse Based, Network Protocol, etc).
Nível de risco da aplicação.
Categoria e sub-categoria de aplicações.
Aplicações que usem técnicas evasivas, utilizadas por malwares, como transferência de arquivos e/ou uso excessivo de banda, etc.
2..4. PREVENÇÃO DE AMEAÇAS
2..4.1. Para proteção do ambiente contra ataques, os dispositivos de proteção devem possuir módulo de IPS, Antivírus e Anti-Spyware integrados no próprio appliance de Firewall ou entregue através de composição com outro equipamento ou fabricante;
2..4.2. Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);
2..4.3. As funcionalidades de IPS, Antivírus e Anti-Spyware devem operar em caráter permanente, podendo ser utilizadas por tempo indeterminado, mesmo que não subsista o direito de receber
2..4.4. atualizações ou que não haja contrato de garantia de software com o fabricante;
2..4.5. Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade ativo/ativo e ativo/passivo;
2..4.6. Deve implementar os seguintes tipos de ações para ameaças detectadas pelo IPS, Antipyware e Antivirus: permitir, permitir e gerar log, bloquear, bloquear IP do atacante por um intervalo de tempo e enviar tcp-reset;
2..4.7. As assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;
2..4.8. Exceções por IP de origem ou de destino devem ser possíveis nas regras, de forma geral e assinatura a assinatura;
2..4.9. Deve suportar granularidade nas políticas de IPS Antivírus e Anti- Spyware , possibilitando a criação de diferentes politicas por grupos de interfaces, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens;
2..4.10. Deve permitir o bloqueio de vulnerabilidades; 2..4.11. Deve permitir o bloqueio de exploits conhecidos;
2..4.12. Deve incluir proteção contra ataques de negação de serviços; 2..4.13. Deverá possuir os seguintes mecanismos de inspeção de IPS: Análise de padrões de estado de conexões;
Análise de decodificação de protocolo;
Análise para detecção de anomalias de protocolo; Análise heurística;
IP Defragmentation; Remontagem de pacotes de TCP;
Bloqueio de pacotes malformados.
Ser imune e capaz de impedir ataques básicos como: Synflood, ICMPflood, UDPfloof, etc;
2..4.14. Detectar e bloquear a origem de portscans;
2..4.15. Bloquear ataques efetuados por worms conhecidos, permitindo ao administrador acrescentar novos padrões;
2..4.16. Suportar os seguintes mecanismos de inspeção contra ameaças de rede: análise de padrões de estado de conexões, análise de decodificação de protocolo, análise para detecção de anomalias de protocolo, análise heurística, IP Defragmentation, remontagem de pacotes de TCP e bloqueio de pacotes malformados;
2..4.17. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;
2..4.18. Possuir assinaturas para bloqueio de ataques de buffer overflow; 2..4.19. Deverá possibilitar a criação de assinaturas customizadas pela
interface gráfica do produto;
2..4.20. Deve permitir usar operadores de negação na criação de assinaturas customizadas de IPS e anti-spyware, permitindo a criação de exceções com granularidade nas configurações;
2..4.21. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;
2..4.22. É permitido uso de appliance externo (antivírus de rede), para o bloqueio de vírus e spywares em protocolo SMB de forma a conter malwares se espalhando horizontalmente pela rede;
2..4.23. Suportar bloqueio de arquivos por tipo;
2..4.24. Identificar e bloquear comunicação com botnets;
2..4.25. Deve suportar varias técnicas de prevenção, incluindo Drop e tcp- rst (Cliente, Servidor e ambos);
2..4.26. Deve suportar referência cruzada com CVE;
2..4.27. Registrar na console de monitoração as seguintes informações sobre ameaças identificadas:
O nome da assinatura ou do ataque, aplicação, usuário, origem e o destino da comunicação, além da ação tomada pelo dispositivo;
2..4.28. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS e Antyspyware;
2..4.29. Deve possuir a função resolução de endereços via DNS, para que conexões com destino a domínios maliciosos sejam resolvidas pelo Firewall com endereços (IPv4 e IPv6), previamente definidos;
2..4.30. Permitir o bloqueio de vírus, pelo menos, nos seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;
2..4.31. Os eventos devem identificar o país de onde partiu a ameaça; 2..4.32. Deve incluir proteção contra vírus em conteúdo HTML e
javascript, software espião (spyware) e worms.
2..4.33. Proteção contra downloads involuntários usando HTTP de arquivos executáveis. maliciosos.
2..4.34. Rastreamento de vírus em pdf.
2..4.35. Deve permitir a inspeção em arquivos comprimidos que utilizam o algoritmo deflate (zip, gzip, etc.)
2..4.36. Deve ser possível a configuração de diferentes políticas de controle de ameaças e ataques baseado em políticas do firewall considerando Usuários, Grupos de usuários, origem, destino, grupos lógicos de interfaces, etc, ou seja, cada política de firewall poderá ter uma configuração diferentes de IPS, sendo essas políticas por Usuários, Grupos de usuário, origem, destino, zonas de segurança.
2..5. ANÁLISE DE MALWARES MODERNOS
2..5.1. Devido aos Malwares hoje em dia serem muito dinâmicos e um antivírus comum reativo não ser capaz de detectar os mesmos com a mesma velocidade que suas variações são criadas, a solução ofertada dever possuir funcionalidades para análise de Malwares não conhecidos incluídas na própria ferramenta ou entregue com composição com outro fabricante;
2..5.2. O dispositivo de proteção deve ser capaz de enviar arquivos trafegados de forma automática para análise em nuvem pública ou local, onde o arquivo será executado e simulado em ambiente controlado;
2..5.3. Selecionar através de políticas granulares quais tipos de arquivos sofrerão esta análise incluindo, mas não limitado a: endereço IP de origem/destino, usuário/grupo do AD/LDAP, aplicação, porta, URL/categoria de URL de destino, tipo de arquivo e todas estas opções simultaneamente;
2..5.4. Deve possuir a capacidade de diferenciar arquivos analisados em pelo menos três categorias: malicioso, não malicioso e arquivos não maliciosos, porém indesejáveis (PUPs, Toolbars, etc.);
2..5.5. Suportar a análise com pelo menos 100 (cem) tipos de comportamentos maliciosos para a análise da ameaça não conhecida;
2..5.6. Suportar a análise de arquivos maliciosos em ambiente controlado com, no mínimo, sistema operacional Windows XP, Windows 7 (32 bits);
2..5.7. Deve suportar a monitoração de arquivos trafegados na internet (HTTPs, FTP, HTTP, SMTP) como também arquivos trafegados internamente entre servidores de arquivos usando SMB em todos os modos de implementação: sniffer, transparente e L3;
2..5.8. A solução deve possuir a capacidade de analisar em sand-box links (http e https) presentes no corpo de e-mails trafegados em SMTP e POP3. Deve ser gerado um relatório caso a abertura do link pela sand-box o identifique como site hospedeiro de exploits;
2..5.9. Para ameaças trafegadas em protocolo SMTP e POP3, a solução deve ter a capacidade de mostrar nos relatórios o remetente, destinatário e assunto dos e-mails permitindo identificação ágil do usuário vítima do ataque;
2..5.10. O sistema de análise em núvem pública ou local deve prover informações sobre as ações do Malware na máquina infectada, informações sobre quais aplicações são utilizadas para causar/propagar a infecção, detectar aplicações não confiáveis utilizadas pelo Malware, gerar assinaturas de Antivírus e Anti- spyware automaticamente, definir URLs não confiáveis utilizadas pelo novo Malware e prover informações sobre o usuário infectado (seu endereço ip e seu login de rede);
2..5.11. Deve permitir exportar o resultado das análises de malwares de dia Zero em PDF e CSV a partir da própria interface de gerência;
2..5.12. Deve permitir o download dos malwares identificados a partir da própria interface de gerência;
2..5.13. Deve permitir visualizar os resultados da análise de malwares de dia zero nos diferentes sistemas operacionais suportados;
2..5.14. Deve permitir informar ao fabricante quanto a suspeita de ocorrências de falso-positivo e falso-negativo na análise de malwares de dia Zero a partir da própria interface de gerência;
2..5.15. Caso a solução seja fornecida em appliance local, deve possuir, no mínimo, 28 ambientes controlados (sand-box) independentes para execução simultânea de arquivos suspeitos;
2..5.16. Caso seja necessário licenças de sistemas operacional e softwares para execução de arquivos no ambiente controlado (sand-box), as mesmas devem ser fornecidas em sua totalidade, sem custos adicionais para a contratante;
2..5.17. Suportar a análise de arquivos executáveis, DLLs, ZIP e criptografados em SSL no ambiente controlado;
2..5.18. Suportar a análise de arquivos do pacote office (.doc, .docx, .xls,
.xlsx, .ppt, .pptx), arquivos java (.jar e class) e arquivos do tipo Flash no ambiente controlado;
2..5.19. Deve atualizar a base com assinaturas para bloqueio dos malwares identificados em sand-box com frequência mínima de 15 minutos
2..5.20. Permitir o envio de arquivos para análise no ambiente controlado via de forma automática via API.
2..6. FILTRO DE URL
2..6.1. A plataforma de segurança deve possuir as seguintes funcionalidades de filtro de URL:
Permite especificar política por tempo, ou seja, a definição de regras para um determinado horário ou período (dia, mês, ano, dia da semana e hora);
2..6.2. Deve ser possível a criação de políticas por Usuários, Grupos de Usuários, Ips, Redes e Grupos lógicos de Interfaces ou Zonas;
2..6.3. Deverá incluir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais URLs através da integração com serviços de diretório, autenticação via ldap, Active Directory, E-directory e base de dados local;
2..6.4. Permite popular todos os logs de URL com as informações dos usuários conforme descrito na integração com serviços de diretório;
2..6.5. Suporta a capacidade de criação de políticas baseadas no controle por URL e Categoria de URL;
2..6.6. Deve bloquear o acesso a sites de busca (Google, Bing e Yahoo), caso a opção Safe Search esteja desabilitada. Deve ainda exibir página de bloqueio fornecendo instruções ao usuário de como habilitar a função;
2..6.7. Suporta base ou cache de URLs local no appliance, evitando delay de comunicação/validação das URLs;
2..6.8. Possui pelo menos 60 categorias de URLs;
2..6.9. A categorização de URL deve analisar toda a URL e não somente até o nível de diretório;
2..6.10. Suporta a criação categorias de URLs customizadas; 2..6.11. Suporta a exclusão de URLs do bloqueio, por categoria; 2..6.12. Permite a customização de página de bloqueio;
2..6.13. Permite o bloqueio e continuação (possibilitando que o usuário acesse um site potencialmente bloqueado informando o mesmo na tela de bloqueio e possibilitando a utilização de um botão "Continuar" para permitir o usuário continuar acessando o site);
2..6.14. Suporta a inclusão nos logs do produto de informações das atividades dos usuários;
2..6.15. Deve salvar nos logs as informações dos seguintes campos do cabeçalho HTTP nos acessos a URLs: UserAgent, Referer;
2..7. IDENTIFICAÇÃO DE USUÁRIOS
2..7.1. Deve incluir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais aplicações através da integração com serviços de diretório, autenticação via ldap, Active Directory, E-directory e base de dados local;
2..7.2. Deve possuir integração com Microsoft Active Directory para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em usuários e grupos de usuários;
2..7.3. Deve possuir integração com Radius para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em usuários e grupos de usuários;
2..7.4. Deve implementar a criação de políticas de segurança baseada em atributos específicos do Radius, incluindo, mas não limitado a: baseado no sistema operacional do usuário remoto exigir autenticação padrão Windows e on-time password (OTP) para usuários Android;
2..7.5. Deve possuir integração com Ldap para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em Usuários e Grupos de usuários;
2..7.6. Deve suportar o recebimento eventos de autenticação de controladoras wireless, dispositivos 802.1x e soluções de AAA, para a identificação de endereços IP e usuários;
2..7.7. Deve permitir o controle, sem instalação de cliente de software, em equipamentos que solicitem saída a internet para que antes de iniciar a navegação, expanda-se um portal de autenticação residente no firewall (Captive Portal);
2..7.8. Suporte a autenticação Kerberos;
2..7.9. Deve suportar autenticação via Kerberos para administradores da plataforma de segurança, captive Portal e usuário de VPN SSL;
2..7.10. Deve possuir suporte a identificação de múltiplos usuários conectados em um mesmo endereço IP em ambientes Citrix e Microsoft Terminal Server, permitindo visibilidade e controle granular por usuário sobre o uso das aplicações que estão nestes serviços;
2..7.11. Deve identificar usuários através de leitura do campo x-fowarded- for, populando nos logs do firewall o endereço IP, bem como o usuário de rede responsável pelo acesso;
2..7.12. Deve permitir a criação de políticas de segurança baseadas em usuários de rede com reconhecimento dos mesmos através de leitura do campo x-fowarded-for;
2..7.13. Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;
2..7.14. Deve possuir suporte a identificação de múltiplos usuários conectados em um mesmo endereço IP em servidores acessados remotamente, mesmo que não sejam servidores Windows.
2..8. QOS
2..8.1. Com a finalidade de controlar aplicações e tráfego cujo consumo possa ser excessivo, (como youtube, ustream, etc) e ter um alto consumo de largura de banda, se requer que a solução, além de poder permitir ou negar esse tipo de aplicações, deve ter a capacidade de controlá-las por políticas de máximo de largura de banda quando forem solicitadas por diferentes usuários ou aplicações, tanto de áudio como de vídeo streaming.
2..8.2. Suportar a criação de políticas de QoS por:
Endereço de origem Endereço de destino
Por usuário e grupo do LDAP/AD.
Por aplicações, incluindo, mas não limitado a Skype, Bittorrent, YouTube e Azureus;
Por porta;
2..8.3. O QoS deve possibilitar a definição de classes por: Banda Garantida
Banda Máxima Fila de Prioridade.
2..8.4. Suportar priorização RealTime de protocolos de voz (VOIP) como H.323, SIP, SCCP, MGCP e aplicações como Skype.
2..8.5. Suportar marcação de pacotes Diffserv, inclusive por aplicação; 2..8.6. Deve implementar QOS (traffic-shapping), para pacotes
marcados por outros ativos na rede (DSCP). A priorização e limitação do tráfego deve ser efetuada nos dois sentidos da conexão (inboud e outbound);
2..8.7. Disponibilizar estatísticas RealTime para classes de QoS. 2..8.8. Deve suportar QOS (traffic-shapping), em interface agregadas;
2..8.9. Deverá permitir o monitoramento do uso que as aplicações fazem por bytes, sessões e por usuário.
2..9. FILTRO DE DADOS
2..9.1. Permite a criação de filtros para arquivos e dados pré-definidos; 2..9.2. Os arquivos devem ser identificados por extensão e assinaturas; 2..9.3. Permite identificar e opcionalmente prevenir a transferência de
vários tipos de arquivos (MS Office, PDF, etc.) identificados sobre aplicações (P2P, InstantMessaging, SMB, etc.);
2..9.4. Suportar identificação de arquivos compactados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;
2..9.5. Permitir identificar e opcionalmente prevenir a transferência de informações sensíveis, incluindo, mas não limitado a número de cartão de crédito, possibilitando a criação de novos tipos de dados via expressão regular;
2..9.6. Permitir listar o número de aplicações suportadas para controle de dados;
2..9.7. Permitir listar o número de tipos de arquivos suportados para controle de dados;
2..10. GEO-LOCALIZAÇÃO
2..10.1. Suportar a criação de políticas por Geo Localização, permitindo o trafego de determinado Pais/Países sejam bloqueados.
2..10.2. Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos.
2..10.3. Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas.
2..11. VPN
2..11.1. Suportar VPN Site-to-Site e Cliente-To-Site; 2..11.2. Suportar IPSec VPN;
2..11.3. Suportar SSL VPN;
2..11.4. A VPN IPSEc deve suportar:
3DES;
Autenticação MD5 e SHA-1;
Diffie-Hellman Group 1, Group 2, Group 5 e Group 14; Algoritmo Internet Key Exchange (IKEv1 e v2);
AES 128, 192 e 256 (Advanced Encryption Standard) Autenticação via certificado IKE PKI.
2..11.5. Deve possuir interoperabilidade com os seguintes fabricantes: Cisco;
Checkpoint; Juniper;
Palo Alto Networks; Fortinet;
Sonic Wall;
2..11.6. Deve permitir habilitar, desabilitar, reiniciar e atualizar IKE gateways e túneis de VPN IPSEc a partir da interface gráfica da solução, facilitando o processo de throubleshooting;
2..11.7. A VPN SSL deve suportar:
O usuário realizar a conexão por meio de cliente instalado no sistema operacional do equipamento ou por meio de interface WEB;
A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;
Atribuição de endereço IP nos clientes remotos de VPN SSL; 2..11.8. Deve permitir a atribuição de IPs fixos nos usuários remotos de
VPN SSL;
2..11.9. Deve permitir a criação de rotas de acesso e faixas de endereços IP atribuídas a clientes remotos de VPN de forma customizada por usuário AD/LDAP e grupo de usuário AD/LDAP;
2..11.10. Deve permitir que todo o tráfego dos usuários remotos de VPN seja escoado para dentro do túnel de VPN, impedindo comunicação direta com dispositivos locais como proxies;
2..11.11. Atribuição de DNS nos clientes remotos de VPN;
2..11.12. Deve haver a opção de ocultar o agente de VPN instalado no cliente remoto, tornando o mesmo invisível para o usuário;
2..11.13. Deve exibir mensagens de notificação customizada toda vez que um usuário remoto se conectar a VPN. Deve permitir que o usuário desabilite a exibição da mensagem nas conexões seguintes;
2..11.14. Dever permitir criar políticas de controle de aplicações, IPS, Antivírus, Antipyware e filtro de URL para tráfego dos clientes remotos conectados na VPN SSL;
2..11.15. A VPN SSL deve suportar proxy arp e uso de interfaces PPPOE; 2..11.16. Suportar autenticação via AD/LDAP, Secure id, certificado e base
de usuários local;
2..11.17. Permite estabelecer um túnel VPN client-to-site do cliente a plataforma de segurança, fornecendo uma solução de single-
2..11.18. sign-on aos usuários, integrando-se com as ferramentas de Windows-logon;
2..11.19. Suporta leitura e verificação de CRL (certificate revocation list); 2..11.20. Permite a aplicação de políticas de segurança e visibilidade para
as aplicações que circulam dentro dos túneis SSL;
2..11.21. O agente de VPN a ser instalado nos equipamentos desktop e laptops, dever ser capaz de ser distribuído de maneira automática via Microsoft SMS, Active Directory e ser descarregado diretamente desde o seu próprio portal, o qual residirá no centralizador de VPN;
2..11.22. O agente deverá comunicar-se com o portal para determinar as políticas de segurança do usuário;
2..11.23. Deve permitir que a conexão com a VPN SSL seja estabelecida das seguintes formas:
Antes do usuário autenticar na estação; Após autenticação do usuário na estação; Sob demanda do usuário;
Deverá manter uma conexão segura com o portal durante a sessão.
2..11.24. O agente de VPN SSL client-to-site deve ser compatível com pelo menos: Windows XP, Vista Windows 7, Windows 8 e Mac OSx;
2..12. CONSOLE DE GERÊNCIA E MONITORAÇÃO
2..12.1. O gerenciamento da solução deve possibilitar a coleta de estatísticas de todo o tráfego que passar pelos equipamentos da plataforma de segurança.
2..12.2. Deve permitir controle global de políticas;
2..12.3. Deve implementar a criação de perfis de usuários com acesso a plataforma de gerenciamento com definição exata de quais informações o usuário terá acesso referente a logs e relatórios;
2..12.4. Deve permitir a criação de objetos e políticas compartilhadas; 2..12.5. Deve consolidar logs e relatórios de todos os dispositivos
administrados;
2..12.6. Deve permitir que exportar backup de configuração automaticamente via agendamento;
2..12.7. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;
2..12.8. Caso haja a necessidade de instalação de cliente para administração da solução o mesmo deve ser compatível com sistemas operacionais Windows e Linux;
2..12.9. O gerenciamento deve permitir/possuir:
Criação e administração de políticas de firewall e controle de aplicação;
Criação e administração de políticas de IPS, Antivírus e Anti- Spyware;
Criação e administração de políticas de Filtro de URL; Monitoração de logs;
Ferramentas de investigação de logs; Debugging;
Captura de pacotes.
Acesso concorrente de administradores;
2..12.10. Deve possuir mecanismo busca global na solução onde possa se consultar por uma string tais como: nome de objetos, ID ou nome de ameaças, nome de aplicações, nome de políticas, endereços IPs, permitindo a localização e uso dos mesmos na configuração do dispositivo;
2..12.11. Deve possuir um mecanismo de busca por comandos no gerenciamento via SSH, facilitando a localização de comandos;
2..12.12. Deve permitir usar palavras chaves e cores para facilitar identificação de regras;
2..12.13. Deve permitir monitorar via SNMP falhas de hardware, inserção ou remoção de fontes, discos e coolers, uso de recursos por número elevado de sessões, número de túneis estabelecidos na VPN cliente-to-site, porcentagem de utilização em referência ao número total suportado/licenciado e número de sessões estabelecidas;
2..12.14. Deve suportar também o monitoramento dos seguintes recursos via SNMP: IP fragmentation, TCP state e dropped packets;
2..12.15. Bloqueio de alterações, no caso acesso simultâneo de dois ou mais administradores;
2..12.16. Definição de perfis de acesso à console com permissões granulares como: acesso de escrita, acesso de leitura, criação de usuários, alteração de configurações;
2..12.17. Autenticação integrada ao Microsoft Active Directory e servidor Radius;
2..12.18. Localização de em quais regras um endereço IP, IP Range, subnet ou objetos estão sendo utilizados;
2..12.19. Deve atribuir sequencialmente um número a cada regra de firewall, NAT, QOS e regras de DOS;
2..12.20. Criação de regras que fiquem ativas em horário definido; 2..12.21. Criação de regras com data de expiração;
2..12.22. Backup das configurações e rollback de configuração para a última configuração salva;
2..12.23. Suportar Rollback de Sistema Operacional para a última versão local;
2..12.24. Habilidade de upgrade via SCP, TFTP e interface de gerenciamento;
2..12.25. Deve possuir mecanismo de análise de impacto na política de segurança antes de atualizar a base com novas aplicações disponibilizadas pelo fabricante;
2..12.26. Validação de regras antes da aplicação;
2..12.27. Deve implementar mecanismo de validação de configurações antes da aplicação das mesmas permitindo identificar erros, tais como: rota de destino inválida, regras em shadowing etc.
2..12.28. Validação das políticas, avisando quando houver regras que, ofusquem ou conflitem com outras (shadowing);
2..12.29. Deve possibilitar a visualização e comparação de configurações Atuais, configuração anterior e configurações antigas.
2..12.30. Deve possibilitar a integração com outras soluções de SIEM de mercado (third-party SIEM vendors);
2..12.31. Geração de logs de auditoria detalhados, informando a configuração realizada, o administrador que a realizou e o horário da alteração;
2..12.32. Deverá ter a capacidade de gerar um relatório gráfico que permita visualizar as mudanças na utilização de aplicações na rede no
que se refere a um período de tempo anterior, para permitir comparar os diferentes consumos realizados pelas aplicações no tempo presente com relação ao passado;
2..12.33. Deve prover relatórios com visão correlacionada de aplicações, ameaças (IPS, Antivírus e Anti-Spware), URLs e filtro de arquivos, para melhor diagnóstico e resposta a incidentes;
2..12.34. Deve permitir a criação de Dash-Boards customizados para visibilidades do tráfego de aplicativos, usuários, categorias de URL, ameaças identificadas pelo IPS, antivírus, anti-spyware, malwares "Zero Day" detectados em sand-box e tráfego bloqueado;
2..12.35. O gerenciamento da solução deve possibilitar a coleta de estatísticas de todo o tráfego;
2..12.36. Deve possuir relatórios de utilização dos recursos por aplicações, URL, ameaças (IPS, Antivírus e Anti-Spware), etc.;
2..12.37. Prover uma visualização sumarizada de todas as aplicações, ameaças (IPS, Antivírus e Anti-Spware), e URLs que passaram pela solução;
2..12.38. Deve possuir mecanismo "Drill-Down" para navegação nos relatórios em Real Time;
2..12.39. Nas opções de "Drill-Down", ser possível identificar o usuário que fez determinado acesso;
2..12.40. Deve possuir relatório de visibilidade e uso sobre aplicativos (SaaS). O relatório também deve mostrar os riscos para a segurança do ambiente, tais como a entrega de malwares através de aplicativos SaaS com a informação do usuário responsável pelo acesso;
2..12.41. Deve ser possível exportar os logs em CSV;
2..12.42. Deverá ser possível acessar o equipamento a aplicar configurações durante momentos onde o tráfego é muito alto e a CPU e memória do equipamento estiver totalmente utilizada.
2..12.43. Rotação do log;
2..12.44. Deve permitir que os logs e relatórios sejam rotacionados automaticamente baseado no tempo em que estão armazenados na solução, assim como no espaço em disco usado;
2..12.45. Exibição das seguintes informações, de forma histórica e em tempo real (atualizado de forma automática e contínua a cada 1 minuto):
Situação do dispositivo e do cluster; Principais aplicações;
Principais aplicações por risco;
Administradores autenticados na gerência da plataforma de segurança;
Número de sessões simultâneas;
Status das interfaces; Uso de CPU;
Geração de relatórios. No mínimo os seguintes relatórios devem ser gerados: Resumo gráfico de aplicações utilizadas;
Principais aplicações por utilização de largura de banda de entrada e saída;
Principais aplicações por taxa de transferência de bytes; Principais hosts por número de ameaças identificadas; Atividades de um usuário específico e grupo de usuários do AD/LDAP, incluindo aplicações acessadas, categorias de URL, URL/tempo de utilização e ameaças (IPS, Antivírus e Anti-Spware), de rede vinculadas a este tráfego;
2..12.46. Deve permitir a criação de relatórios personalizados;
2..12.47. Em cada critério de pesquisa do log deve ser possível incluir múltiplas entradas (ex. 10 redes e IP’s distintos; serviços HTTP, HTTPS e SMTP), exceto no campo horário, onde deve ser possível definir um faixa de tempo como critério de pesquisa;
2..12.48. Gerar alertas automáticos via:
Email;
SNMP;
Syslog;
2..12.49. A plataforma de segurança deve permitir através de API-XML (Application Program Interface) a integração com sistemas existentes no ambiente da contratante de forma a possibilitar que aplicações desenvolvidas na contratante possam interagir em RealTime com a solução possibilitando assim que regras e políticas de segurança de possam ser modificadas por estas aplicações com a utilização de scripts em linguagens de programação como Perl ou PHP.
3. QUALIFICAÇÃO TÉCNICA
3..1. ATESTADO DECLARAÇÃO DO FABRICANTE
3..1.1. Após o julgamento da proposta comercial, a licitante com a proposta mais vantajosa, terá o prazo de 5(CINCO) dias úteis para apresentar atestado de comprovação.
3..1.2. Quando o Licitante não for o próprio fabricante dos equipamentos ofertados, deverá apresentar declaração do Fabricante específica para o edital, autorizando a empresa licitante a comercializar e prestar os serviços de garantia exigidos. .
3..2. ATESTADO DE CAPACIDADE TÉCNICA
3..2.1. Após o julgamento da proposta comercial, a licitante com a proposta mais vantajosa, terá o prazo de 5(CINCO) dias úteis para apresentar atestado.
3..2.2. A licitante deverá apresentar atestado de capacidade técnica compatível com o objeto do edital e abrangendo todos os serviços e tecnologias especificadas, fornecido por empresa pública ou privada que possua no mínimo 50% da quantidade solicitada.
3..3. ATESTADO DE PROFISSIONAIS
3..3.1. Após o julgamento da proposta comercial, a licitante com a proposta mais vantajosa, terá o prazo de 5(CINCO) dias úteis para apresentar atestado.
3..3.2. A licitante deverá apresentar certificação do profissional Palo Alto Networks Certified Network Security Administrator (PCNSA) ou Palo Alto Networks Certified Network Security Engineer (PCNSE).
4. PRESTAÇÃO DE SERVIÇO
4..1. A CONTRATADA deverá realizar a reunião de Kick-off no prazo máximo de até 5 (cinco) dias úteis, contados a partir da assinatura do contrato. A data da reunião deverá ser agendada em comum acordo entre a CONTRATADA e o CONTRATANTE.
4..2. Nesta reunião A CONTRATADA deverá designar um gerente de projeto responsável pela liderança técnica e administrativa do projeto, durante o projeto deverá realizar entregar de artefatos, tais como: termo de abertura de projeto, plano de projeto, declaração de escopo, RACI, cronograma, status report (semanal), reunião de acompanhamento e termo de encerramento do projeto.
4..3. A CONTRATADA responsabilizar-se integralmente pelas despesas com deslocamentos, alimentação, estada, transporte e quaisquer outras adicionais, arcando, dessa forma com todas as despesas diretas ou indiretas decorrentes do cumprimento de suas obrigações, sem qualquer ônus adicional para o CONTRATANTE.
4..4. A CONTRATADA se compromete a substituir, no xxxxx xxxxxx xx 00 (xxxxxxxx x xxxx) horas a contar da notificação do CONTRATANTE, um dos seus empregados em serviço, cuja atuação, permanência ou comportamento forem julgados prejudiciais, inconvenientes ou insatisfatórios à execução dos serviços.
4..5. A CONTRATADA se compromete a fornecimento, instalação e configuração de licenciamento e suporte de sistema de segurança de informação perimetral com implementação de Firewall de nova geração com administração de uso da largura de banda de serviço de internet (QoS/Controlador de Banda), suporte para conexões VPN IPSec e SSL, prevenção de intrusão (IPS), proteção contra ameaças de vírus e malware modernos, bem como controle de transmissão de dados e filtragem de conteúdo para acesso à internet.
4..6. A instalação deverá ser efetuada de forma a não comprometer o funcionamento dos sistemas, recursos ou equipamentos atualmente em operação no ambiente da contratante;
4..7. A empresa licitante deverá prever em sua proposta os serviços de instalação, configuração, programação, ativação, testes, treinamento na modalidade hands-on, conforme MODELO DE PROPOSTA DE PREÇO do anexo V.
4..8. Os serviços poderão ocorrer em horário comercial e, caso seja necessário permanecer após o horário de expediente, as horas extras e encargos trabalhistas serão de total responsabilidade da CONTRATADA;
4..8.1. Poderá haver necessidade de execução dos SERVIÇOS fora do horário comercial, em finais de semana e/ou em feriados, em razão manutenção programada, sem ônus para CONTRATANTE.
4..9. O contratante se reserva o direito de acompanhar e fiscalizar os serviços realizados pela contratada, verificando a aderência às especificações técnicas definidas, zelando pelo cumprimento de prazos e monitorando a qualidade dos serviços;
4..10. A CONTRATADA deverá manter o sistema operacional sempre atualizado à última versão disponível pelo fabricante pelo período de vigência do contrato, caso haja necessidade de atualização do equipamento existente para suportar as novas versões, estas deverá ser realizada sem custos adicionais a CONTRATANTE;
4..11. A instalação e o treinamento deverão ocorrer nas dependências do Sesc Pantanal localizado na Xx Xxxxxxx Xxxxxxx Xxxxxx, 000, Xxxxxx Xxxxxxxxx, Xxxxxx Xxxxxx, Xxxx Xxxxxx XX, XXX 00000-000.
4..12. SERVIÇO DE INSTALAÇÃO
4..12.1. Configuração básica de comunicação LAN e WAN 4..12.2. Instalação e ativação das licenças
4..12.2.1. URL Filtering
4..12.2.2. Threat Prevention
4..12.2.3. WildFire
4..12.3. Atualização de software da plataforma PAN-OS;
4..12.4. Atualização de data-base URL e Threat Prevention (IPS) 4..12.5. Análise do plano de configuração (security policies) fornecido
pelo cliente
4..12.6. Migração de políticas
4..12.6.1. Configuração de até novas 40 políticas para firewall de aplicação
4..12.6.2. Configuração de até novas 20 políticas para controle de acesso e conteúdo Web
4..12.6.3. Configuração de ativação do IPS para políticas criadas
4..12.6.4. Configuração de integração e identificação de usuários 4..12.7. Documentação digital
4..12.7.1. Topologia
4..12.7.2. Regras
4..13. SERVIÇO DE TREINAMENTO
4..13.1. O treinamento terá duração total de 8 horas, no formatado Hands- on.
5. CONDIÇÕES DE ENTREGA
5..1. A CONTRATADA deverá executar a instalação em até 45 (quarenta e cinco) dias corridos após o recebimento da ordem de compra.
5..2. A CONTRATADA deverá executar os serviços de capacitação, no prazo máximo de 2 (dois) dias úteis após o aceite da instalação.
5..2.1. O serviço será considerado aceito quando: 5..2.2. Entregue a licenças solicitadas.
5..2.3. Realizado serviço de instalação, documentação e treinamento. 5..2.4. Termo de encerramento do projeto.
6. CONDIÇÕES DE PAGAMENTO
6..1. Deverão estar inclusas todas as despesas relativas ao fornecimento do produto.
6..1.1. O pagamento será em feito em duas etapas:
6..1.2. Etapa 1 – O pagamento realizado após as entrega das licenças solicitadas com aceite formal do fiscal de contrato.
6..1.3. Etapa 2 – O pagamento realizado após as entrega da instalação e treinamento solicitados com aceite formal do fiscal de contrato.
7. NÍVEL DE ACORDO DE SERVIÇO
7..1. Substituir no prazo de 5 (cinco) dias, as licenças que não atendam as especificações técnicas solicitadas ou apresentem algum defeito ou avaria, sendo todos os custos inerentes a devolução e reenvio por conta da CONTRATADA.
8. PENALIDADES
8..1. Havendo inadimplemento total ou parcial na execução do objeto contratado, a CONTRATADA fica sujeita às seguintes penalidades:
8..1.1. Advertência;
8..1.2. Multa 10% do valor anual; 8..1.3. Rescisão unilateral contratual;
8..2. A penalidade de multa, será aplicada pelo CONTRATANTE da seguinte forma:
8..2.1. Pelo atraso injustificado na prestação dos serviços objeto deste contato, será aplicada multa de 2% (dois por cento) do valor total deste contrato.
8..2.2. Pela inexecução parcial deste contrato e pelo atraso injustificado na prestação dos serviços por período superior a 30 (trinta) dias, corridos ou intercalados, será aplicada multa de 5% (cinco por cento) do valor total deste contrato.
8..2.3. Pela inexecução total deste contrato será aplicada multa de 10% (dez por cento) sobre o valor total deste contrato;
8..3. Para a aplicação das penalidades previstas neste contrato será observado o devido processo legal, que assegure à CONTRATADA o direito ao contraditório e à ampla defesa.
9. VIGÊNCIA CONTRATUAL
9..1. A vigência contratual será de 12 (doze) meses.
Item | Part Number | Descrição | Valor Unitário | Valor Total |
1 | PA-3020 PAN-PA- 3020-URL4-3YR | PAN-PA-3020-URL4-3YR | R$ | R$ |
2 | PA-3020 PAN-PA- 3020-TP-3YR | Threat prevention subscription 3-year prepaid for device | R$ | R$ |
3 | PA-3020 PAN-PA- 3020-WF-3YR | WildFire subscription 3-year prepaid for device | R$ | R$ |
4 | PAN-SVC-PREM- 3020-3 | Premium support 3-year prepaid, PA-3020 WCSS | R$ | R$ |
5 | - | Serviço de implementação e treinamento hands-on | R$ | R$ |
VALOR TOTAL GLOBAL (ITENS 1 A 5) | R$ | |||
OBSERVAÇÕES:
Declaramos que estamos de acordo com os seguintes itens:
1) No preço acima estão inclusos todos os impostos, seguros, taxas, frete, transporte e quaisquer outras despesas relacionadas ao objeto da presente Licitação.
2) Esta proposta tem validade de, no mínimo, 90 (noventa) dias corridos, a contar da data da Sessão Pública do Pregão.
3) O abaixo assinado declara estar ciente de que não lhe caberá direito de exigir nenhuma multa ou indenização financeira, caso o Sesc Pantanal decida não contratá-lo.
4) Dados para depósito em conta:
Nome do banco: | Nome da agência: | N.º da agência: | N.º da conta corrente: |
..................................................,.........de. de 2016.
(assinatura/nome do representante legal da empresa)
OBSERVAÇÃO:
Este documento deverá ser preenchido preferencialmente em papel timbrado da empresa licitante e estar devidamente assinado por seu representante legal. Quando não for em papel timbrado, deverá constar o carimbo com CNPJ dessa empresa.
MODELO DE PROPOSTA DE PREÇO PREGÃO PRESENCIAL
MODELO DE TERMO DE CREDENCIAMENTO PREGÃO PRESENCIAL SESC PANTANAL
A empresa , com sede na
, C.N.P.J. nº. ,
representada pelo (a) Sr.(a) ,
CREDENCIA o(a) Sr.(a) , (CARGO),
portador(a) do R.G. nº. e C.P.F. nº. , para representá-la perante o Sesc em Minas em licitação na modalidade Pregão Presencial nº. 0125/2016, cujo objeto é a aquisição de solução de segurança e proteção de rede com características de Firewall de Próxima Geração (Next Generation Firewall), incluindo hardware, software, instalação, configuração, garantia e suporte técnico, conforme, conforme consta no edital e em seus anexos.
, de de 2016.
(assinatura do representante legal da empresa)
(nome do representante legal da empresa)