Especificação técnica

Transcrição

Diretoria de Infraestrutura de TIC - DIT
Coordenação Geral de Governança de TIC - CGGT
Coordenação de Recursos de TIC - COGR
Termo de Referência – Aquisição Sistema de Prevenção de Intrusos IPS
ANEXO I – ESPECIFICAÇÃO TÉCNICA
1. HARDWARE DO APPLIANCE
SUBITEM
FUNCIONALIDADE
1
ARQUITETURA
1.1
O equipamento deve ser baseado em Appliance Box suportando montagem em rack
(bastidor) de 19” (dezenove polegadas), com utilização de até 4-RU (Quatro unidades
de bastidor) de altura, sendo fornecido com todos os acessórios indispensáveis para
sua montagem.
1.2
O equipamento deve ser baseado em arquitetura específica e desenvolvido, tanto
software quanto hardware, para a funcionalidade única, exclusiva e específica de Next
Generation Intrusion Prevention System (NGIPS), conforme documentos do Gartner
(G00218641/G00258372), não sendo aceito:
1.2.1
Equipamentos OEM, com software de um fabricante e hardware de outro fabricante.
1.2.2
Equipamentos de uso geral, tais como: Chassi servidor (Server Chassis), Estação de
Trabalho (Desktop) e/ou Equipamento Blade.
1.2.3
Equipamentos multifuncionais (UTM – Unified Threat Management).
1.2.4
Equipamentos Next Generation Firewall (NGFW).
1.3
Os equipamentos deverão possuir armazenamento do tipo SSD (Solid State Disk), não
sendo permitido utilização de armazenamento do tipo HDD (Hard Disk Drive).
1.4
O equipamento deve suportar no mínimo 2 (duas) fontes de energia internas, para
Corrente Alternada (AC – Alternating Current), com chaveamento automático e
capacidade de operação em 100V à 240V (50/60Hz), conforme abaixo:
1.4.1
As fontes de energia devem permitir utilização de circuitos elétricos distintos.
1.4.2
As fontes de energia devem ser do tipo substituível (hot-swap), permitindo instalação
e/ou substituição sem a necessidade de remoção do equipamento.
1.4.3
As fontes de energia devem ser suficientes para manter todas as operações do
equipamento, mesmo no caso de falha de uma das fontes de energia,
independentemente da quantidade de interfaces em uso ou funcionalidades
habilitadas.
1.4.4
As fontes de energia devem vir acompanhadas com cabos de energia com 1,80m (hum
metro e oitenta centímetros) de comprimento mínimo.
1.5
O equipamento deve suportar umidade relativa e temperatura ambiente, sem
condensação, conforme abaixo:
1.5.1
1.6
PÁGINA DA
DOCUMENTAÇÃO
Em operação: 10% à 85% de umidade com 10°C à 35°C de temperatura.
O equipamento deve possuir unidades de ventilação redundantes, podendo ser do tipo
substituível (hot-swap), permitindo que fluxo de ar (exaustão) ocorra em direção a parte
Termo de Referência <informar o que se deseja adquirir>
1/11
Termo de Referência
Aquisição de Solução de Criptografia para o Backbone da Rede da Dataprev
traseira do Rack, assim, possibilitando a utilização da infraestrutura de Corredor-Frio e
Corredor-Quente implementada no Data Center da Dataprev, conforme imagem abaixo:
1.7
O equipamento deve possuir todas as interfaces (console, monitoração e gerência)
localizadas na parte frontal, assim, possibilitando quaisquer manobras de cabeamento
diretamente pelo Corredor-Frio.
1.8
O equipamento deve possuir interface serial RS-232, interface USB ou interface RJ45,
exclusiva e dedicada para acesso à console do equipamento, sendo necessário o
fornecimento do respectivo cabo compatível.
1.9
O equipamento deve permitir acesso remoto, através de SSH, à console do
equipamento.
1.10
O equipamento deve possuir 8 (interfaces) 1GigE (Gigabit Ethernet), para cabeamentos
Cobre (10Base-T, 100Base-TX ou 1000Base-T), conforme abaixo:
1.10.1
Capacidade de monitoração de até 4 (quatro) segmentos em linha.
1.10.2
Capacidade de monitoração de até 8 (oito) portas espelhadas no switch (SPAN).
1.10.3
Atendimento integral dos requerimentos do item 2 (e respectivos subitens).
1.11
O equipamento deve possuir 8 (oito) interfaces 10GigE (10-Gigabit Ethernet), para
cabeamentos Fibra Multimodo (10GBase-SR), conforme abaixo:
1.11.1
Capacidade de monitoração de até 4 (quatro) segmentos em linha.
1.11.2
Capacidade de monitoração de até 8 (oito) portas espelhadas no switch (SPAN).
1.11.3
Atendimento integral dos requerimentos do item 2 (e respectivos subitens).
1.12
O equipamento poderá ser fornecido de forma a atender aos requerimentos de
interfaces de monitoração, conforme abaixo:
1.12.1
Caso o fabricante do appliance não consiga fornecer todos os módulos de interfaces
de rede para inspeção de dados no mesmo appliance, poderá compor através de 2
(dois) equipamentos do mesmo fabricante e atendendo integral e individualmente aos
requerimentos deste documento.
1.12.2
Obrigatoriamente 1 (hum) equipamento deve possuir 8 (interfaces) 1GigE (Gigabit
ANEXO I - Termo de Referência - Aquisição Sistema de Prevenção de Intrusos IPS
2/11
Ethernet), para cabeamentos Cobre (10Base-T, 100Base-TX ou 1000Base-T), atendendo
aos requerimentos do item 1.10 (e respectivamente seus subitens).
1.12.3
Obrigatoriamente 1 (hum) equipamento deve possuir 8 (oito) interfaces 10GigE (10Gigabit Ethernet), para cabeamentos Fibra Multimodo (10GBase-SR), atendendo aos
requerimentos do item 1.11 (e respectivamente seus subitens).
1.13
O equipamento deve possuir ao menos 1 (uma) interface 1GigE (Gigabit Ethernet), para
cabeamentos Cobre (100Base-TX ou 1000Base-T), exclusiva e dedicada para gerência,
onde a interface pode ser fixa ou pode ser fornecida com o respectivo transmissorreceptor, o qual deve ser considerado no momento da elaboração da proposta.
1.14
O equipamento deverá ser fornecido com todos os respectivos cabeamentos,
transmissores-receptores e conectores necessários para operação das interfaces de
monitoração, conforme abaixo:
1.14.1
Módulos de interfaces que necessitem de seus respectivos transmissores-receptores
devem ser fornecidos integralmente, isto é, caso os módulos de interfaces excedam as
quantidades requeridas pelos itens 1.10 e 1.11 e, consequentemente, não sejam
utilizadas, devem ser fornecidas com seus respectivos transmissores-receptores,
atendendo aos requerimentos do item 2 (e respectivos subitens).
1.14.2
Cabeamentos até 150 (cento e cinquenta) metros de comprimento, onde o
comprimento adequado será especificado posteriormente no momento da aquisição.
1.15
Deve possuir configurações de CPU e memória (RAM e Flash) suficientes para a
implementação de todas as funcionalidades descritas nesta especificação.
1.16
O tempo de downtime (indisponibilidade) do bypass deverá ser no máximo de 3
segundos.
2
INTERFACES DE MONITORAÇÃO
2.1
As interfaces podem ser fixas ou podem ser fornecidas com os respectivos
transmissores-receptores, os quais devem ser considerados no momento da elaboração
da proposta.
2.2
As interfaces com fornecimento dos respectivos transmissores-receptores devem ser do
tipo substituível (hot-swap), permitindo instalação e/ou substituição sem a necessidade
de remoção do equipamento
2.3
As interfaces devem possuir, individualmente, indicadores luminosos (LED) sobre seus
estados e atividades.
2.4
As interfaces devem permitir, individualmente, configuração de seu estado tanto para
ativas quanto para inativas.
2.5
As interfaces devem permitir, individualmente, configuração em caso de falhas do
equipamento (hardware ou software) ou ausência de energia, conforme abaixo:
2.5.1
Disponibilidade (Fail-Open) dos segmentos monitorados, através de dispositivo interno
de Bypass.
2.5.2
Indisponibilidade (Fail-Close) dos segmentos monitorados.
2.6
Todas as interfaces de proteção devem possuir a funcionalidade de bypass. Este
requisito não se aplica para a interface de gerência.
2.7
O appliance deverá desativar automaticamente uma interface, caso detecte a queda de
3/11
link na outra interface de dados do mesmo segmento.
2.8
Não será aceito solução de Bypass Externo.
3
DESEMPENHO E ESCALABILIDADE
3.1
O equipamento deve suportar tráfego agregado de 20 Gbps (vinte gigabits por
segundo), sendo necessário uma análise de tráfego, consequentemente detecção de
ataques e ameaças avançadas, de no mínimo 12 Gbps (doze gigabits por segundo),
conforme abaixo:
3.1.1
≅ 30% (trinta por cento) de tráfego HTTP.
3.1.2
≅ 25% (vinte e cinco por cento) de tráfego IMAP.
3.1.3
≅ 10% (dez por cento) de tráfego HTTPS.
3.1.4
≅ 15% (quinze por cento) de tráfego PostgreSQL.
3.1.5
≅ 20% (vinte por cento) de tráfego para demais protocolos (tais como: DNS, SSH,
SNMP, NTP, FTP, etc.).
3.2
O equipamento deve inserir latência de no máximo 150 µs (cento e cinquenta
microssegundos) para tráfego nos segmentos monitorados.
3.3
O equipamento deve suportar uma taxa de no mínimo 10.000.000 (dez milhões) de
conexões concorrentes e taxa de no mínimo 180.000 (cento e oitenta mil) novas
conexões TCP por segundo.
3.4
O equipamento deve monitorar e proteger os segmentos monitorados em modo
transparente, assim como operar na camada 2 (Layer-2) do modelo OSI (Open System
Interconnection), isto é, as interfaces de monitoração não devem requerer endereços IP
e endereços MAC.
3.5
O equipamento deve suportar, de forma homogênea e heterogênea, os seguintes
modos de operação:
3.5.1
Prevenção (inline) – monitoração e proteção de segmentos de rede em ambas as
direções, permitindo monitorar e responder à ataques em tempo real, mantendo-se o
estado das conexões (Stateful).
3.5.2
Bloqueio Simulado (inline) – monitoração e simulação de proteção de segmentos de
rede em ambas as direções, permitindo monitorar e alertar os ataques em tempo real,
reportando quais ataques seriam bloqueados, mantendo-se o estado das conexões
(Stateful).
3.5.3
Monitoração (SPAN) – monitoração de segmentos de rede, permitindo monitorar e
alertar os ataques em tempo real.
3.6
4
O equipamento deve suportar captura de todos os pacotes para finalidade de
troubleshooting em formato LIBPCAP (Library for Packet Capture) – podendo ser
através de ferramenta específica (ex.: TCPDUMP) ou através de interface gráfica que
permita regras de captura – sem afetar a disponibilidade e desempenho do(s)
segmento(s)
de
rede.
DETECÇÃO DE ATAQUES
4/11
4.1
O fabricante do equipamento proposto deve possuir avaliação(ões), com no máximo 2
(dois) anos publicado (a partir de 2013) pela NSS Labs, independentemente do
equipamento avaliado, confirmando uma taxa de bloqueio de ataques (“efetividade de
segurança”) superior à 95% (noventa e cinco por cento).
4.2
O fabricante do equipamento proposto deve possuir avaliação(ões), com no máximo 2
(dois) anos publicado (a partir de 2013) pela NSS Labs, independentemente do
equipamento avaliado, confirmando imunidade à tentativas de evasão.
4.3
O equipamento deve suportar análise e decodificação de protocolos de rede, entre a
camada 2 (Layer-2) e
camada 7 (Layer-7) do modelo OSI (Open System
Interconnection), para no mínimo: ARP, BOOTP, DCCP, DHCP, DNS, EIGRP, FINGER, FTP,
HTTP, HTTPS, ICMP (versão 4 e versão 6), IMAP, IP (versão 4 e versão 6), LDAP, NetBIOS,
NFS, POP3, RADIUS, SMTP, SNMP, SSH, RPC, TCP, TELNET, TFTP e UDP.
4.4
O equipamento deve suportar identificação de ataques para protocolos de rede
independente das portas de comunicação utilizadas, para no mínimo: DNS, FTP, HTTP,
IMAP, POP3, SMTP, SNMP e RPC.
4.5
O equipamento deve suportar tanto análise Stateful Inspection, mantendo-se o estado
das sessões monitoradas, quanto Stateless Inspection.
4.6
O equipamento deve suportar análise de tráfego na direção servidor-cliente, isto é,
ataques originados externamente e direcionados à clientes e/ou usuários internos
(“Client-side Attacks” ou “Drive-by Attacks”).
4.7
O equipamento deve suportar detecção e bloqueio de ataques direcionados à
servidores de aplicação Web (Web Application), através de tecnologia heurística, isto é,
detecção heurística e bloqueio de ataques SQL Injection.
4.8
O equipamento deve suportar obtenção de informações detalhadas sobre ataques,
para no mínimo: reputação de arquivo; reputação de endereço IP; reputação de
aplicação e protocolo; e localização geográfica.
4.9
O equipamento deve suportar mecanismo de criação de perfis de dispositivos,
permitindo a descoberta de sistemas operacionais (OS fingerprinting) destes
dispositivos através da análise do tráfego de forma passiva
4.10
O equipamento deve suportar algoritmo de pontuação para relevância de um ataque,
conforme padrão de mercado e definido por entidade independente (Common
Platform Enumeration), permitindo distinguir quando um ataque for bem-sucedido ou
quando um ataque falhar.
4.11
O equipamento deve suportar análise do nível de relevância de um ataque, permitindo
uma demonstração de faixas de relevância para no mínimo 5 (cinco) níveis, podendo
ser: muito baixa, baixa, média, alta e muito alta.
4.12
O equipamento deve suportar criação de políticas de Firewall para controle de
aplicativos, possuindo no mínimo 1.000 (hum mil) identificação de aplicativos e
protocolos (App. ID), permitindo criação de regras de acesso para aplicativos comuns,
tais como: Facebook, Yahoo! Instant Messenger e Gmail.
4.13
O equipamento deve suportar categorias de ataques e tipos de ameaças, conforme
padrões de mercado e definidos por entidades independentes (Common Weakness
Enumeration e Common Attack Pattern Enumeration and Classification), para no
mínimo: CAPEC-10, CAPEC-100, CAPEC-112, CAPEC-119, CAPEC-123, CAPEC-14,
5/11
CAPEC-16, CAPEC-49, CWE-119, CWE-120, CWE-121, CWE-122, CWE-129, CWE-131,
CWE-20, CWE-200, CWE-205, CWE-227, CWE-264, CWE-307, CWE-400, CWE-436, CWE506, CWE-507, CWE-509, CWE-512, CWE-514, CWE-553, CWE-680, CWE-770, CWE-78,
CWE-805, CWE-806, CWE-88, CWE-89 e CWE-94.
4.14
O equipamentos deve suportar detecção e bloqueio de ataques do tipo Denial-ofService (DoS) e Distributed Denial-of-Service (DDoS) de forma nativa, para no mínimo:
4.14.1
Detecção e bloqueio efetivo baseado em assinaturas de ataques à vulnerabilidades
DoS, conforme padrões de mercado e definidos por entidades independentes
(Computer Emergency Response Team e Common Vulnerability and Exposures), para no
mínimo: CA-1996-26, CA-1997-28, CA-1998-13, CVE-1999-0015, CVE-1999-0016, CVE1999-0128, CVE-1999-0153, CVE-1999-0258, CVE-1999-0345, CVE-1999-0969, CVE2000-0305, CVE-2004-0230, CVE-2004-0790, CVE-2005-0688 e CVE-2005-0048.
4.14.2
Detecção e bloqueio efetivo baseado em assinaturas de atividades de agentes (zumbis)
DDoS, conforme padrões de mercado e definidos por entidades independentes
(Computer Emergency Response Team e Common Vulnerability and Exposures), para no
mínimo: CA-1999-17, CA-2000-01, CVE-2000-0138, IN-99-07, IN-2000-01 e IN-2000-05.
4.14.3
Detecção e bloqueio baseado em modo aprendizagem (Learning Mode), através de
anomalias estatísticas (Statistical Anomalies) e desequilíbrio de volume de tráfego, que
permite utilização de perfil de tráfego tanto de longo quanto de curto prazo, para
Flood (Volume) DoS Attacks, conforme padrões de mercado e definidos por entidades
independentes (Computer Emergency Response Team e Common Vulnerability and
Exposures), para no mínimo: CA-1996-21, CA-1996-01, CA-1998-01 e CVE-2002-1712.
4.14.4
Detecção e bloqueio baseados em SYN Cookie (SYN Proxy), que permita utilização de
uma “secret key” juntamente ao ISN (Initial Sequence Number) – nos pacotes de
resposta TCP (SYN+ACK) às requisições de conexão TCP (SYN) – como parte integrante
do processo de “3-way handshake”.
4.14.5
Detecção e bloqueio baseados em políticas de Firewall, para no mínimo:
4.14.5.1
Filtros de origem e destino por: país, nome (DNS), endereço IP, bloco de endereços,
rede ou grupo de redes.
4.14.5.2
VlanID, para no mínimo 250 Vlans.
4.14.5.3
Filtros de aplicação: aplicação, grupo de aplicações, porta de comunicação
customizada, serviço ou grupo de serviços.
4.14.5.4
Filtro de resposta: bloqueio (drop), negação (deny) e ignorar.
4.14.6
Detecção e bloqueio baseados limite de conexões, que permite definição de valores
“threshold” para limitar o número de conexões que podem ser estabelecidas de/para
uma máquina.
4.14.7
Detecção e bloqueio baseados em proteção de servidores DNS (Domain Name Service)
contra ataques – com ou sem a presença de endereços IP forjados (IP Spoofing) – e que
permita utilizar-se apenas do protocolo TCP para resolução de nomes (name
lookup/resolve), não permitindo a utilização do protocolo UDP para esta finalidade.
4.15
O equipamento deve suportar detecção e bloqueio de tráfego de aplicações Instant
Messenger e P2P (Peer-to-Peer), para no mínimo: AOL Instant Messenger, Ares,
6/11
Azureus, Bearshare, Bittorrent, Blubster, DirectConnect, eDonkey, eMule, Enppy, ICQ,
FileNara, Gnucleus, Gnutella, Grokster, Groove, JAP Anonymizer, Kazaa, Limewire,
Morpheus, MSN Messenger, Mutella, MyNapster, Mxie, OpenLITO, Overnet, Phex, Piolet,
RockItNet, Shareaza, Skype, SoulSeek, Swapper, Xolox, WinMX e Yahoo! Messenger.
4.16
O equipamento deve suportar detecção e bloqueio de ataques através de túneis para
no mínimo: IPv4-in-IPv4, IPv4-in-IPv6 e IPv6-in-IPv6.
4.17
O equipamento deve suportar análise em segmentos monitorados com tráfego
encapsulados, para no mínimo: GRE (Generic Routing Encapsulation), IEEE 802.1Q, IEEE
802.1Q-in-Q, Jumbo Frames e MPLS (Multi Protocol Label Switching).
4.18
O equipamento deve ser transparente – isto é, sem causar qualquer interrupção ou
alteração nestes protocolos – em segmentos monitorados com protocolos de
roteamento e redundância de rotas, para no mínimo: OSPF, BGP, VRRP e HSRP.
4.19
O equipamento deve suportar análise e deve ser transparente – isto é, sem causar
qualquer interrupção ou alteração nestes protocolos – em segmentos monitorados com
protocolo LACP (Link Aggregation Control Protocol).
4.20
Deve permitir a criação de novas assinaturas ou alteração de parâmetros das
assinaturas já existentes.
5
DETECÇÃO DE AMEAÇAS (MALWARES) AVANÇADAS
5.1
O equipamento deve suportar tecnologias de detecção e bloqueio de códigos
maliciosos, ameaças malwares (incluindo avançados) em tempo-real, para no mínimo:
5.1.1
Mecanismo de lista local de arquivos confiáveis (lista branca), os quais não precisarão
ser analisados por serem notoriamente confiáveis.
5.1.2
Mecanismo de lista com valores “Hash” de arquivos que sejam códigos maliciosos e
ameaças (malwares) conhecidas e armazenado em uma base de dados local (lista
negra).
5.1.3
Mecanismo de detecção de códigos maliciosos e ameaças (malwares), que deve operar
em tempo-real e permitindo o uso de reputação de arquivos.
5.1.4
Mecanismo de detecção de códigos malicioso e ameaças (malwares) em no mínimo os
seguintes tipos de arquivos:
5.1.4.1
Capacidade de análise de arquivos PDF.
5.1.4.2
Capacidade de análise de arquivos PDF, mesmo quando criptografados.
5.1.4.3
Suporte a objetos e arquivos Flash arquivos Executáveis e arquivos Microsoft Office.
5.2
O equipamento deve suportar tecnologia de detecção e bloqueio de códigos
maliciosos e ameaças (malwares) baseada em mecanismo de análise que inclua técnicas
Machine Learning, Assinatura e reputação de arquivos em tempo-real.
6
RESPOSTAS À ATAQUES
6.1
O equipamento deve suportar TCP Reset.
6.2
O equipamento deve suportar bloqueio (Drop) de pacotes.
6.3
O equipamento deve suportar aplicação, extensão e remoção de quarentena (IPS
Quarantine) sob demanda.
7/11
6.4
O equipamento deve suportar configuração e atualização global de bloqueio para um
ataque, propagando esta configuração e atualização em todas as políticas.
6.5
O equipamento deve suportar captura de pacotes para análise de evidências em
formato LIBPCAP (Library for Packet Capture).
6.6
O equipamento deve suportar envio de SNMP Trap para as versões:
6.6.1
SNMPv2c.
6.6.2
SNMPv3.
6.7
O equipamento deve suportar envio de e-mail.
7
DECRIPTOGRAFIA DE TRÁFEGO SSL
7.1
O equipamento deve suportar análise de tráfego criptografado de no mínimo 1.2 Gbps
ou 1200 Mbps (Mil e duzentos megabits por segundo), atendendo aos requerimentos
do item 3.1 (e respectivamente seus subitens).
7.2
O equipamento deve suportar análise de tráfego criptografado HTTPS (Hyper Transfer
Protocol Secure), não sendo permitido utilização de equipamento externo, conforme
abaixo:
7.2.1
Análise de conexões seguras que utilizem-se de SSL (Secure Sockets Layer) e TLS
(Transport Layer Security), para no mínimo: SSL versão 2, SSL versão 3, TLS versão 1.0,
TLS versão 1.1 e TLS versão 1.2.
7.2.2
Análise de tráfego para comunicação(ões) “inbound” estabelecida(s) com servidores
WEB, para no mínimo: Microsoft Internet Information Server (IIS), Apache e IBM
WebSphere.
7.3
O equipamento deve permitir importação de no mínimo 60 (sessenta) certificados em
formato PKCS #12 (extensões ".pkcs12", ".p12" ou ".pfx"), com chave(s) privada(s) RSA
de 1024-bit e 2048-bit.
7.4
O equipamento deve suportar algoritmos de chaves simétricas, para no mínimo: RC4
(Rivest Cipher 4), DES (Data Encryption Standard), 3DES (Triple Data Encryption
Standard) e AES (Advanced Encryption Standard).
7.5
O equipamento deve suportar funções de “hashing”, para no mínimo: MD5 (MessageDigest Algorithm 5) e SHA-1 (Secure Hash Algorithm 1).
8
GERENCIAMENTO DA SOLUÇÃO
8.1
A solução de gerência deve permitir gerenciamento centralizado do(s) equipamento(s)
NGIPS.
8.2
A solução de gerência deve ser baseada em Appliance Box suportando montagem em
rack (bastidor) de 19” (dezenove polegadas), com utilização de 1-RU (uma unidade de
bastidor) de altura.
8.3
A solução de gerência deve ser fornecida, tanto software quanto hardware, para a
funcionalidade única, exclusiva e específica de gerenciamento do(s) equipamento(s)
NGIPS, não sendo permitido que o(s) equipamento(s) NGIPS operem como solução de
gerência.
8.4
A solução de gerência deve suportar no mínimo 2 (duas) fontes de energia internas
8/11
para Corrente Alternada (AC – Alternating Current), com chaveamento automático e
capacidade de operação em 100V à 240V (50/60Hz).
8.5
A solução de gerência deve possuir capacidade de armazenamento do tipo redundante
(RAID – Redundant Array of Independent Drives), atendendo aos requerimentos do
item 8.18.
8.6
A solução de gerência deve possuir ao menos 1 (uma) interface 1GigE (Gigabit
Ethernet), para cabeamentos Cobre (100Base-TX ou 1000Base-T), onde a interface pode
ser fixa ou pode ser fornecida com o respectivo transmissor-receptor, o qual deve ser
considerado no momento da elaboração da proposta.
8.7
A solução de gerência deve considerar uma instalação em alta disponibilidade no modo
ativo/passivo, onde:
8.7.1
Uma das gerências deve ser primária (ativa).
8.7.2
Uma das gerências deve ser secundária (passiva).
8.7.3
Em caso de falha da gerência primária (ativa), automaticamente a secundária (passiva)
deve assumir o gerenciamento centralizado do(s) equipamento(s) NGIPS.
8.7.4
As configurações devem ser sincronizadas em tempo real entre a gerência primária
(ativa) e a gerência secundário (passiva).
8.8
A solução de gerência deve possuir políticas baseadas em assinaturas recomendadas
pelo fabricante para bloqueio, as quais são baseadas nas recomendações provenientes
de equipe de pesquisa do fabricante.
8.9
A solução de gerência deve suportar atualização de software e firmware do(s)
equipamento(s) NGIPS, de forma remota e centralizada, conforme abaixo:
8.9.1
Online: automática e/ou manual de conteúdo de segurança e produto através da
Internet, podendo ser realizada sem interferência do usuário.
8.9.2
Offline: automática e/ou manual de conteúdo de segurança e produto através de
pacotes de atualização importados pela gerência, sem conexão com a Internet.
8.10
A solução de gerência deve suportar aplicação de políticas, regras, de forma remota e
centralizada, sem afetar a detecção e bloqueio, isto é, o(s) equipamento(s) NGIPS
gerenciado(s) não perderá(ão) capacidade de detecção e bloqueio durante o processo
de aplicação de políticas e regras.
8.11
A solução de gerência deve suportar comunicação criptografada com o(s)
equipamento(s) NGIPS.
8.12
A solução de gerência deve permitir envio de registros de eventos através de
integração com servidor SYSLOGD.
8.13
A solução de gerência deve suportar integração, através de SNMPv2c ou SNMPv3, com
solução de Sistema de Gerenciamento de Rede (NMS – Network Management System),
onde deve ser fornecido o(s) respectivo(s) arquivo(s) MIB.
8.14
A solução de gerência deve permitir sincronismo de horário do(s) equipamento(s)
NGIPS através de integração com servidor NTP (Network Time Protocol).
8.15
A solução de gerência deve suportar operação e armazenamento com Sistema
Gerenciador de Banco de Dados Relacional (SGBDR – Relational Database Management
System ou RDBMS) que utilize linguagem de pesquisa declarativa SQL (Structured
9/11
Query Language).
8.16
A solução de gerência deve suportar arquivamento (backup) dos eventos gerados
pelo(s) equipamento(s) NGIPS, conforme abaixo:
8.16.1
Manual: arquivamento (backup) dos eventos sob-demanda, sendo realizado de forma
manual pelo administrador.
8.16.2
Automático: arquivamento (backup) dos eventos de forma agendada e automática,
sendo previamente configurado pelo administrador.
8.17
A solução de gerência deve permitir tarefas tanto de arquivamento (backup) quanto de
restauração (restore) de sua base de dados.
8.18
A solução de gerência deve ser capaz de armazenar 30.000.000 (trinta milhões) de
eventos em Sistema Gerenciador de Banco de Dados Relacional (SGBDR – Relational
Database Management System ou RDBMS), permitindo uma retenção de até 6 (seis)
meses.
8.19
A solução de gerência deve suportar administração, configuração e manutenção de
contas de acesso de usuários e administradores através de autenticação:
8.19.1
LOCAL: usuários e administradores cadastrados na gerência, permitindo definir políticas
de composição de senhas.
8.19.2
LDAP: usuários e administradores importados e integrados com o Windows AD (Active
Directory).
8.19.3
RADIUS: usuários e administradores importados e integrados com servidor RADIUS.
8.20
A solução de gerência deve suportar atribuição de perfis para usuário e
administradores, para no mínimo:
8.20.1
Administrador.
8.20.2
Super usuário.
8.20.3
Perfil nulo.
8.21
A solução de gerência deve permitir monitoração dos recursos alocados do(s)
equipamento(s) NGIPS, para no mínimo:
8.21.1
Utilização de processamento do(s) equipamento(s) NGIPS.
8.21.2
Taxa de transferência do(s) equipamento(s) NGIPS.
8.21.3
Taxa de transferência da(s) interface(s) do(s) equipamento(s) NGIPS.
8.22
A solução de gerência deve suportar notificação de falhas de sistema, permitindo envio
de informação sobre falha de sistema, conforme abaixo:
8.22.1
Através de integração com servidor SYSLOGD.
8.22.2
Através de integração com servidor SNMP.
8.23
A solução de gerência deve possuir capacidade de geração de relatórios, não sendo
permitido utilização de solução de terceiros ou externa.
8.24
A solução de gerência deve ser capaz de gerar relatórios, de forma remota e
centralizada, para os eventos e alertas do(s) equipamento(s) NGIPS, conforme abaixo:
10/11
8.24.1
Manual: geração de relatórios sob-demanda, sendo realizada de forma manual pelo
administrador.
8.24.2
Automático: geração de relatórios de forma agendada e automática, sendo
previamente configurada pelo administrador.
8.25
A solução de gerência deve permitir exportar relatórios para arquivos HTML e PDF.
8.26
A solução de gerência deve possuir relatórios pré-definidos, para no mínimo:
8.26.1
Resumo executivo.
8.26.2
Resumo de reputação da origem do ataque.
8.26.3
Resumo de reputação do destino do ataque.
8.26.4
Ataques de reconhecimento.
8.26.5
Análise de tendências.
8.26.6
Os 10 (dez) ataques mais detectados.
8.26.7
As 10 (dez) ameaças (malwares) mais detectados.
8.26.8
As 10 (dez) origens que mais atacaram.
8.26.9
Os 10 (dez) destinos que mais foram atacados.
8.27
A solução de gerência deve permitir customização e criação de relatórios sob-demanda,
permitindo utilização de filtros específicos, para no mínimo:
8.27.1
Endereço IP de origem.
8.27.2
Endereço IP de destino.
8.27.3
País de origem.
8.27.4
País de destino.
8.27.5
Identificação do usuário de origem.
8.27.6
Identificação do usuário de destino.
8.27.7
Nome do ataque.
11/11

Especificação técnica

Transcrição

Documentos relacionados

s@ber [email protected] tic

A Sociedade do Conhecimento e as "Neuroses de Informação"

Educação Infantil

Resumo da Tese de Mestrado

O uso das Tecnologias no Ensino Superior

CP-RX80_SPA:Layout 1

AB INFARTO AGUDO DO MIOCÁRDIO CAUSADO POR

RECIFE 2015 Internacionalização do ensino básico na agenda do

tecnologias de informação e comunicação (tic) na américa latina e

As tecnologias de informação e comunicação como fator de

Memorial - Prefeitura de Vacaria RS