PREGÃO ELETRÔNICO PARA REGISTRO DE PREÇO Nº 100/2016 PROCESSO Nº. 23122.022278/2016-22

PREGÃO ELETRÔNICO PARA REGISTRO DE PREÇO Nº 100/2016 PROCESSO Nº. 23122.022278/2016-22

UNIVERSIDADE FEDERAL DE SÃO JOÃO DEL-REI/UFSJ

A Universidade Federal de São João Del-Rei - UFSJ, situada à Xxxxx Xxxx Xxxxxxx, 000, Xxxxxx Xxxxx Xxxxxxx, na cidade de São João del-Rei/MG – XXX 00.000-000, por intermédio do Pregoeiro designado pela Portaria nº 401 de 06 de junho de 2016, torna público para conhecimento dos interessados que na data, horário e local abaixo indicado fará realizar licitação PARA REGISTRO DE PREÇO, na modalidade PREGÃO, na forma ELETRÔNICA, do tipo MENOR PREÇO POR GRUPO, conforme descritos neste Edital, seus Anexos e condições que se enunciam.

FUNDAMENTAÇÃO: O presente certame licitatório reger-se-á pelas disposições da Lei

nº 10.520, de 17 de julho de 2002, pela Lei Complementar nº. 123, de 14 de dezembro de 2006, pelo Decreto nº 5.450, de 31 de maio de 2005, pelo Decreto n° 8.538, de 06 de outubro de 2015, pela Lei nº 8.248, de 23 de outubro de 1991, pelo Decreto

nº 5.906, de 26 de setembro de 2006, pelo Decreto nº 7.174, de 12 de maio de 2010, pelo pelo Decreto nº 8.184, de 17 de janeiro de 2014, pelo Decreto nº 8.194, de 12 de fevereiro de 2014, da Instrução Normativa SLTI/MPOG nº 2, de 11 de outubro de 2010, pela Lei nº 11.488, de 15 de junho de 2007, pelo Decreto nº 7.892, de 23 de janeiro de 2013 aplicando-se, subsidiariamente, a Lei no 8.666, de 21 de junho de 1993, e demais legislações pertinentes e, ainda, pelo estabelecido no presente Edital e seus Anexos.

O Edital está disponibilizado, na íntegra, nos endereços eletrônicos xxxx://xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx e xxxx://xxx.xxxx.xxx.xx/xxxxx, e também poderão ser lidos e/ou obtidos no endereço Xxxxx Xxxx Xxxxxxx, 000, xxxxxx Xxxxxx, cidade de São João del- Rei/MG, nos dias úteis, no horário das 08:30 às 12:00 e 13:30 às 17:00, mesmo endereço e período no qual os autos do processo administrativo permanecerão com vista franqueada aos interessados.

Integram este Edital, para todos os fins e efeitos, os seguintes anexos:

ANEXO I - TERMO DE REFERÊNCIA

ANEXO II – ATA DE REGISTRO DE PREÇOS

ANEXO II – DECLARAÇÃO PARA EMPRESAS OPTANTES PELO SIMPLES

DATA E HORÁRIO DA ABERTURA DA SESSÃO PÚBLICA: dia 26/12/2016, às 14 horas.

UASG: 154069

LOCAL: Portal Comprasnet - xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx

1 - DO OBJETO

1.1 - O objeto da presente licitação é o registro de preço para aquisição de solução de segurança global (firewall) para atendimento aos seis campi da Universidade Federal de São João del-Rei, conforme condições, quantidades e exigências estabelecidas neste Edital e seus anexos.

1.2 - A licitação será dividida em grupo único, formados por todos os itens, conforme tabela constante no Termo de Referência.

2 - DO ÓRGÃO GERENCIADOR E ÓRGÃOS PARTICIPANTES

2.1 - O órgão gerenciador será a Universidade Federal de São João del-Rei

3 - DA ADESÃO À ATA DE REGISTRO DE PREÇOS

3.1 - A ata de registro de preços, durante sua validade, poderá ser utilizada por qualquer órgão ou entidade da administração pública que não tenha participado do certame licitatório, mediante anuência do órgão gerenciador, desde que devidamente justificada a vantagem e respeitadas, no que couber, as condições e as regras estabelecidas na Lei nº 8.666, de 1993 e no Decreto nº 7.892, de 2013.

3.2 - Caberá ao fornecedor beneficiário da Ata de Registro de Preços, observadas as condições nela estabelecidas, optar pela aceitação ou não do fornecimento, desde que este fornecimento não prejudique as obrigações anteriormente assumidas com o órgão gerenciador e órgãos participantes.

3.3 - As aquisições ou contratações adicionais a que se refere este item não poderão exceder, por órgão ou entidade, a cem por cento dos quantitativos dos itens do instrumento convocatório e registrados na ata de registro de preços para o órgão gerenciador e órgãos participantes.

3.4 - As adesões à ata de registro de preços são limitadas, na totalidade, ao quíntuplo do quantitativo de cada item registrado na ata de registro de preços para o órgão gerenciador e órgãos participantes, independente do número de órgãos não participantes que eventualmente aderirem.

3.5 - Ao órgão não participante que aderir à ata competem os atos relativos à cobrança do cumprimento pelo fornecedor das obrigações contratualmente assumidas e a aplicação, observada a ampla defesa e o contraditório, de eventuais penalidades decorrentes do descumprimento de cláusulas contratuais, em relação as suas próprias contratações, informando as ocorrências ao órgão gerenciador.

3.6 - Após a autorização do órgão gerenciador, o órgão não participante deverá efetivar a contratação solicitada em até noventa dias, observado o prazo de validade da Ata de Registro de Preços.

3.6.1 - Caberá ao órgão gerenciador autorizar, excepcional e justificadamente, a prorrogação do prazo para efetivação da contratação, respeitado o prazo de vigência da ata, desde que solicitada pelo órgão não participante.

4 - DO CREDENCIAMENTO

4.1 - O Credenciamento é o nível básico do registro cadastral no SICAF, que permite a participação dos interessados na modalidade licitatória Pregão, em sua forma eletrônica.

4.2 - O cadastro no SICAF poderá ser iniciado no Portal de Compras do Governo Federal – Comprasnet, no sítio xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx, com a solicitação de login e senha pelo interessado.

4.3 - O credenciamento junto ao provedor do sistema implica na responsabilidade do licitante ou de seu representante legal e a presunção de sua capacidade técnica para realização das transações inerentes a este Pregão.

4.4 - O uso da senha de acesso pela licitante é de sua responsabilidade exclusiva, incluindo qualquer transação efetuada diretamente ou por seu representante, não cabendo ao provedor do sistema ou a UFSJ, responsabilidade por eventuais danos decorrentes do uso indevido da senha, ainda que por terceiros.

4.5 - A perda da senha ou a quebra de sigilo deverão ser comunicadas imediatamente ao provedor do sistema para imediato bloqueio de acesso.

5 - DA PARTICIPAÇÃO NO PREGÃO

5.1 - Poderão participar deste Pregão interessados cujo ramo de atividade seja compatível com o objeto desta licitação, e que estejam com Credenciamento regular no Sistema de Cadastramento Unificado de Fornecedores – SICAF, conforme disposto no §3º do artigo 8º da Instrução Normativa SLTI/MPOG nº 2, de 11.10.10.

5.2 - Será concedido tratamento favorecido para as microempresas e empresas de pequeno porte, para as sociedades cooperativas mencionadas no artigo 34 da Lei nº 11.488, de 2007, para o agricultor familiar, o produtor rural pessoa física e para o microempreendedor individual - MEI, nos limites previstos da Lei Complementar nº 123, de 2006.

5.3 - Não poderão participar desta licitação os interessados:

5.3.1 - proibidos de participar de licitações e celebrar contratos administrativos, na forma da legislação vigente;

5.3.2 - estrangeiros que não tenham representação legal no Brasil com poderes expressos para receber citação e responder administrativa ou judicialmente;

5.3.3 - que se enquadrem nas vedações previstas no artigo 9º da Lei nº 8.666, de 1993;

5.3.4 - que estejam sob falência, em recuperação judicial ou extrajudicial, concurso de credores, concordata ou insolvência, em processo de dissolução ou liquidação;

5.3.5 - entidades empresariais que estejam reunidas em consórcio;

5.3.6 - que possuem servidor ou dirigente de órgão ou da UFSJ ou os responsáveis pela licitação;

5.3.7 - o autor do projeto, básico ou executivo, pessoa física ou jurídica;

5.3.8 - que estejam inadimplentes, suspensas de licitar ou contratar com a UFSJ;

5.4 - Como condição para participação no Pregão, a licitante assinalará “sim” ou “não” em campo próprio do sistema eletrônico, relativo às seguintes declarações:

5.4.1 - que cumpre os requisitos estabelecidos no artigo 3° da Lei Complementar nº 123, de 2006, estando apta a usufruir do tratamento favorecido estabelecido em seus arts. 42 a 49;

5.4.1.1 - a assinalação do campo “não” apenas produzirá o efeito de a licitante não ter direito ao tratamento favorecido previsto na Lei Complementar nº 123, de 2006, mesmo que seja qualificada como microempresa ou empresa de pequeno porte;

5.4.2 - que está ciente e concorda com as condições contidas no Edital e seus anexos, bem como de que cumpre plenamente os requisitos de habilitação definidos no Edital;

5.4.3 - que inexistem fatos impeditivos para sua habilitação no certame, ciente da obrigatoriedade de declarar ocorrências posteriores;

5.4.4 - que não emprega menor de 18 anos em trabalho noturno, perigoso ou insalubre e não emprega menor de 16 anos, salvo menor, a partir de 14 anos, na condição de aprendiz, nos termos do artigo 7°, XXXIII, da Constituição;

5.4.5 - que a proposta foi elaborada de forma independente, nos termos da Instrução Normativa SLTI/MPOG nº 2, de 16 de setembro de 2009.

5.5 - Será assegurada preferência na contratação, nos termos do disposto no art. 3º da Lei nº 8.248, de 1991, nas aquisições de bens e serviços de informática e automação, observada a seguinte ordem:

5.5.1 - bens e serviços com tecnologia desenvolvida no País e produzidos de acordo com o Processo Produtivo Básico (PPB), na forma definida pelo Poder Executivo Federal;

5.5.2 - bens e serviços com tecnologia desenvolvida no País; e

5.5.3 - bens e serviços produzidos de acordo com o PPB, na forma definida pelo Poder Executivo Federal.

5.5.4 - As microempresas e empresas de pequeno porte que atendam ao disposto nos itens 5.5.1, 5.5.2 e 5.5.3 terão prioridade no exercício do direito de preferência em relação às médias e grandes empresas enquadradas no mesmo inciso e os itens com valores abaixo de R$80.000,00.

5.6 - A comprovação do atendimento ao PPB dos bens de informática e automação ofertados será feita mediante apresentação do documento comprobatório da habilitação à fruição dos incentivos fiscais regulamentados pelo Decreto no 5.906, de 26 de setembro de 2006, ou pelo Decreto no 6.008, de 29 de dezembro de 2006.

6 - DO ENVIO DA PROPOSTA

6.1 - O licitante deverá encaminhar a proposta por meio do sistema eletrônico até a data e horário marcados para abertura da sessão, quando, então, encerrar-se-á automaticamente a fase de recebimento de propostas.

6.1.1 - Todas as referências de tempo no Edital, no aviso e durante a sessão pública observarão o horário de Brasília – DF.

6.2 - O licitante será responsável por todas as transações que forem efetuadas em seu nome no sistema eletrônico, assumindo como firmes e verdadeiras suas propostas e lances.

6.3 - Incumbirá ao licitante acompanhar as operações no sistema eletrônico durante a sessão pública do Pregão, ficando responsável pelo ônus decorrente da perda de negócios, diante da inobservância de quaisquer mensagens emitidas pelo sistema ou de sua desconexão.

6.4 - Até a abertura da sessão, os licitantes poderão retirar ou substituir as propostas apresentadas.

6.5 - O licitante deverá enviar sua proposta mediante o preenchimento, no sistema eletrônico, dos seguintes campos:

6.5.1 - Valor unitário do item;

6.5.2 - Marca;

6.5.3 - Fabricante;

6.5.4 - Descrição detalhada do objeto: indicando, no que for aplicável, o modelo, prazo de validade ou de garantia, número do registro ou inscrição do bem no órgão competente, quando for o caso;

6.5.5 - A quantidade de unidades, observada a quantidade mínima fixada no Termo de Referência para cada item;

6.5.5.1 - Em não havendo quantidade mínima fixada, deverá ser cotada a quantidade total prevista para o item.

6.5.6 - Todas as especificações do objeto contidas na proposta vinculam a Contratada.

6.6 - O prazo de validade da proposta não será inferior a 60 (sessenta) dias, a contar da data de sua apresentação.

6.7 - O licitante deverá declarar, para cada item, em campo próprio do sistema COMPRASNET, se o produto ofertado é manufaturado nacional beneficiado por um dos critérios de margem de preferência indicados no Termo de Referência.

6.8 - Deverá consignar expressamente o valor total do item, estando incluídas todas as despesas, encargos previdenciários, trabalhistas, comerciais e quaisquer outros que incidam direta ou indiretamente no fornecimento dos bens sociais objeto deste Pregão Eletrônico. Nenhuma reivindicação adicional de pagamento ou reajustamento de preços será considerada.

6.8.1 - Deverá limitar-se ao objeto desta licitação, sendo desconsideradas quaisquer alternativas de preço ou qualquer outra condição não prevista neste Edital.

6.8.2 - O valor deverá ser apresentado em moeda corrente nacional, sendo os centavos com apenas duas casas decimais. Não serão considerados, para efeito de empenhamento, valores cujo preço contenha mais de duas casas decimais, sendo desconsideradas as frações de centavos. Ex: 0,0123, será empenhado 0,01.

6.9 - A apresentação da proposta implica plena aceitação, por parte do licitante, das condições estabelecidas neste Edital e seus Anexos.

7 - DAS PROPOSTAS E FORMULAÇÃO DE LANCES

7.1 - A abertura da presente licitação dar-se-á em sessão pública, por meio de sistema eletrônico, na data, horário e local indicados neste Edital.

7.2 - O Pregoeiro verificará as propostas apresentadas, desclassificando desde logo aquelas que não estejam em conformidade com os requisitos estabelecidos neste Edital, contenham vícios insanáveis ou não apresentem as especificações técnicas exigidas no Termo de Referência.

7.2.1 - A desclassificação será sempre fundamentada e registrada no sistema, com acompanhamento em tempo real por todos os participantes.

7.2.2 - A não desclassificação da proposta não impede o seu julgamento definitivo em sentido contrário, levado a efeito na fase de aceitação.

7.3 - O sistema ordenará automaticamente as propostas classificadas, sendo que somente estas participarão da fase de lances.

7.4 - O sistema disponibilizará campo próprio para troca de mensagens entre o Pregoeiro e os licitantes.

7.5 - Iniciada a etapa competitiva, os licitantes deverão encaminhar lances exclusivamente por meio do sistema eletrônico, sendo imediatamente informados do seu recebimento e do valor consignado no registro.

7.5.1 - O lance deverá ser ofertado pelo valor unitário do item.

7.6 - Os licitantes poderão oferecer lances sucessivos, observando o horário fixado para abertura da sessão e as regras estabelecidas no Edital.

7.7 - O licitante somente poderá oferecer lance inferior ao último por ele ofertado e registrado pelo sistema.

7.7.1 - O intervalo entre os lances enviados pelo mesmo licitante não poderá ser inferior a vinte (20) segundos e o intervalo entre lances não poderá ser inferior a três (3) segundos.

7.8 - Não serão aceitos dois ou mais lances de mesmo valor, prevalecendo aquele que for recebido e registrado em primeiro lugar.

7.9 - Durante o transcurso da sessão pública, os licitantes serão informados, em tempo real, do valor do menor lance registrado, vedada a identificação do licitante.

7.10 - No caso de desconexão com o Pregoeiro, no decorrer da etapa competitiva do Pregão, o sistema eletrônico poderá permanecer acessível aos licitantes para a recepção dos lances.

7.11 - Se a desconexão perdurar por tempo superior a 10 (dez) minutos, a sessão será suspensa e terá reinício somente após comunicação expressa do Pregoeiro aos participantes.

7.12 - A etapa de lances da sessão pública será encerrada por decisão do Pregoeiro. O sistema eletrônico encaminhará aviso de fechamento iminente dos lances, após o que transcorrerá período de tempo de até 30 (trinta) minutos, aleatoriamente determinado pelo sistema, findo o qual será automaticamente encerrada a recepção de lances.

7.13 - Caso o licitante não apresente lances, concorrerá com o valor de sua proposta e, na hipótese de desistência de apresentar outros lances, valerá o último lance por ele ofertado, para efeito de ordenação das propostas.

7.14 - Encerrada a etapa de lances será efetivada a verificação automática, junto à Receita Federal, do porte da entidade empresarial. O sistema identificará em coluna própria as licitantes qualificadas como microempresas ou empresas de pequeno porte, procedendo à comparação com os valores da primeira colocada, se esta for empresa de maior porte, assim como das demais classificadas, para o fim de aplicar-se o disposto nos arts. 44 e 45 da LC nº 123, de 2006, regulamentado pelo Decreto nº 8.538, de 2015.

7.15 - Caso a melhor oferta válida tenha sido apresentada por empresa de maior porte, as propostas de licitantes qualificadas como microempresas ou empresas de pequeno porte que se encontrarem na faixa de até 5% (cinco por cento) acima da proposta ou lance de menor preço serão consideradas empatadas com a primeira colocada.

7.16 - A melhor classificada nos termos do item anterior terá o direito de encaminhar uma última oferta para desempate, obrigatoriamente em valor inferior ao da primeira colocada, no prazo de 5 (cinco) minutos controlados pelo sistema, contados após a comunicação automática para tanto.

7.17 - Caso a licitante qualificada como microempresa ou empresa de pequeno porte melhor classificada desista ou não se manifeste no prazo estabelecido, serão convocadas as demais licitantes qualificadas como microempresa ou empresa de pequeno porte que se encontrem naquele intervalo de 5% (cinco por cento), na ordem de classificação, para o exercício do mesmo direito, no prazo estabelecido no subitem anterior.

7.17.1 - Quando houver propostas beneficiadas com as margens de preferência em relação ao produto estrangeiro, o critério de desempate será aplicado exclusivamente entre as propostas que fizerem jus às margens de preferência, conforme regulamento.

7.17.2 - Ao presente certame não se aplica o sorteio como critério de desempate. Lances equivalentes não serão considerados iguais, vez que a ordem de apresentação das propostas pelos licitantes é utilizada como um dos critérios de classificação.

7.18 - Para a aquisição de bens comuns de informática e automação, definidos no art. 16-A da Lei n° 8.248, de 1991, será assegurado o direito de preferência previsto no seu artigo 3º, conforme procedimento estabelecido nos artigos 5° e 8° do Decreto n° 7.174, de 2010.

7.18.1 - Nas contratações de bens e serviços de informática e automação, nos termos da Lei nº 8.248, de 1991, as licitantes qualificadas como microempresas ou empresas de pequeno porte que fizerem jus ao direito de preferência previsto no Decreto nº 7.174, de 2010, terão prioridade no exercício desse benefício em relação às médias e às grandes empresas na mesma situação.

7.18.2 - Quando aplicada a margem de preferência a que se refere o Decreto nº 7.546, de 2 de agosto de 2011, não se aplicará o desempate previsto no Decreto nº 7.174, de 2010.

7.19 - Para produtos abrangidos por margem de preferência, caso a proposta de menor preço não tenha por objeto produto manufaturado nacional, o sistema automaticamente indicará as propostas de produtos manufaturados nacionais que estão enquadradas dentro da referida margem, para fins de aceitação pelo Pregoeiro.

7.19.1 - Nesta situação, a proposta beneficiada pela aplicação da margem de preferência tornar-se-á a proposta classificada em primeiro lugar.

7.20 - Ao final do procedimento, após o encerramento da etapa competitiva, os licitantes poderão reduzir seus preços ao valor da proposta do licitante mais bem classificado.

7.20.1 - A apresentação de novas propostas na forma deste item não prejudicará o resultado do certame em relação ao licitante mais bem classificado.

8 - DA ACEITABILIDADE DA PROPOSTA VENCEDORA

8.1 - Encerrada a etapa de lances e depois da verificação de possível empate, o Pregoeiro examinará a proposta classificada em primeiro lugar quanto ao preço, a sua exequibilidade, bem como quanto ao cumprimento das especificações do objeto.

8.2 - Analisada a aceitabilidade do preço obtido em relação ao valor de referência, o pregoeiro divulgará o resultado do julgamento das propostas de preços.

8.2.1 - Os preços não poderão ultrapassar o valor máximo para aquisição definido no Termo de Referência e que apresente preço manifestamente inexequível.

8.3 - O licitante qualificado como produtor rural pessoa física deverá incluir, na sua proposta, os percentuais das contribuições previstas no art. 176 da Instrução Normativa RFB n. 971, de 2009, em razão do disposto no art. 184, inciso V, sob pena de desclassificação.

8.4 - Considera-se inexequível a proposta que apresente preços global ou unitários simbólicos, irrisórios ou de valor zero, incompatíveis com os preços dos insumos e salários de mercado, acrescidos dos respectivos encargos, ainda que o ato convocatório da licitação não tenha estabelecido limites mínimos, exceto quando se referirem a materiais e instalações de propriedade do próprio licitante, para os quais ele renuncie a parcela ou à totalidade da remuneração.

8.5 - Após o término da etapa dos lances, o pregoeiro poderá convocar o licitante para enviar documento digital, que deverá ser apresentado por meio de funcionalidade disponível no sistema, de acordo com o solicitado pelo chat, em até 02 (duas) horas a contar da solicitação do Pregoeiro no sistema, sob pena de não aceitação da proposta.

8.5.1 - Dentre os documentos passíveis de solicitação pelo Pregoeiro, destacam-se os que contenham as características do material ofertado, tais como marca, modelo, tipo, fabricante e procedência, além de outras informações pertinentes, a exemplo de catálogos, folhetos ou propostas, encaminhados por meio eletrônico, ou, se for o caso, por outro meio e prazo indicados pelo Pregoeiro, sem prejuízo do seu ulterior envio pelo sistema eletrônico, sob pena de não aceitação da proposta.

8.5.1.1 - O prazo estabelecido pelo Pregoeiro poderá ser prorrogado por solicitação escrita e justificada do licitante, formulada antes de findo o prazo estabelecido, e formalmente aceita pelo Pregoeiro.

8.5.2 - Caso a compatibilidade com as especificações demandadas, sobretudo quanto a padrões de qualidade e desempenho, não possa ser aferida pelos meios previstos nos subitens acima, o Pregoeiro exigirá que o licitante classificado em primeiro lugar apresente amostra, sob pena de não aceitação da proposta, no local a ser indicado e dentro de 02 (dois) dias úteis contados da solicitação.

8.5.2.1 - No caso de não haver entrega da amostra ou ocorrer atraso na entrega, sem justificativa aceita pelo Pregoeiro, ou havendo entrega de amostra fora das especificações previstas neste Edital, a proposta do licitante será recusada.

8.5.2.2 - Se a(s) amostra(s) apresentada(s) pelo primeiro classificado não for(em) aceita(s), o Pregoeiro analisará a aceitabilidade da proposta ou lance ofertado pelo segundo classificado. Seguir-se-á com a verificação da(s) amostra(s) e, assim, sucessivamente, até a verificação de uma que atenda às especificações constantes no Termo de Referência.

8.5.2.3 - Os exemplares colocados à disposição da Administração serão tratados como protótipos, podendo ser manuseados e desmontados pela equipe técnica responsável pela análise, não gerando direito a ressarcimento.

8.5.2.4 - Após a divulgação do resultado final da licitação, as amostras entregues deverão ser recolhidas pelos licitantes no prazo de 10 (dez.) dias, após o qual poderão ser descartadas pela Administração, sem direito a ressarcimento.

8.5.2.5 - Os licitantes deverão colocar à disposição da Administração todas as condições indispensáveis à realização de testes e fornecer, sem ônus, os manuais impressos em língua portuguesa, necessários ao seu perfeito manuseio, quando for o caso.

8.6 - Caso a proposta classificada em primeiro lugar tenha se beneficiado da aplicação da margem de preferência, o Pregoeiro solicitará ao licitante que envie imediatamente, por meio eletrônico, com

posterior encaminhamento por via postal, o documento comprobatório da caracterização do produto manufaturado nacional.

8.7 - O licitante que não apresentar o documento comprobatório, ou cujo produto não atender aos regulamentos técnicos pertinentes e normas técnicas brasileiras aplicáveis, não poderá usufruir da aplicação da margem de preferência, sem prejuízo das penalidades cabíveis.

8.7.1 - Nessa hipótese, bem como em caso de inabilitação do licitante, as propostas serão reclassificadas, para fins de nova aplicação da margem de preferência.

8.8 - Se a proposta ou lance vencedor for desclassificado, o Pregoeiro examinará a proposta ou lance subsequente, e, assim sucessivamente, na ordem de classificação.

8.9 - Havendo necessidade, o Pregoeiro suspenderá a sessão, informando no “chat” a nova data e horário para a continuidade da mesma.

8.10 - O Pregoeiro poderá encaminhar, por meio do sistema eletrônico, contraproposta ao licitante que apresentou o lance mais vantajoso, com o fim de negociar a obtenção de melhor preço, vedada a negociação em condições diversas das previstas neste Edital.

8.10.1 - Também nas hipóteses em que o Pregoeiro não aceitar a proposta e passar à subsequente, poderá negociar com o licitante para que seja obtido preço melhor.

8.10.2 - A negociação será realizada por meio do sistema, podendo ser acompanhada pelos demais licitantes.

8.11 - Sempre que a proposta não for aceita, e antes de o Pregoeiro passar à subsequente, haverá nova verificação, pelo sistema, da eventual ocorrência do empate ficto, previsto nos artigos 44 e 45 da LC nº 123, de 2006, seguindo-se a disciplina antes estabelecida, se for o caso.

8.12 - Nos itens em que for admitido oferecer quantitativos inferiores, se a proposta do licitante vencedor não atender ao quantitativo total estimado para a contratação, respeitada a ordem de classificação, poderão ser convocados tantos quantos forem necessários para alcançar o total estimado, observado o preço da proposta vencedora.

8.13 - Para os efeitos do Decreto nº. 7.174/2010 consideram-se bens e serviços de informática e automação com tecnologia desenvolvida no País aqueles cujo efetivo desenvolvimento local seja comprovado junto ao Ministério da Ciência e Tecnologia, na forma por este regulamentada.

8.14 - Para os bens e serviços de informática e automação, será assegurado o direito de preferência previsto no artigo 3°, da Lei nº 8.248, de 1991, conforme procedimento estabelecido nos artigos 4º, 5° e 8° do Decreto n° 7.174, de 2010.

8.14.1 - Para os produtos abrangidos por margem de preferência, caso a proposta de menor preço não tenha por objeto produto manufaturado nacional, o sistema automaticamente indicará as propostas de produtos manufaturados nacionais que estão enquadradas dentro da referida margem, para fins de aceitação pelo Pregoeiro.

8.14.2 - Nessa situação, a proposta beneficiada pela aplicação da margem de preferência tornar-se-á a proposta classificada em primeiro lugar.

8.15 - Havendo eventual empate entre propostas, ou entre propostas e lances, o critério de desempate será aquele previsto no artigo 3º, § 2º, da Lei nº 8.666, de 1993, assegurando-se a preferência, sucessivamente, aos bens e serviços:

I - produzidos no País;

II - produzidos ou prestados por empresas brasileiras;

III - produzidos ou prestados por empresas que invistam em pesquisa e no desenvolvimento de tecnologia no País.

8.16 - Apurada a proposta final classificada em primeiro lugar, o Pregoeiro poderá encaminhar, pelo sistema eletrônico, contraproposta ao licitante para que seja obtido melhor preço, observado o critério de julgamento, não se admitindo negociar condições diferentes daquelas previstas neste Edital.

8.16.1 - A negociação será realizada por meio do sistema, podendo ser acompanhada pelos demais licitantes.

8.17 - O exercício do direito de preferência disposto no Decreto nº. 7.174/2010 será concedido após o encerramento da fase de apresentação das propostas ou lances, observando-se os seguintes procedimentos, sucessivamente:

8.17.1 - aplicação das regras de preferência para as microempresas e empresas de pequeno porte dispostas no Capítulo V da Lei Complementar nº 123, de 2006, quando for o caso;

8.17.2 - aplicação das regras de preferência com a classificação dos licitantes cujas propostas finais estejam situadas até dez por cento acima da melhor proposta válida, conforme o critério de julgamento, para a comprovação e o exercício do direito de preferência;

8.17.3 - convocação dos licitantes classificados que estejam enquadrados no item 8.17.2, na ordem de classificação, para que possam oferecer nova proposta ou novo lance para igualar ou superar a melhor proposta válida, caso em que será declarado vencedor do certame;

8.17.4 - caso nenhuma empresa classificada venha a exercer o direito de preferência, observar-se-ão as regras usuais de classificação e julgamento previstas na Lei no 8.666, de 21 de junho de 1993, e na Lei no 10.520, de 17 de julho de 2002.

9 - DA HABILITAÇÃO

9.1 - Como condição prévia ao exame da documentação de habilitação do licitante detentor da proposta classificada em primeiro lugar, o Pregoeiro verificará o eventual descumprimento das condições de participação, especialmente quanto à existência de sanção que impeça a participação no certame ou a futura contratação, mediante a consulta aos seguintes cadastros:

9.1.1 - SICAF;

9.1.2 - Cadastro Nacional de Empresas Inidôneas e Suspensas – CEIS, mantido pela Controladoria-Geral da União (xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx/xxxx);

9.1.3 - Cadastro Nacional de Condenações Cíveis por Atos de Improbidade Administrativa, mantido pelo Conselho Nacional de Justiça (xxx.xxx.xxx.xx/xxxxxxxxxxx_xxx/xxxxxxxxx_xxxxxxxxx.xxx).

9.1.4 - Lista de Inidôneos, mantida pelo Tribunal de Contas da União – TCU;

9.1.5 - A consulta aos cadastros será realizada em nome da empresa licitante e também de seu sócio majoritário, por força do artigo 12 da Lei n° 8.429, de 1992, que prevê, dentre as sanções impostas ao responsável pela prática de ato de improbidade administrativa, a proibição de contratar com o Poder Público, inclusive por intermédio de pessoa jurídica da qual seja sócio majoritário.

9.1.6 - Constatada a existência de sanção, o Pregoeiro reputará o licitante inabilitado, por falta de condição de participação.

9.2 - O Pregoeiro consultará o Sistema de Cadastro Unificado de Fornecedores – SICAF, em relação à habilitação jurídica, à regularidade fiscal e trabalhista, à qualificação econômica financeira e habilitação técnica, conforme o disposto nos arts. 4º, caput, 8º, § 3º, 13 a 18 e 43, III, da Instrução Normativa SLTI/MPOG nº 2, de 11.10.10.

9.2.1 - Também poderão ser consultados os sítios oficiais emissores de certidões, especialmente quando o licitante esteja com alguma documentação vencida junto ao SICAF.

9.2.2 - Caso o Pregoeiro não logre êxito em obter a certidão correspondente através do sítio oficial, ou na hipótese de se encontrar vencida no referido sistema, o licitante será convocado a encaminhar, no prazo de 02 (duas) horas, documento válido que comprove o atendimento das exigências deste Edital, sob pena de inabilitação, ressalvado o disposto quanto à comprovação da regularidade fiscal das licitantes qualificadas como microempresas ou empresas de pequeno porte, conforme estatui o art. 43, § 1º da LC nº 123, de 2006.

9.3 - Os licitantes que não estiverem cadastrados no Sistema de Cadastro Unificado de Fornecedores – SICAF além do nível de credenciamento exigido pela Instrução Normativa SLTI/MPOG nº 2, de 2010, deverão apresentar a seguinte documentação relativa à Habilitação Jurídica, à Regularidade Fiscal e trabalhista:

9.4 - Habilitação jurídica:

9.4.1 - No caso de empresário individual: inscrição no Registro Público de Empresas Mercantis, a cargo da Junta Comercial da respectiva sede;

9.4.2 - Em se tratando de microempreendedor individual – MEI: Certificado da Condição de Microempreendedor Individual - CCMEI, na forma da Resolução CGSIM nº 16, de 2009, cuja aceitação ficará condicionada à verificação da autenticidade no sítio xxx.xxxxxxxxxxxxxxxxxxxx.xxx.xx;

9.4.3 - No caso de sociedade empresária ou empresa individual de responsabilidade limitada - EIRELI: ato constitutivo, estatuto ou contrato social em vigor, devidamente registrado na Junta Comercial da respectiva sede, acompanhado de documento comprobatório de seus administradores;

9.4.4 - No caso de sociedade simples: inscrição do ato constitutivo no Registro Civil das Pessoas Jurídicas do local de sua sede, acompanhada de prova da indicação dos seus administradores;

9.4.5 - No caso de microempresa ou empresa de pequeno porte: certidão expedida pela Junta Comercial ou pelo Registro Civil das Pessoas Jurídicas, conforme o caso, que comprove a condição de microempresa ou empresa de pequeno porte, nos termos do artigo 8° da Instrução Normativa n° 103, de 30/04/2007, do Departamento Nacional de Registro do Comércio - DNRC;

9.4.6 - No caso de cooperativa: ata de fundação e estatuto social em vigor, com a ata da assembleia que o aprovou, devidamente arquivado na Junta Comercial ou inscrito no Registro Civil das Pessoas Jurídicas da respectiva sede, bem como o registro de que trata o art. 107 da Lei nº 5.764, de 1971;

9.4.7 - No caso de agricultor familiar: Declaração de Aptidão ao Pronaf – DAP ou DAP-P válida, ou, ainda, outros documentos definidos pelo Ministério do Desenvolvimento Agrário, nos termos do art. 4º, §2º do Decreto n. 7.775, de 2012.

9.4.8 - No caso de produtor rural: matrícula no Cadastro Específico do INSS – CEI, que comprove a qualificação como produtor rural pessoa física, nos termos da Instrução Normativa RFB n. 971, de 2009 (arts. 17 a 19 e 165).

9.4.9 - No caso de empresa ou sociedade estrangeira em funcionamento no País: decreto de autorização;

9.4.10 - Os documentos acima deverão estar acompanhados de todas as alterações ou da consolidação respectiva;

9.5 - Regularidade fiscal e trabalhista:

9.5.1 - prova de inscrição no Cadastro Nacional de Pessoas Jurídicas ou no Cadastro de Pessoas Físicas, conforme o caso;

9.5.2 - prova de regularidade fiscal perante a Fazenda Nacional, mediante apresentação de certidão expedida conjuntamente pela Secretaria da Receita Federal do Brasil (RFB) e pela Procuradoria-Geral da Fazenda Nacional (PGFN), referente a todos os créditos tributários federais e à Dívida Ativa da União (DAU) por elas administrados, inclusive aqueles relativos à Seguridade Social, nos termos da Portaria Conjunta nº 1.751, de 02/10/2014, do Secretário da Receita Federal do Brasil e da Procuradora-Geral da Fazenda Nacional.

9.5.3 - prova de regularidade com o Fundo de Garantia do Tempo de Serviço (FGTS);

9.5.4 - prova de inexistência de débitos inadimplidos perante a justiça do trabalho, mediante a apresentação de certidão negativa ou positiva com efeito de negativa, nos termos do Título VII-A da Consolidação das Leis do Trabalho, aprovada pelo Decreto-Lei nº 5.452, de 1º de maio de 1943;

9.5.5 - prova de inscrição no cadastro de contribuintes estadual, relativo ao domicílio ou sede do licitante, pertinente ao seu ramo de atividade e compatível com o objeto contratual;

9.5.6 - prova de regularidade com a Fazenda Estadual do domicílio ou sede do licitante;

8.5.7 - caso o fornecedor seja considerado isento dos tributos estaduais relacionados ao objeto licitatório, deverá comprovar tal condição mediante a apresentação de declaração da Fazenda Estadual do domicílio ou sede do fornecedor, ou outra equivalente, na forma da lei;

9.5.8 - caso o licitante detentor do menor preço seja qualificado como microempresa ou empresa de pequeno porte deverá apresentar toda a documentação exigida para efeito de comprovação de regularidade fiscal, mesmo que esta apresente alguma restrição, sob pena de inabilitação.

9.5.9 - A licitante melhor classificada deverá, também, apresentar a documentação de regularidade fiscal das microempresas e/ou empresas de pequeno porte que serão subcontratadas no decorrer da execução do contrato, ainda que exista alguma restrição, aplicando-se o prazo de regularização previsto no art. 4º, §1º do Decreto nº 8.538, de 2015.

9.6 - As empresas, cadastradas ou não no SICAF, deverão comprovar, ainda, a qualificação técnica, por meio de:

9.6.1 - Comprovação de aptidão para o fornecimento de bens em características, quantidades e prazos compatíveis com o objeto desta licitação, ou com o item pertinente, por meio da apresentação de atestados fornecidos por pessoas jurídicas de direito público ou privado.

9.7 - O licitante enquadrado como microempreendedor individual que pretenda auferir os benefícios do tratamento diferenciado previstos na Lei Complementar n. 123, de 2006, estará dispensado (a) da prova de inscrição nos cadastros de contribuintes estadual e municipal e (b) da apresentação do balanço patrimonial e das demonstrações contábeis do último exercício.

9.8 - Os documentos exigidos para habilitação relacionados nos subitens acima, deverão ser apresentados em meio digital pelos licitantes, por meio de funcionalidade presente no sistema (upload), de acordo com a solicitação do Pregoeiro no sistema eletrônico, no prazo de 02 horas. Somente mediante autorização do Pregoeiro será aceito o envio da documentação por meio do e- mail xxxxx@xxxx.xxx.xx. Posteriormente, os documentos serão remetidos em original, por qualquer processo de cópia reprográfica, autenticada por tabelião de notas, ou por servidor da Administração, desde que conferidos com o original, ou publicação em órgão da imprensa oficial, para análise, no prazo de 48 (quarenta e oito) horas após encerrado o prazo para o encaminhamento via funcionalidade do sistema (upload) ou e-mail, para a Equipe de Pregão da UFSJ, localizado na Xxxxx Xxxx Xxxxxxx, 000 - Xxxxxx, “Campus Santo Antônio” – Cep: 36.307-352 - São João del-Rei/MG, devendo, obrigatoriamente, conter na parte externa:

PREGÃO ELETRÔNICO Nº. 100/2016

PROPOSTA DE PREÇO E DOCUMENTAÇÃO DE HABILITAÇÃO

9.8.1 - Não serão aceitos documentos com indicação de CNPJ/CPF diferentes, salvo aqueles legalmente permitidos.

9.9 - A existência de restrição relativamente à regularidade fiscal não impede que a licitante qualificada como microempresa ou empresa de pequeno porte seja declarada vencedora, uma vez que atenda a todas as demais exigências do edital.

9.9.1 - A declaração do vencedor acontecerá no momento imediatamente posterior à fase de habilitação.

9.10 - Caso a proposta mais vantajosa seja ofertada por licitante qualificada como microempresa ou empresa de pequeno porte, e uma vez constatada a existência de alguma restrição no que tange à regularidade fiscal, a mesma será convocada para, no prazo de 5 (cinco) dias úteis, após a declaração do vencedor, comprovar a regularização. O prazo poderá ser prorrogado por igual período, a critério da administração pública, quando requerida pelo licitante, mediante apresentação de justificativa.

9.11 - A não-regularização fiscal no prazo previsto no subitem anterior acarretará a inabilitação do licitante, sem prejuízo das sanções previstas neste Edital, com a reabertura da sessão pública.

9.12 - Havendo necessidade de analisar minuciosamente os documentos exigidos, o Pregoeiro suspenderá a sessão, informando no “chat” a nova data e horário para a continuidade da mesma.

9.13 - Será inabilitado o licitante que não comprovar sua habilitação, seja por não apresentar quaisquer dos documentos exigidos, ou apresentá-los em desacordo com o estabelecido neste Edital.

9.14 - No caso de inabilitação, haverá nova verificação, pelo sistema, da eventual ocorrência do empate ficto, previsto nos artigos 44 e 45 da LC nº 123, de 2006, seguindo-se a disciplina antes estabelecida para aceitação da proposta subsequente.

9.15 - Para o exercício do direito de preferência, os fornecedores dos bens e serviços de informática e automação deverão apresentar, junto com a documentação necessária à habilitação, declaração, sob as penas da lei, de que atendem aos requisitos legais para a qualificação como microempresa ou empresa de pequeno porte, se for o caso, bem como a comprovação de que atendem aos requisitos estabelecidos nos subitens 5.6.

9.15.1 - Nas licitações na modalidade de pregão, a declaração a que se refere o item 9.15 deverá ser apresentada no momento da apresentação da proposta.

9.15.2 - O licitante deverá apresentar, juntamente com a proposta, cópia da portaria interministerial que atesta sua habilitação aos incentivos da Lei nº 8.248, de 1991, ou cópia da Resolução do Conselho de Administração da Superintendência da Zona Franca de Manaus - Suframa que atesta sua habilitação aos incentivos do Decreto-Lei nº 288, de 1967, em atendimento ao Decreto 8.184/2013 e Decreto 8.194/2013.

9.16 - Da sessão pública do Pregão divulgar-se-á Ata no sistema eletrônico.

10 - DA REABERTURA DA SESSÃO PÚBLICA

10.1 - A sessão pública poderá ser reaberta:

10.1.1 - Nas hipóteses de provimento de recurso que leve à anulação de atos anteriores à realização da sessão pública precedente ou em que seja anulada a própria sessão pública, situação em que serão repetidos os atos anulados e os que dele dependam.

10.1.2 - Quando houver erro na aceitação do preço melhor classificado ou quando o licitante declarado vencedor não assinar o contrato, não retirar o instrumento equivalente ou não comprovar a regularização fiscal, nos termos do art. 43, §1º da LC nº 123/2006. Nessas hipóteses, serão adotados os procedimentos imediatamente posteriores ao encerramento da etapa de lances.

10.2 - Todos os licitantes remanescentes deverão ser convocados para acompanhar a sessão reaberta.

10.2.1 - A convocação se dará por meio do sistema eletrônico (“chat”), ou e-mail, ou, ainda, fac-símile, de acordo com a fase do procedimento licitatório.

10.2.2 - A convocação feita por e-mail ou fac-símile dar-se-á de acordo com os dados contidos no SICAF, sendo responsabilidade do licitante manter seus dados cadastrais atualizados.

11 - DO ENCAMINHAMENTO DA PROPOSTA VENCEDORA

11.1 - A proposta final do licitante declarado vencedor deverá ser encaminhada no prazo de 02 (duas) horas, a contar da solicitação do Pregoeiro no sistema eletrônico e deverá:

11.1.1 - ser redigida em língua portuguesa, digitada, em uma via, sem emendas, rasuras, entrelinhas ou ressalvas, devendo a última folha ser assinada e as demais rubricadas pelo licitante ou seu representante legal.

11.1.2 - conter a indicação do banco, número da conta e agência do licitante vencedor, para fins de pagamento.

11.2 - A proposta final deverá ser documentada nos autos e será levada em consideração no decorrer da execução do contrato e aplicação de eventual sanção à Contratada, se for o caso.

11.2.1 - Todas as especificações do objeto contidas na proposta, tais como marca, modelo, tipo, fabricante e procedência, vinculam a Contratada.

12 - DOS RECURSOS

12.1 - Declarado o vencedor e decorrida a fase de regularização fiscal da licitante qualificada como microempresa ou empresa de pequeno porte, se for o caso, será concedido o prazo de no mínimo trinta minutos, para que qualquer licitante manifeste a intenção de recorrer, de forma motivada, isto é, indicando contra qual(is) decisão(ões) pretende recorrer e por quais motivos, em campo próprio do sistema.

12.2 - Havendo quem se manifeste, caberá ao Pregoeiro verificar a tempestividade e a existência de motivação da intenção de recorrer, para decidir se admite ou não o recurso, fundamentadamente.

12.2.1 - Nesse momento o Pregoeiro não adentrará no mérito recursal, mas apenas verificará as condições de admissibilidade do recurso.

12.2.2 - A falta de manifestação motivada do licitante quanto à intenção de recorrer importará a decadência desse direito.

12.2.3 - Uma vez admitido o recurso, o recorrente terá, a partir de então, o prazo de três dias para apresentar as razões, pelo sistema eletrônico, ficando os demais licitantes, desde logo, intimados para, querendo, apresentarem contrarrazões também pelo sistema eletrônico, em outros três dias, que começarão a contar do término do prazo do recorrente, sendo-lhes assegurada vista imediata dos elementos indispensáveis à defesa de seus interesses.

12.3 - O acolhimento do recurso invalida tão somente os atos insuscetíveis de aproveitamento.

12.4 - Os autos do processo permanecerão com vista franqueada aos interessados, no endereço constante neste Edital.

13 - DA ADJUDICAÇÃO E HOMOLOGAÇÃO

13.1 - O objeto da licitação será adjudicado ao licitante declarado vencedor, por ato do Pregoeiro, caso não haja interposição de recurso, ou pela autoridade competente, após a regular decisão dos recursos apresentados.

13.2 - Após a fase recursal, constatada a regularidade dos atos praticados, a autoridade competente homologará o procedimento licitatório.

14 - DA ATA DE REGISTRO DE PREÇOS

14.1 - Homologado o resultado da licitação, terá o adjudicatário o prazo de 5 (cinco) dias, contados a partir da data de sua convocação, para assinar a Ata de Registro de Preços, cujo prazo de validade encontra-se nela fixado, sob pena de decair do direito à contratação, sem prejuízo das sanções previstas neste Edital.

14.2 - Alternativamente à convocação para comparecer perante o órgão ou entidade para a assinatura da Ata de Registro de Preços, a Administração poderá encaminhá-la para assinatura, mediante correspondência postal com aviso de recebimento (AR) ou meio eletrônico, para que seja assinada no prazo de 5 (cinco) dias, a contar da data de seu recebimento.

14.3 - O prazo estabelecido no subitem anterior para assinatura da Ata de Registro de Preços poderá ser prorrogado uma única vez, por igual período, quando solicitado pelo(s) licitante(s) vencedor(s), durante o seu transcurso, e desde que devidamente aceito.

14.4 - Serão formalizadas tantas Atas de Registro de Preços quanto necessárias para o registro de todos os itens constantes no Termo de Referência, com a indicação do licitante vencedor, a descrição do(s) item(ns), as respectivas quantidades, preços registrados e demais condições.

14.4.1 - Será incluído na ata, sob a forma de anexo, o registro dos licitantes que aceitarem cotar os bens ou serviços com preços iguais aos do licitante vencedor na sequência da classificação do certame, excluído o percentual referente à margem de preferência, quando o objeto não atender aos requisitos previstos no art. 3º da Lei nº 8.666, de 1993;

15 - DO TERMO DE CONTRATO OU INSTRUMENTO EQUIVALENTE

15.1 - Dentro da validade da Ata de Registro de Preços, o fornecedor registrado poderá ser convocado para assinar o Termo de Contrato ou aceitar/retirar o instrumento equivalente (Nota de Empenho/Carta Contrato/Autorização).

15.2 - Previamente à contratação, a Administração promotora da licitação realizará consulta ao SICAF para identificar eventual proibição da licitante adjudicatária de contratar com o Poder Público.

15.2.1 - A adjudicatária terá o prazo de 05 (cinco) dias úteis, contados a partir da data de sua convocação, para assinar o Termo de Contrato ou aceitar o instrumento equivalente, conforme o caso, sob pena de decair do direito à contratação, sem prejuízo das sanções previstas neste Edital.

15.2.2 - Alternativamente à convocação para comparecer perante o órgão ou entidade para a assinatura do Termo de Contrato ou aceite do instrumento equivalente, a Administração poderá encaminhá-lo para assinatura ou aceite da Adjudicatária, mediante correspondência postal com aviso de recebimento (AR) ou meio eletrônico, para que seja assinado ou aceito no prazo de 05 (cinco) dias, a contar da data de seu recebimento.

15.3 - O prazo previsto no subitem anterior poderá ser prorrogado, por igual período, por solicitação justificada do adjudicatário e aceita pela Administração.

15.4 - Antes da assinatura do Termo de Contrato ou aceite do instrumento equivalente, a Administração realizará consulta “on line” ao SICAF, bem como ao Cadastro Informativo de Créditos não Quitados – CADIN, cujos resultados serão anexados aos autos do processo.

15.4.1 - Na hipótese de irregularidade do registro no SICAF, o contratado deverá regularizar a sua situação perante o cadastro no prazo de até 05 (cinco) dias, sob pena de aplicação das penalidades previstas no edital e anexos.

16 - DO PREÇO

16.1 - Os preços são fixos e irreajustáveis.

16.1.1 - As contratações decorrentes da Ata de Registro de Preços poderão sofrer alterações, obedecidas às disposições contidas no art. 65 da Lei n° 8.666/93 e no Decreto nº 7.892, de 2013.

17 - DA ENTREGA E DO RECEBIMENTO DO OBJETO E DA FISCALIZAÇÃO

17.1 - Os critérios de recebimento e aceitação do objeto e de fiscalização estão previstos no Termo de Referência.

18 - DAS OBRIGAÇÕES DA CONTRATANTE E DA CONTRATADA

18.1 - As obrigações da Contratante e da Contratada são as estabelecidas no Termo de Referência.

19 - DO PAGAMENTO

19.1 - O pagamento será realizado no prazo máximo de até 15 (quinze) dias úteis, contados a partir da data final do período de adimplemento a que se referir, através de ordem bancária, para crédito em banco, agência e conta corrente indicados pelo contratado.

19.2 - Os pagamentos decorrentes de despesas cujos valores não ultrapassem o limite de que trata o inciso II do art. 24 da Lei 8.666, de 1993, deverão ser efetuados no prazo de até 5 (cinco) dias úteis, contados da data da apresentação da Nota Fiscal, nos termos do art. 5º, § 3º, da Lei nº 8.666, de 1993.

19.3 - O pagamento somente será autorizado depois de efetuado o “atesto” pelo servidor competente na nota fiscal apresentada.

19.4 - Havendo erro na apresentação da Nota Fiscal ou dos documentos pertinentes à contratação, ou, ainda, circunstância que impeça a liquidação da despesa, como, por exemplo, obrigação financeira pendente, decorrente de penalidade imposta ou inadimplência, o pagamento ficará sobrestado até que a Contratada providencie as medidas saneadoras. Nesta hipótese, o prazo para pagamento iniciar-se-á após a comprovação da regularização da situação, não acarretando qualquer ônus para a Contratante.

19.5 - Será considerada data do pagamento o dia em que constar como emitida a ordem bancária para pagamento.

19.6 - Antes de cada pagamento à contratada, será realizada consulta ao SICAF para verificar a manutenção das condições de habilitação exigidas no edital.

19.7 - Constatando-se, junto ao SICAF, a situação de irregularidade da contratada, será providenciada sua advertência, por escrito, para que, no prazo de 5 (cinco) dias, regularize sua situação ou, no mesmo prazo, apresente sua defesa. O prazo poderá ser prorrogado uma vez, por igual período, a critério da contratante.

19.8 - Não havendo regularização ou sendo a defesa considerada improcedente, a contratante deverá comunicar aos órgãos responsáveis pela fiscalização da regularidade fiscal quanto à inadimplência da contratada, bem como quanto à existência de pagamento a ser efetuado, para que sejam acionados os meios pertinentes e necessários para garantir o recebimento de seus créditos.

19.9 - Persistindo a irregularidade, a contratante deverá adotar as medidas necessárias à rescisão contratual nos autos do processo administrativo correspondente, assegurada à contratada a ampla defesa.

19.10 - Havendo a efetiva execução do objeto, os pagamentos serão realizados normalmente, até que se decida pela rescisão do contrato, caso a contratada não regularize sua situação junto ao SICAF.

19.11 - Somente por motivo de economicidade, segurança nacional ou outro interesse público de alta relevância, devidamente justificado, em qualquer caso, pela máxima autoridade da contratante, não será rescindido o contrato em execução com a contratada inadimplente no SICAF.

19.12 - Quando do pagamento, será efetuada a retenção tributária prevista na legislação aplicável.

19.12.1 - A Contratada regularmente optante pelo Simples Nacional, nos termos da Lei Complementar nº 123, de 2006, não sofrerá a retenção tributária quanto aos impostos e contribuições abrangidos por aquele regime. No entanto, o pagamento ficará condicionado à apresentação de comprovação, por meio de documento oficial, de que faz jus ao tratamento tributário favorecido previsto na referida Lei Complementar.

19.13 - Nos casos de eventuais atrasos de pagamento, desde que a Contratada não tenha concorrido, de alguma forma, para tanto, fica convencionado que a taxa de compensação financeira devida pela Contratante, entre a data do vencimento e o efetivo adimplemento da parcela, é calculada mediante a aplicação da seguinte fórmula:

EM = I x N x VP, sendo:

EM = Encargos moratórios;

N = Número de dias entre a data prevista para o pagamento e a do efetivo pagamento; VP = Valor da parcela a ser paga.

I = Índice de compensação financeira = 0,00016438, assim apurado:

I = (TX) I = (6/100) 365 I = 0,00016438 TX = Percentual da taxa anual = 6%.

20 - DA FORMAÇÃO DO CADASTRO DE RESERVA

20.1 - Após o encerramento da etapa competitiva, os licitantes poderão reduzir seus preços ao valor da proposta do licitante mais bem classificado.

20.1.1 - A apresentação de novas propostas na forma deste item não prejudicará o resultado do certame em relação ao licitante melhor classificado.

20.2 - Havendo um ou mais licitantes que aceitem cotar suas propostas em valor igual ao do licitante vencedor, estes serão classificados segundo a ordem da última proposta individual apresentada durante a fase competitiva.

20.3 - Esta ordem de classificação dos licitantes registrados deverá ser respeitada nas contratações e somente será utilizada acaso o melhor colocado no certame não assine a ata ou tenha seu registro cancelado nas hipóteses previstas nos artigos 20 e 21 do Decreto n° 7.892/2013.

21 - DAS SANÇÕES ADMINISTRATIVAS

21.1 - Comete infração administrativa, nos termos da Lei nº 10.520, de 2002, o licitante/adjudicatário que:

21.1.1 - não aceitar/retirar a nota de xxxxxxx, ou não assinar o termo de contrato, quando convocado dentro do prazo de validade da proposta;

21.1.2 - apresentar documentação falsa;

21.1.3 - deixar de entregar os documentos exigidos no certame;

21.1.4 - ensejar o retardamento da execução do objeto;

21.1.5 - não mantiver a proposta;

21.1.6 - fraude fiscal;

21.1.7 - comportar-se de modo inidôneo;

21.2 - Considera-se comportamento inidôneo, entre outros, a declaração falsa quanto às condições de participação, quanto ao enquadramento como ME/EPP ou o conluio entre os licitantes, em qualquer momento da licitação, mesmo após o encerramento da fase de lances.

21.3 – O licitante/adjudicatário que cometer qualquer das infrações discriminadas no subitem anterior ficará sujeito, sem prejuízo da responsabilidade civil e criminal, às seguintes sanções:

21.3.1 - Multa de 10% (dez por cento) sobre o valor estimado do(s) item(s) prejudicado(s) pela conduta do licitante;

21.3.2 - Impedimento de licitar e de contratar com a União e descredenciamento no SICAF, pelo prazo de até cinco anos;

21.4 - A penalidade de multa pode ser aplicada cumulativamente com a sanção de impedimento.

21.5 - A aplicação de qualquer das penalidades previstas realizar-se-á em processo administrativo que assegurará o contraditório e a ampla defesa ao licitante/adjudicatário, observando-se o procedimento previsto na Lei nº 8.666, de 1993, e subsidiariamente na Lei nº 9.784, de 1999.

21.6 - A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade.

21.7 - As penalidades serão obrigatoriamente registradas no SICAF.

21.8 - As sanções por atos praticados no decorrer da contratação estão previstas no Termo de Referência.

22 - DA IMPUGNAÇÃO AO EDITAL E DO PEDIDO DE ESCLARECIMENTO

22.1 - Até 02 (dois) dias úteis antes da data designada para a abertura da sessão pública, qualquer pessoa poderá impugnar este Edital.

22.2 - A impugnação poderá ser realizada por forma eletrônica, pelo e-mail xxxxx@xxxx.xxx.xx ou por petição dirigida ou protocolada no endereço Praça Frei Orlando 170, sala 4.68, bairro Centro, cidade de São João del-Rei/MG, Cep: 36.307-352.

22.3 - Caberá ao Pregoeiro decidir sobre a impugnação no prazo de até vinte e quatro horas.

22.4 - Acolhida a impugnação, será definida e publicada nova data para a realização do certame.

22.5 - Os pedidos de esclarecimentos referentes a este processo licitatório deverão ser enviados ao Pregoeiro, até 03 (três) dias úteis anteriores à data designada para abertura da sessão pública, exclusivamente por meio eletrônico via internet, no endereço indicado no Edital.

22.6 - As impugnações e pedidos de esclarecimentos não suspendem os prazos previstos no certame.

22.7 - As respostas às impugnações e os esclarecimentos prestados pelo Pregoeiro serão entranhados nos autos do processo licitatório e estarão disponíveis para consulta por qualquer interessado.

23 - DAS DISPOSIÇÕES GERAIS

23.1 - Não havendo expediente ou ocorrendo qualquer fato superveniente que impeça a realização do certame na data marcada, a sessão será automaticamente transferida para o primeiro dia útil subsequente, no mesmo horário anteriormente estabelecido, desde que não haja comunicação em contrário pelo Pregoeiro.

23.2 - No julgamento das propostas e da habilitação, o Pregoeiro poderá sanar erros ou falhas que não alterem a substância das propostas, dos documentos e sua validade jurídica, mediante despacho fundamentado, registrado em ata e acessível a todos, atribuindo-lhes validade e eficácia para fins de habilitação e classificação.

23.3 - A homologação do resultado desta licitação não implicará direito à contratação.

23.4 - As normas disciplinadoras da licitação serão sempre interpretadas em favor da ampliação da disputa entre os interessados, desde que não comprometam o interesse da Administração, o princípio da isonomia, a finalidade e a segurança da contratação.

23.5 - Os licitantes assumem todos os custos de preparação e apresentação de suas propostas e a Administração não será, em nenhum caso, responsável por esses custos, independentemente da condução ou do resultado do processo licitatório.

23.6 - Na contagem dos prazos estabelecidos neste Edital e seus Anexos, excluir-se-á o dia do início e incluir-se-á o do vencimento. Só se iniciam e vencem os prazos em dias de expediente na Administração.

23.7 - O desatendimento de exigências formais não essenciais não importará o afastamento do licitante, desde que seja possível o aproveitamento do ato, observados os princípios da isonomia e do interesse público.

23.8 - Em caso de divergência entre disposições deste Edital e de seus anexos ou demais peças que compõem o processo, prevalecerá as deste Edital.

23.9 - É facultada ao pregoeiro ou à autoridade competente, em qualquer fase da licitação, a promoção de diligência destinada a esclarecer ou complementar a instrução do processo, vedada à inclusão posterior de documento ou informação que deveria constar do mesmo desde a realização da sessão pública.

23.10 - Os licitantes não terão direito à indenização em decorrência da anulação do procedimento licitatório, ressalvado o direito do contratado de boa-fé de ser ressarcido pelos encargos que tiver suportado no cumprimento do contrato.

23.11 - O órgão promotor do certame não disponibilizará suas instalações, bem como equipamentos ou conexões com o provedor do sistema eletrônico, às licitantes interessadas em participar deste Pregão Eletrônico.

23.12 - A autoridade competente poderá revogar a licitação por razões de interesse público decorrente de fato superveniente devidamente comprovado e fundamentado, pertinente e suficiente

para justificar tal conduta, devendo anulá-la por ilegalidade de ofício ou por provocação de terceiros, mediante parecer escrito e, também, fundamentado.

23.13 - Nos casos omissos aplicar-se-ão as disposições constantes da Lei nº 10.520, de 2002, do Decreto nº 5.450, de 2005, do Decreto nº 3.722, de 2001, da Lei Complementar nº 123, de 2006, e da Lei nº 8.666, de 1993, subsidiariamente.

24 - DO FORO

24.1 - Fica eleito o Foro da Justiça Federal, Subseção Judiciária de São João del-Rei, para dirimir qualquer controvérsia não resolvida entre as partes.

São João del-Rei, 07 de dezembro de 2016

Xxxxxxx Xxxxx Xxxxxx Pregoeiro

ANEXO I

UNIVERSIDADE FEDERAL DE SÃO JOÃO DEL-REI/UFSJ TERMO DE REFERÊNCIA

SISTEMA DE REGISTRO DE PREÇO

1 - DO OBJETO

1.1 - Aquisição de solução de segurança global (firewall) para os seis campi da Universidade Federal de São João del-Rei - UFSJ, conforme condições, quantidades e exigências estabelecidas neste instrumento:

Grupo	Item	Descrição	Unidad e de Medida	Quantidad e	Valor Unitário (Máximo Aceitável)	Valor Total (Máximo Aceitável)
1	1	Firewall Tipo I	Unidade	2	R$691.100,10	R$1.382.200,19
	2	Firewall Tipo II	Unidade	2	R$458.583,29	R$917.166,58
	3	Firewall Tipo III	Unidade	2	R$374.502,22	R$749.004,45
	4	Firewall Tipo IV	Unidade	5	R$307.544,00	R$1.537.720,02
	5	Firewall Tipo V	Unidade	5	R$154.334,20	R$771.671,02
	6	Firewall Tipo VI	Unidade	5	R$101.564,03	R$507.820,17
	7	Software de Gerenciamento	Unidade	2	R$90.714,79	R$181.429,59
	8	Software de Relatórios TIPO I	Unidade	2	R$101.482,23	R$202.964,46
	9	Software de Relatórios TIPO II	Unidade	2	R$94.523,46	R$189.046,92

* O detalhamento das especificações encontram-se no Anexo I deste Termo.

1.2 - O custo estimado total da presente contratação é de R$ 6.439.023,39 (seis milhões. quatrocentos e trinta e nove mil, vinte e três reais e trinta e nove centavos);

1.3 - Todos os bens tangíveis e intangíveis deverão ter prazo de garantia mínima de 36 (trinta e seis) meses de suporte e manutenção a contar do recebimento provisório, se a garantia for do fabricante, ou do recebimento definitivo, se a garantia for do fornecedor;

1.4 - Os produtos de hardware ofertados devem ser novos, nunca terem sido utilizados e não terem sido descontinuados, ou seja, devem constar na linha atual de comercialização e suporte do fabricante;

1.5 - Todos os produtos do Grupo 1 devem ser do mesmo fabricante, a fim de manter a padronização das soluções;

1.6 - Todos os produtos (hardware e software) deverão possuir garantia pelo período de 36 (trinta e seis) meses;

1.7 - Na apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos;

1.8 - No intuito de dirimir quaisquer dúvidas em relação as especificações técnicas, a UFSJ poderá requisitar uma amostra e/ou catálogo de especificações técnicas dos produtos ofertados para realização de testes de bancada;

1.9 - Os produtos ofertados deverão vir acompanhados de todos os cabos e acessórios necessários à completa instalação e operação dos mesmos;

1.10 - Os produtos ofertados deverão vir acompanhados de documentação impressa ou em mídia DVD/CD ou via download, em idioma português ou inglês, contendo orientações para configuração e operação do produto fornecido.

2 - JUSTIFICATIVA E OBJETIVO DA CONTRATAÇÃO

A presente aquisição visa o alinhamento à Estratégia da Universidade Federal de São João del-Rei (UFSJ) em relação a sua área de tecnologia da informação de forma a garantir a segurança, disponibilidade e a funcionalidade dos sistemas essenciais ao funcionamento das atividades, bem como prover os recursos necessários à área que possibilitem à execução da estratégia, uma vez que a alta disponibilidade nos serviços prestados e no acesso às informações impacta diretamente ao cidadão e alinha-se a um leque de Valores Institucionais desta academia: acessibilidade, modernização, transparência fortalecendo assim a confiabilidade dos públicos internos e externos em relação a Instituição. A demanda permanentemente crescente por recursos de Tecnologia da Informação impulsiona a necessidade de que as “áreas de TI” das empresas estejam preparadas para prover rapidamente soluções que alinhadas com os objetivos estratégicos da Universidade Federal de São João del-Rei (UFSJ).

Em virtude da ampliação da infraestrutura de TI da UFSJ e da constante expansão dos serviços de rede faz-se necessário promover a Segurança da Informação no ambiente computacional da UFSJ, seguindo as diretrizes da IN nº. 01 GSI/PR/2008 e de suas normas complementares que orientam acerca das diretrizes desejáveis de segurança da informação e comunicações no âmbito da administração pública.

A aquisição de solução integrada de segurança é de suma importância para a proteção dos dados contidos na rede da UFSJ, pois permite a realização de:

⚫ Segmentar fisicamento a rede da UFSJ;

⚫ Criação de filtros para bloqueio dos conteúdos adultos como: pornografia, vídeos impróprios, arquivos maliciosos entre outros;

⚫ Proteger a rede contra worms, vírus, malware entre outras pragas virtuais;

⚫ Geração de relatórios dos acessos realizados por IP, grupo ou usuário nas seguintes formas: diário, semanal, mensal ou período selecionado;

⚫ Criação de políticas de proteção da rede de computadores contra: ataques de hackers através do bloqueio de programas de compartilhamento de dados (P2P), bloqueio mensagens instantâneas, fechamento de portas não utilizadas controlando a banda de internet a fim de evitar abusos em sua utilização;

⚫ Regras de bloqueio e liberação de serviços e portas TCP e UDP por grupo ou usuário;

⚫ Limitação de banda por serviços, tais como: servidor web, streaming, internet etc;

⚫ Monitoramento do link de dados.

2.1 - Justificativa para as quantidades

As quantidades especificadas têm o objetivo de garantir alta disponibilidade dos serviços de tecnologia da informação dos 06 (seis) campi da UFSJ.

2.2 - Justificativa para aquisição em lote

A aquisição de vários produtos como um único lote, deve-se a ser uma solução completa de segurança global, descriminada neste Termo de Referência e seus Anexos, que objetivam permitir ao Núcleo de Tecnologia da Informação uma contratação de infraestrutura de hardware e software com o foco no alinhamento à estratégia da UFSJ em relação a sua área de tecnologia da informação de forma a garantir a manutenabilidade, disponibilidade e a funcionalidade dos sistemas e serviços essenciais ao funcionamento das atividades, bem como prover os recursos necessários à área que possibilitem à execução da estratégia uma vez que a alta disponibilidade nos serviços prestados e no

acesso às informações impacta diretamente ao cidadão e alinha-se a um leque de Valores Institucionais desta Casa tais como: acessibilidade, modernização e transparência; fortalecendo assim a confiabilidade dos públicos internos e externos em relação a Instituição.

Justifica-se, ainda, a aquisição destes equipamentos em lote único em virtude da observância do Inciso primeiro do Art. 15 da Lei Nº 8.666 de 21 de Junho de 1993, uma vez que esta solução trata-se de um projeto global de alta tecnologia, complexo e integrado. A unificação destes itens também se faz mais vantajosa para este órgão, tendo em vista que tecnicamente, a instalação é interdependente. Lidar com um único lote diminui o custo administrativo de gerenciamento de todo o processo de contratação: fornecimento, suporte e garantias dos produtos. E mais, o aumento da eficiência administrativa do setor público passa pela otimização do gerenciamento de seus contratos de fornecimento. Essa eficiência administrativa também é de estatura constitucional e deve ser buscada pela administração pública.

3 - CLASSIFICAÇÃO DOS BENS COMUNS

3.1 - Os bens a serem adquiridos enquadram-se na classificação de bens comuns, nos termos da Lei n° 10.520, de 2002, do Decreto n° 3.555, de 2000, e do Decreto 5.450, de 2005.

4 - ENTREGA E CRITÉRIOS DE ACEITAÇÃO DO OBJETO.

4.1 - O prazo de entrega dos bens tangíveis e intangíveis é de no máximo 60 (sessenta) dias, contados do recebimento da nota de empenho, em remessa (única ou parcelada), no seguinte endereço: Campus Santo Antônio, à Xxxxx Xxxx Xxxxxxx, 000, Xxxxxx, em São João del-Rei/MG, no horário das 08h30min às 11h30min e de 14h às 17h, sendo o frete, carga e descarga por conta do fornecedor até o local indicado pelo Setor de Almoxarifado/Patrimônio.

4.2 - Os bens serão recebidos provisoriamente a partir da entrega, pelo(a) responsável pelo acompanhamento e fiscalização do contrato, para efeito de posterior verificação de sua conformidade com as especificações constantes neste Termo de Referência e na proposta.

4.3 - Os bens poderão ser rejeitados, no todo ou em parte, quando em desacordo com as especificações constantes neste Termo de Referência e na proposta, devendo ser substituídos no prazo de 5 (cinco) dias, a contar da notificação da contratada, às suas custas, sem prejuízo da aplicação das penalidades.

4.4 - Os bens serão recebidos definitivamente no prazo de 5 (cinco) dias, contados do recebimento provisório, após a verificação da qualidade e quantidade do material e consequente aceitação mediante termo circunstanciado.

4.5 - Na hipótese de a verificação a que se refere o subitem anterior não ser procedida dentro do prazo fixado, reputar-se-á como realizada, consumando-se o recebimento definitivo no dia do esgotamento do prazo.

4.6 - O recebimento provisório ou definitivo do objeto não exclui a responsabilidade da contratada pelos prejuízos resultantes da incorreta execução do contrato.

5 - OBRIGAÇÕES DA CONTRATANTE

5.1 - São obrigações da Contratante:

5.1.1 - receber o objeto no prazo e condições estabelecidas no Edital e seus anexos;

5.1.2 - verificar minuciosamente, no prazo fixado, a conformidade dos bens recebidos provisoriamente com as especificações constantes do Edital e da proposta, para fins de aceitação e recebimento definitivo;

5.1.3 - comunicar à Contratada, por escrito, sobre imperfeições, falhas ou irregularidades verificadas no objeto fornecido, para que seja substituído, reparado ou corrigido;

5.1.4 - acompanhar e fiscalizar o cumprimento das obrigações da Contratada, através de comissão/servidor especialmente designado;

5.1.5 - efetuar o pagamento à Contratada no valor correspondente ao fornecimento do objeto, no prazo e forma estabelecidos no Edital e seus anexos;

5.2 - A Administração não responderá por quaisquer compromissos assumidos pela Contratada com terceiros, ainda que vinculados à execução do presente Termo de Contrato, bem como por qualquer dano causado a terceiros em decorrência de ato da Contratada, de seus empregados, prepostos ou subordinados.

5.3 - A Administração realizará pesquisa de preços periodicamente, em prazo não superior a 180 (cento e oitenta) dias, a fim de verificar a vantajosidade dos preços registrados em Ata.

6 - OBRIGAÇÕES DA CONTRATADA

6.1 - A Contratada deve cumprir todas as obrigações constantes no Edital, seus anexos e sua proposta, assumindo como exclusivamente seus os riscos e as despesas decorrentes da boa e perfeita execução do objeto e, ainda:

6.1.1 - efetuar a entrega do objeto em perfeitas condições, conforme especificações, prazo e local constantes no Edital e seus anexos, acompanhado da respectiva nota fiscal, na qual constarão as indicações referentes a: marca, fabricante, modelo, procedência e prazo de garantia ou validade;

6.1.1.1 - O objeto deve estar acompanhado do manual do usuário, com uma versão em português e da relação da rede de assistência técnica autorizada;

6.1.2 - responsabilizar-se pelos vícios e danos decorrentes do objeto, de acordo com os artigos 12, 13 e 17 a 27, do Código de Defesa do Consumidor (Lei nº 8.078, de 1990);

6.1.3 - substituir, reparar ou corrigir, às suas expensas, no prazo fixado neste Termo de Referência, o objeto com avarias ou defeitos;

6.1.4 - comunicar à Contratante, no prazo máximo de 24 (vinte e quatro) horas que antecede a data da entrega, os motivos que impossibilitem o cumprimento do prazo previsto, com a devida comprovação;

6.1.5 - manter, durante toda a execução do contrato, em compatibilidade com as obrigações assumidas, todas as condições de habilitação e qualificação exigidas na licitação;

6.1.6 - indicar preposto para representá-la durante a execução do contrato;

6.2 - A empresa Contratada deverá prestar serviços de manutenção e suporte técnico a todos os produtos contratados, no local de instalação da solução, sem ônus para a Contratante, durante os sete dias da semana, incluindo finais de semana e feriados, 24 (vinte e quatro) horas por dia (7x24);

6.3 - A empresa Contratada fornecerá à Contratante os meios de contato (telefone, "e-mail", site web) com vistas a receber os chamados técnicos para prestar os eventuais serviços de suporte;

6.4 - A manutenção dos equipamentos fornecidos compreende o atendimento a defeitos decorrentes, fabricação ou desgaste prematuro, envolvendo, obrigatoriamente, a substituição de peças;

6.5 - Toda e quaisquer despesas decorrentes da execução dos Serviços de Manutenção e Suporte Técnico aqui descrito, ficarão inteiramente a cargo da Contratada, bem como a responsabilidade dos produtos e/ou seus componentes que estiverem sob sua guarda, arcando com quaisquer danos;

6.5.1 - Um chamado somente será considerado contingenciado ou concluído com o aceite da CONTRATANTE.

6.5.2 - Solução de Contingência ou de Contorno é uma solução temporária para um problema que não elimina a sua causa raiz. Esta solução restabelece a disponibilidade do ambiente, possibilitando assim a execução plena de suas funções originais, mantendo o mesmo nível de desempenho anterior ao problema;

6.5.3 - Para problemas de hardware, a solução definitiva não poderá ultrapassar 2 (dois) dias úteis e para software, 07(sete) dias;

6.5.4 - Não será aceito, pela CONTRATANTE, a cobrança de eventuais diferenças vinculadas a questões trabalhistas, tais como férias, horas extras, sobreaviso, etc. Adicionalmente, todos os gastos provenientes de deslocamento, estadia e alimentação,

caso sejam necessários, já deverão estar incluídos no preço final da proposta.

6.6 - As descrições dos serviços a serem executados, da qualificação mínima dos profissionais envolvidos no projeto encontram-se no ANEX II e devem ser seguidas em sua íntegra.

7 - DA SUBCONTRATAÇÃO

7.1 - Não será admitida a subcontratação do objeto licitatório.

8 - ALTERAÇÃO SUBJETIVA

8.1 - É admissível a fusão, cisão ou incorporação da contratada com/em outra pessoa jurídica, desde que sejam observados pela nova pessoa jurídica todos os requisitos de habilitação exigidos na licitação original; sejam mantidas as demais cláusulas e condições do contrato; não haja prejuízo à execução do objeto pactuado e haja a anuência expressa da Administração à continuidade do contrato.

9 - CONTROLE DA EXECUÇÃO

9.1 - Nos termos do art. 67 Lei nº 8.666, de 1993, será designado representante para acompanhar e fiscalizar a entrega dos bens, anotando em registro próprio todas as ocorrências relacionadas com a execução e determinando o que for necessário à regularização de falhas ou defeitos observados.

9.2 - A fiscalização de que trata este item não exclui nem reduz a responsabilidade da Contratada, inclusive perante terceiros, por qualquer irregularidade, ainda que resultante de imperfeições técnicas ou vícios redibitórios, e, na ocorrência desta, não implica em co-responsabilidade da Administração ou de seus agentes e prepostos, de conformidade com o art. 70 da Lei nº 8.666, de 1993.

9.3 - O representante da Administração anotará em registro próprio todas as ocorrências relacionadas com a execução do contrato, indicando dia, mês e ano, bem como o nome dos funcionários eventualmente envolvidos, determinando o que for necessário à regularização das falhas ou defeitos observados e encaminhando os apontamentos à autoridade competente para as providências cabíveis.

10 - DAS SANÇÕES ADMINISTRATIVAS

10.1 - Comete infração administrativa nos termos da Lei nº 8.666, de 1993 e da Lei nº 10.520, de 2002, a Contratada que:

10.1.1 - inexecutar total ou parcialmente qualquer das obrigações assumidas em decorrência da contratação;

10.1.2 - ensejar o retardamento da execução do objeto;

10.1.3 - fraudar na execução do contrato;

10.1.4 - comportar-se de modo inidôneo;

10.1.5 - cometer fraude fiscal;

10.1.6 - não mantiver a proposta.

10.2 - A Contratada que cometer qualquer das infrações discriminadas no subitem acima ficará sujeita, sem prejuízo da responsabilidade civil e criminal, às seguintes sanções:

10.2.1 - advertência por faltas leves, assim entendidas aquelas que não acarretem prejuízos significativos para a Contratante;

10.2.2 - multa moratória de 0,1% (um décimo por cento) por dia de atraso injustificado sobre o valor da parcela inadimplida, até o limite de 2% (dois por centos);

10.2.3 - multa compensatória de 10% (dez por cento) sobre o valor total do contrato, no caso de inexecução total do objeto;

10.2.4 - em caso de inexecução parcial, a multa compensatória, no mesmo percentual do subitem acima, será aplicada de forma proporcional à obrigação inadimplida;

10.2.5 - suspensão de licitar e impedimento de contratar com o órgão, entidade ou unidade administrativa pela qual a Administração Pública opera e atua concretamente, pelo prazo de até dois anos;

10.2.6 - impedimento de licitar e contratar com a União com o consequente descredenciamento no SICAF pelo prazo de até cinco anos;

10.2.7 - declaração de inidoneidade para licitar ou contratar com a Administração Pública, enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação perante a própria autoridade que aplicou a penalidade, que será concedida sempre que a Contratada ressarcir a Contratante pelos prejuízos causados;

10.3 - Também ficam sujeitas às penalidades do art. 87, III e IV da Lei nº 8.666, de 1993, as empresas ou profissionais que:

10.3.1 - tenham sofrido condenação definitiva por praticar, por meio dolosos, fraude fiscal no recolhimento de quaisquer tributos;

10.3.2 - tenham praticado atos ilícitos visando a frustrar os objetivos da licitação;

10.3.3 - demonstrem não possuir idoneidade para contratar com a Administração em virtude de atos ilícitos praticados.

10.4 - A aplicação de qualquer das penalidades previstas realizar-se-á em processo administrativo que assegurará o contraditório e a ampla defesa à Contratada, observando-se o procedimento previsto na Lei nº 8.666, de 1993, e subsidiariamente a Lei nº 9.784, de 1999.

10.5 - A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade.

10.6 - As penalidades serão obrigatoriamente registradas no SICAF.

São João del-Rei, 18 de novembro de 2016.

Prof. Xxxxxxxx Xxxxxx Xxxxx da Rocha Diretor de Núcleo de Tecnologia da Informação

Xxxx Xxxxxxxx Chefe do SETIR/NTINF

ANEXO I DO TERMO DE REFERÊNCIA

Especificações Técnicas

LOTE 1 - ITEM 1

1 .FIREWALL TIPO I

1.1.Características de hardware e performance

1.1.1.Throughput de, no mínimo, 55 Gbps com a funcionalidade de firewall habilitada para tráfego IPv4 e IPv6, independentemente do tamanho do pacote

1.1.2.Suporte a, no mínimo, 12M conexões simultâneas 1.1.3.Suporte a, no mínimo, 300K novas conexões por segundo 1.1.4.Throughput de, no mínimo, 20 Gbps de VPN IPSec

1.1.5.Estar licenciado para ou suportar sem o uso de licença, 20K túneis de VPN IPSEC Site-to-Site simultâneos

1.1.6.Estar licenciado para ou suportar sem o uso de licença, 20K túneis de clientes VPN IPSEC simultâneos

1.1.7.Throughput de, no mínimo, 4 Gbps de VPN SSL 1.1.8.Suporte a, no mínimo, 10K clientes de VPN SSL simultâneos 1.1.9.Suportar no mínimo 13 Gbps de throughput de IPS

1.1.10. Suportar no mínimo 10.5 Gbps de throughput de Inspeção SSL

1.1.11. Throughput de, no mínimo, 4.5 Gbps com as seguintes funcionalidade habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware. Caso o fabricante divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito;

1.1.12. Possuir ao menos 16 interfaces 1Gbps

1.1.13. Possuir ao menos 8 interfaces 10Gbps

1.1.14. Disco de, no mínimo, 240 GBytes para armazenamento de informações locais

1.1.15. Estar licenciado e/ou ter incluído sem custo adicional, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

1.1.16. Suporte a, no mínimo, 225 sistemas virtuais lógicos (Contextos) por appliance

1.2.Características Gerais

1.2.1. A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;

1.2.2.Deverá ser do mesmo fabricante dos itens “SOFTWARE DE GERENCIAMENTO” e “SOFTWARE DE RELATÓRIOS”, para garantir total compatibilidade;

1.2.3. 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;

1.2.4. 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;

1.2.5. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;

1.2.6. 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;

1.2.7. O software deverá ser fornecido em sua versão mais atualizada;

1.2.8. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

1.2.9. O gerenciamento da solução deve suportar a interface de administração via web no próprio dispositivo de proteção de rede

1.2.10. Os dispositivos de proteção de rede devem possuir suporte a 1024 VLAN Tags 802.1q;

1.2.11. Os dispositivos de proteção de rede devem possuir suporte a agregação de links 8023ad e LACP;

1.2.12. Os dispositivos de proteção de rede devem possuir suporte a Policy based routing ou policy based forwarding;

1.2.13. Os dispositivos de proteção de rede devem possuir suporte a roteamento multicast (PIM-SM e PIM-DM);

1.2.14. Os dispositivos de proteção de rede devem possuir suporte a DHCP Relay;

1.2.15. Os dispositivos de proteção de rede devem possuir suporte a DHCP Server;

1.2.16. Os dispositivos de proteção de rede devem possuir suporte a Jumbo Frames;

1.2.17. Os dispositivos de proteção de rede devem suportar sub-interfaces ethernet logicas

1.2.18. Deve suportar NAT dinâmico (Many-to-1);

1.2.19. Deve suportar NAT dinâmico (Many-to-Many);

1.2.20. Deve suportar NAT estático (1-to-1);

1.2.21. Deve suportar NAT estático (Many-to-Many);

1.2.22. Deve suportar NAT estático bidirecional 1-to-1;

1.2.23. Deve suportar Tradução de porta (PAT);

1.2.24. Deve suportar NAT de Origem;

1.2.25. Deve suportar NAT de Destino;

1.2.26. Deve suportar NAT de Origem e NAT de Destino simultaneamente;

1.2.27. Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico;

1.2.28. Deve suportar NAT64 e NAT46;

1.2.29. Deve implementar o protocolo ECMP;

1.2.30. Deve implementar balanceamento de link por hash do IP de origem;

1.2.31. Deve implementar balanceamento de link por hash do IP de origem e destino;

1.2.32. 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;

1.2.33. Deve permitir monitorar via SNMP falhas de hardware, uso de recursos por número elevado de sessões, conexões por segundo, número de túneis estabelecidos na VPN, CPU, memória, status do cluster, ataques e estatísticas de uso das interfaces de rede

1.2.34. Enviar log para sistemas de monitoração externos, simultaneamente;

1.2.35. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;

1.2.36. Proteção anti-spoofing;

1.2.37. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);

1.2.38. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);

1.2.39. Suportar OSPF graceful restart;

1.2.40. 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);

1.2.41. Deve suportar Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;

1.2.42. Deve suportar 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;

1.2.43. Deve suportar 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;

1.2.44. Deve suportar Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;

1.2.45. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente;

1.2.46. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3;

1.2.47. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster;

1.2.48. A configuração em alta disponibilidade deve sincronizar: Sessões;

1.2.49. A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede;

1.2.50. A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs;

1.2.51. A configuração em alta disponibilidade deve sincronizar:Tabelas FIB;

1.2.52. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link;

1.2.53. Deve possuir suporte à criação de sistemas virtuais no mesmo appliance;

1.2.54. A utilização dos dispositivos em alta disponibilidade não deve impor limitações quanto à utilização de sistemas virtuais (contextos);

1.2.55. Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas;

1.2.56. O gerenciamento da solução deve suportar acesso via SSH e interface WEB (HTTPS), incluindo, mas não limitado à, exportar configuração dos sistemas virtuais (contextos) por ambas interfaces;

1.2.57. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema virtual, ou seja, isolação das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos)

1.2.58. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH 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;

1.2.59. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH Decryption e protocolos de roteamento dinâmico devem operar em caráter permanente, o licenciamento do dispositivo de segurança não pode ter nenhuma relação com sua configuração de rede como, mas não limitado a, configuração de interfaces, endereços lógicos, etc , podendo ser utilizado 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;

1.3. Controle por Política de Firewall

1.3.1. Deverá suportar controles por zona de segurança

1.3.2. Controles de políticas por porta e protocolo

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

1.3.4. Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança

1.3.5. Controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS)

1.3.6. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound)

1.3.7. Deve suportar offload de certificado em inspeção de conexões SSL de entrada (Inbound);

1.3.8. Deve de-criptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2;

1.3.9. Controle de inspeção e de-criptografia de SSH por política;

1.3.10. Suporte a objetos e regras IPV6;

1.3.11. Suporte a objetos e regras multicast;

1.3.12. Deve suportar no mínimo 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 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;

1.3.13. Suportar a atribuição de agendamento das políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente;

1.4. Controle de Aplicações

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

1.4.2. Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos

1.4.3. 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;

1.4.4. 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;

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

1.4.6. Deve 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;

1.4.7. 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 utilização da rede Tor

1.4.8. 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;

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

1.4.10. Identificar o uso de táticas evasivas via comunicações criptografadas;

1.4.11. Atualizar a base de assinaturas de aplicações automaticamente;

1.4.12. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos do LDAP/AD;

1.4.13. 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;

1.4.14. 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;

1.4.15. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos;

1.4.16. Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;

1.4.17. 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;

1.4.18. 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: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS- SQL, IMAP, DNS, LDAP, RTSP e SSL

1.4.19. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;

1.4.20. Deve alertar o usuário quando uma aplicação for bloqueada;

1.4.21. Deve possibilitar que o controle de portas seja aplicado para todas as aplicações;

1.4.22. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc) possuindo granularidade de controle/políticas para os mesmos;

1.4.23. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos;

1.4.24. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo;

1.4.25. Deve possibilitar a diferenciação de aplicações Proxies (psiphon3, freegate, etc) possuindo granularidade de controle/políticas para os mesmos;

1.4.26. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como:

1.4.27. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client- Server, Browse Based, Network Protocol, etc)

1.4.28. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação

1.4.29. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Categoria da aplicação

1.4.30. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Aplicações que usem técnicas evasivas, utilizadas por malwares como uso excessivo de banda, tunelamento de tráfego ou transferência de arquivos, etc;

1.5. Prevenção de Ameaças

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

1.5.2. Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);

1.5.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 atualizações ou que não haja contrato de garantia de software com o fabricante;

1.5.4. Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade ativo/ativo e ativo/passivo;

1.5.5. 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;

1.5.6. As assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;

1.5.7. Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

1.5.8. Exceções por IP de origem ou de destino devem ser possíveis nas regras e assinatura a assinatura;

1.5.9. Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens

1.5.10. Deve permitir o bloqueio de vulnerabilidades

1.5.11. Deve permitir o bloqueio de exploits conhecidos

1.5.12. Deve incluir proteção contra-ataques de negação de serviços

1.5.13. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de padrões de estado de conexões;

1.5.14. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de decodificação de protocolo;

1.5.15. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise para detecção de anomalias de protocolo;

1.5.16. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise heurística;

1.5.17. Deverá possuir o seguinte mecanismos de inspeção de IPS: IP Defragmentation;

1.5.18. Deverá possuir o seguinte mecanismos de inspeção de IPS: Remontagem de pacotes de TCP;

1.5.19. Deverá possuir o seguinte mecanismos de inspeção de IPS: Bloqueio de pacotes malformados

1.5.20. Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood, etc;

1.5.21. Detectar e bloquear a origem de portscans;

1.5.22. Bloquear ataques efetuados por worms conhecidos, permitindo ao administrador acrescentar novos padrões;

1.5.23. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;

1.5.24. Possuir assinaturas para bloqueio de ataques de buffer overflow;

1.5.25. Deverá possibilitar a criação de assinaturas customizadas pela interface gráfica do produto;

1.5.26. 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;

1.5.27. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;

1.5.28. Identificar e bloquear comunicação com botnets;

1.5.29. 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;

1.5.30. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS e controle de aplicação;

1.5.31. Deve permitir que na captura de pacotes por assinaturas de IPS seja definido o número de pacotes a serem capturados ou permitir capturar o pacote que deu origem ao alerta assim como seu contexto, facilitando a análise forense e identificação de falsos positivos

1.5.32. Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas;

1.5.33. Os eventos devem identificar o país de onde partiu a ameaça;

1.5.34. Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms

1.5.35. Proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos

1.5.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, zonas de segurança, 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

1.6. Filtro de URL

1.6.1. 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);

1.6.2. Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

1.6.3. Deve possuir 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, Active Directory e base de dados local;

1.6.4. Suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL;

1.6.5. Deve possuir base ou cache de URLs local no appliance ou em nuvem do próprio fabricante, evitando delay de comunicação/validação das URLs;

1.6.6. Possuir pelo menos 60 categorias de URLs;

1.6.7. Deve possuir a função de exclusão de URLs do bloqueio, por categoria;

1.6.8. Permitir a customização de página de bloqueio;

1.6.9. Permitir 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);

1.7. Identificação de Usuários

1.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;

1.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;

1.7.3. 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, suportando single sign-on, essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à utilização de sistemas virtuais, segmentos de rede, etc;

1.7.4. 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;

1.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;

1.7.6. 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);

1.7.7. 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;

1.7.8. Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;

1.7.9. Permitir integração com tokens para autenticação dos usuários, incluindo, mas não limitado a acesso à internet e gerenciamento da solução

1.7.10. Prover no mínimo um token nativamente, possibilitando autenticação de duplo fator

1.8. QoS e Traffic Shaping

1.8.1. Suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem;

1.8.2. Suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino;

1.8.3. Suportar a criação de políticas de QoS e Traffic Shaping por porta;

1.8.4. O QoS deve possibilitar a definição de classes por Banda Garantida;

1.8.5. O QoS deve possibilitar a definição de classes por Banda Máxima;

1.8.6. O QoS deve possibilitar a definição de classes por Fila de Prioridade

1.8.7. Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping;

1.8.8. Deve suportar QOS (traffic-shapping), em interface agregadas ou redundantes;

1.9. Filtro de Dados

1.9.1. Suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

1.9.2. Suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

1.9.3. 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;

1.10. Geo Localização

1.10.1. Suportar a criação de políticas por geo-localização, permitindo o trafego de determinado Pais/Países sejam bloqueados;

1.10.2. Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos;

1.10.3. Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas;

1.11. VPN

1.11.1. Suportar VPN Site-to-Site e Cliente-To-Site;

1.11.2. Suportar IPSec VPN;

1.11.3. Suportar SSL VPN;

1.11.4. A VPN IPSEc deve suportar 3DES;

1.11.5. A VPN IPSEc deve suportar Autenticação MD5 e SHA-1;

1.11.6. A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14;

1.11.7. A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2);

1.11.8. A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard);

1.11.9. A VPN IPSEc deve suportar Autenticação via certificado IKE PKI

1.11.10. Deve possuir interoperabilidade com os seguintes fabricantes: Cisco, Check Point, Juniper, Palo Alto Networks, Fortinet, SonicWall;

1.11.11. Suportar VPN em em IPv4 e IPv6, assim como tráfego IPv4 dentro de túneis IPSec IPv6

1.11.12. 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;

1.11.13. 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;

1.11.14. A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;

1.11.15. 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;

1.11.16. Atribuição de DNS nos clientes remotos de VPN;

1.11.17. 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;

1.11.18. Suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local;

1.11.19. Suportar leitura e verificação de CRL (certificate revocation list);

1.11.20. Permitir a aplicação de políticas de segurança e visibilidade para as aplicações que circulam dentro dos túneis SSL;

1.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 SCCM, Active Directory e ser descarregado diretamente desde o seu próprio portal, o qual residirá no centralizador de VPN;

1.11.22. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Antes do usuário autenticar na estação;

1.11.23. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Após autenticação do usuário na estação;

1.11.24. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Sob demanda do usuário;

1.11.25. Deverá manter uma conexão segura com o portal durante a sessão;

1.11.26. O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows XP (32 bit), Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior);

1.12. Condições operacionais

1.12.1. Alimentação / tensão de 100-240 VAC

1.12.2. Possuir fonte de alimentação redundante, ou seja, deve ser fornecido com no mínimo duas fontes.

1.12.3. As fontes de alimentação devem ser “hot swappable”, ou seja, podem ser trocadas sem a necessidade de interromper o funcionamento do equipamento.

1.12.4. Alimentação / frequência de 50/60 Hz

1.12.5. Temperatura - faixa de operação de 0º a 40º C

1.13. Suporte técnico e licenciamento

1.13.1. Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

1.13.2. Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

1.13.3. Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

1.13.4. A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados;

1.13.5. Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo possível solicitar atendimento em língua portuguesa;

1.13.6. Na apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

1.14.Serviços de configuração

1.14.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada:

1.14.2. Configurações básicas de conectividade

1.14.3. Registro e ativação de licenças Atualização de software

1.14.4. Configuração de zonas de segurança, VLANs e roteamento interno

1.14.5. Configurações dos serviços de segurança como IPS e Anti-Malware

1.14.6. Configuração de balanceamento de cagar de links WAN

1.14.7. Migração e/ou configuração de regras de firewall

1.14.8. Configuração de VPN

1.14.9. Configuração de regras de aplicação

1.14.10. Integração com base LDAP ou Radius

1.14.11. Configuração de autenticação SSO

1.14.12. Configuração de filtro de conteúdo por grupo de usuários

1.14.13. Configuração da unidade de alta disponibilidade

1.14.14. Configuração de QoS por serviços e/ou aplicações

1.14.15. Testes de funcionalidade

1.15.Treinamento

1.15.1. Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel:

1.15.2. Funcionalidades básicas do equipamento: senha de administração, hora e data, schedules e etc

1.15.3. Procedimento de registro e ativação de licenças

1.15.4. Procedimento de atualização de software

1.15.5. Zonas de segurança e objetos

1.15.6. Interfaces físicas, interfaces virtuais (VLANs) e roteamento interno

1.15.7. NAT

1.15.8. Serviços de segurança como IPS e Anti-Malware

1.15.9. Balanceamento de cagar de links WAN

1.15.10. Regras de firewall

1.15.11. VPN

1.15.12. Regras de aplicação, incluindo visibilidade das mesmas

1.15.13. Integração com base LDAP ou Radius

1.15.14. Autenticação SSO

1.15.15. Filtro de conteúdo por grupo de usuários

1.15.16. Unidade de alta disponibilidade

1.15.17. QoS por serviços e/ou aplicações

1.15.18. Instâncias ou contextos virtuais

LOTE 1 - ITEM 2

2. FIREWALL TIPO II

2.1.Características de hardware e performance

2.1.1.Throughput de, no mínimo, 33 Gbps com a funcionalidade de firewall habilitada para tráfego IPv4 e IPv6, independentemente do tamanho do pacote

2.1.2.Suporte a, no mínimo, 11M conexões simultâneas 2.1.3.Suporte a, no mínimo, 280K novas conexões por segundo 2.1.4.Throughput de, no mínimo, 18 Gbps de VPN IPSec

2.1.5.Estar licenciado para ou suportar sem o uso de licença, 20K túneis de VPN IPSEC Site-to-Site simultâneos

2.1.6.Estar licenciado para ou suportar sem o uso de licença, 20K túneis de clientes VPN IPSEC simultâneos

2.1.7.Throughput de, no mínimo, 3.6 Gbps de VPN SSL 2.1.8.Suporte a, no mínimo, 10K clientes de VPN SSL simultâneos 2.1.9.Suportar no mínimo 4.2 Gbps de throughput de IPS

2.1.10. Suportar no mínimo 4 Gbps de throughput de Inspeção SSL

2.1.11. Throughput de, no mínimo, 2.4 Gbps com as seguintes funcionalidade habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware. Caso o fabricante divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito;

2.1.12. Possuir ao menos 22 interfaces 1Gbps

2.1.13. Possuir ao menos 2 interfaces 10Gbps

2.1.14. Disco de, no mínimo, 120 GBytes para armazenamento de informações locais

2.1.15. Estar licenciado e/ou ter incluído sem custo adicional, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

2.1.16. Suporte a, no mínimo, 225 sistemas virtuais lógicos (Contextos) por appliance

2.2.Requisitos Mínimos de Funcionalidade

2.2.1.A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;

2.2.2.Deverá ser do mesmo fabricante dos itens “SOFTWARE DE GERENCIAMENTO” e “SOFTWARE DE RELATÓRIOS”, para garantir total compatibilidade;

2.2.3. 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.2.4. 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.2.5. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;

2.2.6. 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.2.7. O software deverá ser fornecido em sua versão mais atualizada;

2.2.8. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

2.2.9. O gerenciamento da solução deve suportar a interface de administração via web no próprio dispositivo de proteção de rede

2.2.10. Os dispositivos de proteção de rede devem possuir suporte a 1024 VLAN Tags 802.1q;

2.2.11. Os dispositivos de proteção de rede devem possuir suporte a agregação de links 8023ad e LACP;

2.2.12. Os dispositivos de proteção de rede devem possuir suporte a Policy based routing ou policy based forwarding;

2.2.13. Os dispositivos de proteção de rede devem possuir suporte a roteamento multicast (PIM-SM e PIM-DM);

2.2.14. Os dispositivos de proteção de rede devem possuir suporte a DHCP Relay;

2.2.15. Os dispositivos de proteção de rede devem possuir suporte a DHCP Server;

2.2.16. Os dispositivos de proteção de rede devem possuir suporte a Jumbo Frames;

2.2.17. Os dispositivos de proteção de rede devem suportar sub-interfaces ethernet logicas

2.2.18. Deve suportar NAT dinâmico (Many-to-1);

2.2.19. Deve suportar NAT dinâmico (Many-to-Many);

2.2.20. Deve suportar NAT estático (1-to-1);

2.2.21. Deve suportar NAT estático (Many-to-Many);

2.2.22. Deve suportar NAT estático bidirecional 1-to-1;

2.2.23. Deve suportar Tradução de porta (PAT);

2.2.24. Deve suportar NAT de Origem;

2.2.25. Deve suportar NAT de Destino;

2.2.26. Deve suportar NAT de Origem e NAT de Destino simultaneamente;

2.2.27. Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico;

2.2.28. Deve suportar NAT64 e NAT46;

2.2.29. Deve implementar o protocolo ECMP;

2.2.30. Deve implementar balanceamento de link por hash do IP de origem;

2.2.31. Deve implementar balanceamento de link por hash do IP de origem e destino;

2.2.32. 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.2.33. Deve permitir monitorar via SNMP falhas de hardware, uso de recursos por número elevado de sessões, conexões por segundo, número de túneis estabelecidos na VPN, CPU, memória, status do cluster, ataques e estatísticas de uso das interfaces de rede

2.2.34. Enviar log para sistemas de monitoração externos, simultaneamente;

2.2.35. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;

2.2.36. Proteção anti-spoofing;

2.2.37. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);

2.2.38. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);

2.2.39. Suportar OSPF graceful restart;

2.2.40. 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.2.41. Deve suportar Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;

2.2.42. Deve suportar 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.2.43. Deve suportar 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.2.44. Deve suportar Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;

2.2.45. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente;

2.2.46. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3;

2.2.47. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster;

2.2.48. A configuração em alta disponibilidade deve sincronizar: Sessões;

2.2.49. A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede;

2.2.50. A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs;

2.2.51. A configuração em alta disponibilidade deve sincronizar:Tabelas FIB;

2.2.52. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link;

2.2.53. Deve possuir suporte a criação de sistemas virtuais no mesmo appliance;

2.2.54. A utilização dos dispositivos em alta disponibilidade não deve impor limitações quanto à utilização de sistemas virtuais (contextos);

2.2.55. Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas;

2.2.56. O gerenciamento da solução deve suportar acesso via SSH e interface WEB (HTTPS), incluindo, mas não limitado à, exportar configuração dos sistemas virtuais (contextos) por ambas interfaces;

2.2.57. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema virtual, ou seja, isolação das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos)

2.2.58. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH 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.59. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH Decryption e protocolos de roteamento dinâmico devem operar em caráter permanente, o licenciamento do dispositivo de segurança não pode ter nenhuma relação com sua configuração de rede como, mas não limitado a, configuração de interfaces, endereços lógicos, etc , podendo ser utilizado 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.3.Controle por Política de Firewall

2.3.1.Deverá suportar controles por zona de segurança 2.3.2.Controles de políticas por porta e protocolo

2.3.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.3.4.Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança

2.3.5.Controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS)

2.3.6.Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound)

2.3.7.Deve suportar offload de certificado em inspeção de conexões SSL de entrada (Inbound); 2.3.8.Deve de-criptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2; 2.3.9.Controle de inspeção e de-criptografia de SSH por política;

2.3.10. Suporte a objetos e regras IPV6;

2.3.11. Suporte a objetos e regras multicast;

2.3.12. Deve suportar no mínimo 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 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.3.13. Suportar a atribuição de agendamento das políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente;

2.4.Controle de Aplicações

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

2.4.2.Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos

2.4.3.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;

2.4.4.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;

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

2.4.6.Deve 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;

2.4.7.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 utilização da rede Tor

2.4.8.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.4.9.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

2.4.10. Identificar o uso de táticas evasivas via comunicações criptografadas;

2.4.11. Atualizar a base de assinaturas de aplicações automaticamente;

2.4.12. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos do LDAP/AD;

2.4.13. 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.4.14. 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.4.15. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos;

2.4.16. 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.4.17. 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.4.18. 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: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS- SQL, IMAP, DNS, LDAP, RTSP e SSL

2.4.19. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;

2.4.20. Deve alertar o usuário quando uma aplicação for bloqueada;

2.4.21. Deve possibilitar que o controle de portas seja aplicado para todas as aplicações;

2.4.22. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc) possuindo granularidade de controle/políticas para os mesmos;

2.4.23. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos;

2.4.24. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo;

2.4.25. Deve possibilitar a diferenciação de aplicações Proxies (psiphon3, freegate, etc) possuindo granularidade de controle/políticas para os mesmos;

2.4.26. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como:

2.4.27. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client- Server, Browse Based, Network Protocol, etc)

2.4.28. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação

2.4.29. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Categoria da aplicação

2.4.30. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Aplicações que usem técnicas evasivas, utilizadas por malwares como uso excessivo de banda, tunelamento de tráfego ou transferência de arquivos, etc;

2.5.Prevenção de Ameaças

2.5.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.5.2.Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);

0.0.0.Xx 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 atualizações ou que não haja contrato de garantia de software com o fabricante;

2.5.4.Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade ativo/ativo e ativo/passivo;

2.5.5.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;

0.0.0.Xx assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;

2.5.7.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

2.5.8.Exceções por IP de origem ou de destino devem ser possíveis nas regras e assinatura a assinatura; 2.5.9.Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a

criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens

2.5.10. Deve permitir o bloqueio de vulnerabilidades

2.5.11. Deve permitir o bloqueio de exploits conhecidos

2.5.12. Deve incluir proteção contra ataques de negação de serviços

2.5.13. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de padrões de estado de conexões;

2.5.14. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de decodificação de protocolo;

2.5.15. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise para detecção de anomalias de protocolo;

2.5.16. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise heurística;

2.5.17. Deverá possuir o seguinte mecanismos de inspeção de IPS: IP Defragmentation;

2.5.18. Deverá possuir o seguinte mecanismos de inspeção de IPS: Remontagem de pacotes de TCP;

2.5.19. Deverá possuir o seguinte mecanismos de inspeção de IPS: Bloqueio de pacotes malformados

2.5.20. Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood, etc;

2.5.21. Detectar e bloquear a origem de portscans;

2.5.22. Bloquear ataques efetuados por worms conhecidos, permitindo ao administrador acrescentar novos padrões;

2.5.23. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;

2.5.24. Possuir assinaturas para bloqueio de ataques de buffer overflow;

2.5.25. Deverá possibilitar a criação de assinaturas customizadas pela interface gráfica do produto;

2.5.26. 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.5.27. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;

2.5.28. Identificar e bloquear comunicação com botnets;

2.5.29. 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.5.30. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS e controle de aplicação;

2.5.31. Deve permitir que na captura de pacotes por assinaturas de IPS seja definido o número de pacotes a serem capturados ou permitir capturar o pacote que deu origem ao alerta assim como seu contexto, facilitando a análise forense e identificação de falsos positivos

2.5.32. Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas;

2.5.33. Os eventos devem identificar o país de onde partiu a ameaça;

2.5.34. Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms

2.5.35. Proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos

2.5.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, zonas de segurança, 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.6.Filtro de URL

2.6.1.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 ou zonas de segurança;

2.6.3.Deve possuir 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, Active Directory e base de dados local;

2.6.4.Suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL; 2.6.5.Deve possuir base ou cache de URLs local no appliance ou em nuvem do próprio fabricante,

evitando delay de comunicação/validação das URLs; 2.6.6.Possuir pelo menos 60 categorias de URLs;

2.6.7.Deve possuir a função de exclusão de URLs do bloqueio, por categoria;

2.6.8.Permitir a customização de página de bloqueio;

2.6.9.Permitir 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.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 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, suportando single sign-on, essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à, utilização de sistemas virtuais, segmentos de rede, etc;

2.7.4.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.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 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.7.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.8.Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;

2.7.9.Permitir integração com tokens para autenticação dos usuários, incluindo, mas não limitado a acesso a internet e gerenciamento da solução

2.7.10. Prover no mínimo um token nativamente, possibilitando autenticação de duplo fator

2.8.QoS e Traffic Shaping

2.8.1.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem; 2.8.2.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino; 2.8.3.Suportar a criação de políticas de QoS e Traffic Shaping por porta;

2.8.4.O QoS deve possibilitar a definição de classes por Banda Garantida;

2.8.5.O QoS deve possibilitar a definição de classes por Banda Máxima;

2.8.6.O QoS deve possibilitar a definição de classes por Fila de Prioridade 2.8.7.Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping; 2.8.8.Deve suportar QOS (traffic-shapping), em interface agregadas ou redundantes;

2.9.Filtro de Dados

2.9.1.Suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

2.9.2.Suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

2.9.3.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.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;

2.11.5. A VPN IPSEc deve suportar Autenticação MD5 e SHA-1;

2.11.6. A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14;

2.11.7. A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2);

2.11.8. A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard);

2.11.9. A VPN IPSEc deve suportar Autenticação via certificado IKE PKI

2.11.10. Deve possuir interoperabilidade com os seguintes fabricantes: Cisco, Check Point, Juniper, Palo Alto Networks, Fortinet, SonicWall;

2.11.11. Suportar VPN em em IPv4 e IPv6, assim como tráfego IPv4 dentro de túneis IPSec IPv6

2.11.12. 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.13. 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;

2.11.14. A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;

2.11.15. 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.16. Atribuição de DNS nos clientes remotos de VPN;

2.11.17. 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.18. Suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local;

2.11.19. Suportar leitura e verificação de CRL (certificate revocation list);

2.11.20. Permitir 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 SCCM, Active Directory e ser descarregado diretamente desde o seu próprio portal, o qual residirá no centralizador de VPN;

2.11.22. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Antes do usuário autenticar na estação;

2.11.23. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Após autenticação do usuário na estação;

2.11.24. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Sob demanda do usuário;

2.11.25. Deverá manter uma conexão segura com o portal durante a sessão;

2.11.26. O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows XP (32 bit), Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior);

2.12. Condições operacionais

2.12.1. Alimentação / tensão de 100-240 VAC

2.12.2. Possuir fonte de alimentação redundante, ou seja, deve ser fornecido com no mínimo duas fontes.

2.12.3. As fontes de alimentação devem ser “hot swappable”, ou seja, podem ser trocadas sem a necessidade de interromper o funcionamento do equipamento.

2.12.4. Alimentação / frequência de 50/60 Hz

2.12.5. Temperatura - faixa de operação de 0º a 40º C

2.13. Suporte técnico e licenciamento

2.13.1. Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

2.13.2. Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

2.13.3. Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

2.13.4. A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados;

2.13.5. Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo possível solicitar atendimento em língua portuguesa;

2.13.6. Na apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

2.14.Serviços de configuração

2.14.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada:

2.14.2. Configurações básicas de conectividade

2.14.3. Registro e ativação de licenças Atualização de software

2.14.4. Configuração de zonas de segurança, VLANs e roteamento interno

2.14.5. Configurações dos serviços de segurança como IPS e Anti-Malware

2.14.6. Configuração de balanceamento de cagar de links WAN

2.14.7. Migração e/ou configuração de regras de firewall

2.14.8. Configuração de VPN

2.14.9. Configuração de regras de aplicação

2.14.10. Integração com base LDAP ou Radius

2.14.11. Configuração de autenticação SSO

2.14.12. Configuração de filtro de conteúdo por grupo de usuários

2.14.13. Configuração da unidade de alta disponibilidade

2.14.14. Configuração de QoS por serviços e/ou aplicações

2.14.15. Testes de funcionalidade

2.15.Treinamento

2.15.1. Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel:

2.15.2. Funcionalidades básicas do equipamento: senha de administração, hora e data, schedules e etc

2.15.3. Procedimento de registro e ativação de licenças

2.15.4. Procedimento de atualização de software

2.15.5. Zonas de segurança e objetos

2.15.6. Interfaces físicas, interfaces virtuais (VLANs) e roteamento interno

2.15.7. NAT

2.15.8. Serviços de segurança como IPS e Anti-Malware

2.15.9. Balanceamento de cagar de links WAN

2.15.10. Regras de firewall

2.15.11. VPN

2.15.12. Regras de aplicação, incluindo visibilidade das mesmas

2.15.13. Integração com base LDAP ou Radius

2.15.14. Autenticação SSO

2.15.15. Filtro de conteúdo por grupo de usuários

2.15.16. Unidade de alta disponibilidade

2.15.17. QoS por serviços e/ou aplicações

2.15.18. Instâncias ou contextos virtuais

LOTE 1 - ITEM 3

3. FIREWALL TIPO III

3.1.Características de hardware e performance

3.1.1.Throughput de, no mínimo, 30 Gbps com a funcionalidade de firewall habilitada para tráfego IPv4 e IPv6, independentemente do tamanho do pacote

3.1.2.Suporte a, no mínimo, 10M conexões simultâneas 3.1.3.Suporte a, no mínimo, 280K novas conexões por segundo 3.1.4.Throughput de, no mínimo, 19 Gbps de VPN IPSec

3.1.5.Estar licenciado para ou suportar sem o uso de licença, 2K túneis de VPN IPSEC Site-to-Site simultâneos

3.1.6.Estar licenciado para ou suportar sem o uso de licença, 20K túneis de clientes VPN IPSEC simultâneos

3.1.7.Throughput de, no mínimo, 3.6 Gbps de VPN SSL 3.1.8.Suporte a, no mínimo, 10K clientes de VPN SSL simultâneos 3.1.9.Suportar no mínimo 4.2 Gbps de throughput de IPS

3.1.10. Suportar no mínimo 4 Gbps de throughput de Inspeção SSL

3.1.11. Throughput de, no mínimo, 2.4 Gbps com as seguintes funcionalidade habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware. Caso o fabricante divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito;

3.1.12. Possuir ao menos 22 interfaces 1Gbps

3.1.13. Possuir ao menos 2 interfaces 10Gbps

3.1.14. Disco de, no mínimo, 256 GBytes para armazenamento de informações locais

3.1.15. Estar licenciado e/ou ter incluído sem custo adicional, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

3.1.16. Suporte a, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

3.2.Requisitos Mínimos de Funcionalidade

3.2.1.A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;

3.2.2.Deverá ser do mesmo fabricante dos itens “SOFTWARE DE GERENCIAMENTO” e “SOFTWARE DE RELATÓRIOS”, para garantir total compatibilidade;

3.2.3. 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;

3.2.4. 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;

3.2.5. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;

3.2.6. 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;

3.2.7. O software deverá ser fornecido em sua versão mais atualizada;

3.2.8. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

3.2.9. O gerenciamento da solução deve suportar a interface de administração via web no próprio dispositivo de proteção de rede

3.2.10. Os dispositivos de proteção de rede devem possuir suporte a 1024 VLAN Tags 802.1q;

3.2.11. Os dispositivos de proteção de rede devem possuir suporte a agregação de links 8023ad e LACP;

3.2.12. Os dispositivos de proteção de rede devem possuir suporte a Policy based routing ou policy based forwarding;

3.2.13. Os dispositivos de proteção de rede devem possuir suporte a roteamento multicast (PIM-SM e PIM-DM);

3.2.14. Os dispositivos de proteção de rede devem possuir suporte a DHCP Relay;

3.2.15. Os dispositivos de proteção de rede devem possuir suporte a DHCP Server;

3.2.16. Os dispositivos de proteção de rede devem possuir suporte a Jumbo Frames;

3.2.17. Os dispositivos de proteção de rede devem suportar sub-interfaces ethernet logicas

3.2.18. Deve suportar NAT dinâmico (Many-to-1);

3.2.19. Deve suportar NAT dinâmico (Many-to-Many);

3.2.20. Deve suportar NAT estático (1-to-1);

3.2.21. Deve suportar NAT estático (Many-to-Many);

3.2.22. Deve suportar NAT estático bidirecional 1-to-1;

3.2.23. Deve suportar Tradução de porta (PAT);

3.2.24. Deve suportar NAT de Origem;

3.2.25. Deve suportar NAT de Destino;

3.2.26. Deve suportar NAT de Origem e NAT de Destino simultaneamente;

3.2.27. Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico;

3.2.28. Deve suportar NAT64 e NAT46;

3.2.29. Deve implementar o protocolo ECMP;

3.2.30. Deve implementar balanceamento de link por hash do IP de origem;

3.2.31. Deve implementar balanceamento de link por hash do IP de origem e destino;

3.2.32. 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;

3.2.33. Deve permitir monitorar via SNMP falhas de hardware, uso de recursos por número elevado de sessões, conexões por segundo, número de túneis estabelecidos na VPN, CPU, memória, status do cluster, ataques e estatísticas de uso das interfaces de rede

3.2.34. Enviar log para sistemas de monitoração externos, simultaneamente;

3.2.35. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;

3.2.36. Proteção anti-spoofing;

3.2.37. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);

3.2.38. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);

3.2.39. Suportar OSPF graceful restart;

3.2.40. 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);

3.2.41. Deve suportar Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;

3.2.42. Deve suportar 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;

3.2.43. Deve suportar 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;

3.2.44. Deve suportar Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;

3.2.45. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente;

3.2.46. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3;

3.2.47. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster;

3.2.48. A configuração em alta disponibilidade deve sincronizar: Sessões;

3.2.49. A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede;

3.2.50. A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs;

3.2.51. A configuração em alta disponibilidade deve sincronizar:Tabelas FIB;

3.2.52. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link;

3.2.53. Deve possuir suporte à criação de sistemas virtuais no mesmo appliance;

3.2.54. A utilização dos dispositivos em alta disponibilidade não deve impor limitações quanto à utilização de sistemas virtuais (contextos);

3.2.55. Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas;

3.2.56. O gerenciamento da solução deve suportar acesso via SSH e interface WEB (HTTPS), incluindo, mas não limitado à, exportar configuração dos sistemas virtuais (contextos) por ambas interfaces;

3.2.57. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema virtual, ou seja, isolação das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos)

3.2.58. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH 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;

3.2.59. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH Decryption e protocolos de roteamento dinâmico devem operar em caráter permanente, o licenciamento do dispositivo de segurança não pode ter nenhuma relação com sua configuração de rede como, mas não limitado a, configuração de interfaces, endereços lógicos, etc , podendo ser utilizado 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;

3.3.Controle por Política de Firewall

3.3.1.Deverá suportar controles por zona de segurança 3.3.2.Controles de políticas por porta e protocolo

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

3.3.4.Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança 3.3.5.Controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS)

3.3.6.Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound)

3.3.7.Deve suportar offload de certificado em inspeção de conexões SSL de entrada (Inbound); 3.3.8.Deve de-criptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2; 3.3.9.Controle de inspeção e de-criptografia de SSH por política;

3.3.10. Suporte a objetos e regras IPV6;

3.3.11. Suporte a objetos e regras multicast;

3.3.12. Deve suportar no mínimo 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 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;

3.3.13. Suportar a atribuição de agendamento das políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente;

3.4.Controle de Aplicações

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

3.4.2.Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos

3.4.3.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;

3.4.4.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;

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

3.4.6.Deve 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;

3.4.7.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 utilização da rede Tor

3.4.8.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;

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

3.4.10. Identificar o uso de táticas evasivas via comunicações criptografadas;

3.4.11. Atualizar a base de assinaturas de aplicações automaticamente;

3.4.12. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos do LDAP/AD;

3.4.13. 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;

3.4.14. 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;

3.4.15. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos;

3.4.16. Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;

3.4.17. 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;

3.4.18. 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: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS- SQL, IMAP, DNS, LDAP, RTSP e SSL

3.4.19. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;

3.4.20. Deve alertar o usuário quando uma aplicação for bloqueada;

3.4.21. Deve possibilitar que o controle de portas seja aplicado para todas as aplicações;

3.4.22. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc) possuindo granularidade de controle/políticas para os mesmos;

3.4.23. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos;

3.4.24. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo;

3.4.25. Deve possibilitar a diferenciação de aplicações Proxies (psiphon3, freegate, etc) possuindo granularidade de controle/políticas para os mesmos;

3.4.26. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como:

3.4.27. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client- Server, Browse Based, Network Protocol, etc)

3.4.28. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação

3.4.29. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Categoria da aplicação

3.4.30. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Aplicações que usem técnicas evasivas, utilizadas por malwares como uso excessivo de banda, tunelamento de tráfego ou transferência de arquivos, etc;

3.5.Prevenção de Ameaças

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

3.5.2.Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);

0.0.0.Xx 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 atualizações ou que não haja contrato de garantia de software com o fabricante;

3.5.4.Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade ativo/ativo e ativo/passivo;

3.5.5.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;

0.0.0.Xx assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;

3.5.7.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

3.5.8.Exceções por IP de origem ou de destino devem ser possíveis nas regras e assinatura a assinatura; 3.5.9.Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a

criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens

3.5.10. Deve permitir o bloqueio de vulnerabilidades

3.5.11. Deve permitir o bloqueio de exploits conhecidos

3.5.12. Deve incluir proteção contra ataques de negação de serviços

3.5.13. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de padrões de estado de conexões;

3.5.14. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de decodificação de protocolo;

3.5.15. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise para detecção de anomalias de protocolo;

3.5.16. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise heurística;

3.5.17. Deverá possuir o seguinte mecanismos de inspeção de IPS: IP Defragmentation;

3.5.18. Deverá possuir o seguinte mecanismos de inspeção de IPS: Remontagem de pacotes de TCP;

3.5.19. Deverá possuir o seguinte mecanismos de inspeção de IPS: Bloqueio de pacotes malformados

3.5.20. Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood, etc;

3.5.21. Detectar e bloquear a origem de portscans;

3.5.22. Bloquear ataques efetuados por worms conhecidos, permitindo ao administrador acrescentar novos padrões;

3.5.23. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;

3.5.24. Possuir assinaturas para bloqueio de ataques de buffer overflow;

3.5.25. Deverá possibilitar a criação de assinaturas customizadas pela interface gráfica do produto;

3.5.26. 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;

3.5.27. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;

3.5.28. Identificar e bloquear comunicação com botnets;

3.5.29. 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;

3.5.30. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS e controle de aplicação;

3.5.31. Deve permitir que na captura de pacotes por assinaturas de IPS seja definido o número de pacotes a serem capturados ou permitir capturar o pacote que deu origem ao alerta assim como seu contexto, facilitando a análise forense e identificação de falsos positivos

3.5.32. Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas;

3.5.33. Os eventos devem identificar o país de onde partiu a ameaça;

3.5.34. Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms

3.5.35. Proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos

3.5.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, zonas de segurança, 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

3.6.Filtro de URL

3.6.1.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);

3.6.2.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

3.6.3.Deve possuir 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, Active Directory e base de dados local;

3.6.4.Suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL; 3.6.5.Deve possuir base ou cache de URLs local no appliance ou em nuvem do próprio fabricante,

evitando delay de comunicação/validação das URLs; 3.6.6.Possuir pelo menos 60 categorias de URLs;

3.6.7.Deve possuir a função de exclusão de URLs do bloqueio, por categoria; 3.6.8.Permitir a customização de página de bloqueio;

3.6.9.Permitir 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);

3.7.Identificação de Usuários

3.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;

3.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;

3.7.3.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, suportando single sign-on, essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à, utilização de sistemas virtuais, segmentos de rede, etc;

3.7.4.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;

3.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;

3.7.6.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);

3.7.7.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;

3.7.8.Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;

3.7.9.Permitir integração com tokens para autenticação dos usuários, incluindo, mas não limitado a acesso a internet e gerenciamento da solução

3.7.10. Prover no mínimo um token nativamente, possibilitando autenticação de duplo fator

3.8.QoS e Traffic Shaping

3.8.1.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem; 3.8.2.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino; 3.8.3.Suportar a criação de políticas de QoS e Traffic Shaping por porta;

3.8.4.O QoS deve possibilitar a definição de classes por Banda Garantida;

3.8.5.O QoS deve possibilitar a definição de classes por Banda Máxima;

3.8.6.O QoS deve possibilitar a definição de classes por Fila de Prioridade 3.8.7.Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping; 3.8.8.Deve suportar QOS (traffic-shapping), em interface agregadas ou redundantes;

3.9.Filtro de Dados

3.9.1.Suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

3.9.2.Suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

3.9.3.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;

3.10. Geo Localização

3.10.1. Suportar a criação de políticas por geo-localização, permitindo o trafego de determinado Pais/Países sejam bloqueados;

3.10.2. Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos;

3.10.3. Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas;

3.11. VPN

3.11.1. Suportar VPN Site-to-Site e Cliente-To-Site;

3.11.2. Suportar IPSec VPN;

3.11.3. Suportar SSL VPN;

3.11.4. A VPN IPSEc deve suportar 3DES;

3.11.5. A VPN IPSEc deve suportar Autenticação MD5 e SHA-1;

3.11.6. A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14;

3.11.7. A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2);

3.11.8. A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard);

3.11.9. A VPN IPSEc deve suportar Autenticação via certificado IKE PKI

3.11.10. Deve possuir interoperabilidade com os seguintes fabricantes: Cisco, Check Point, Juniper, Palo Alto Networks, Fortinet, SonicWall;

3.11.11. Suportar VPN em em IPv4 e IPv6, assim como tráfego IPv4 dentro de túneis IPSec IPv6

3.11.12. 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;

3.11.13. 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;

3.11.14. A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;

3.11.15. 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;

3.11.16. Atribuição de DNS nos clientes remotos de VPN;

3.11.17. 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;

3.11.18. Suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local;

3.11.19. Suportar leitura e verificação de CRL (certificate revocation list);

3.11.20. Permitir a aplicação de políticas de segurança e visibilidade para as aplicações que circulam dentro dos túneis SSL;

3.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 SCCM, Active Directory e ser descarregado diretamente desde o seu próprio portal, o qual residirá no centralizador de VPN;

3.11.22. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Antes do usuário autenticar na estação;

3.11.23. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Após autenticação do usuário na estação;

3.11.24. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Sob demanda do usuário;

3.11.25. Deverá manter uma conexão segura com o portal durante a sessão;

3.11.26. O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows XP (32 bit), Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior);

3.12. Condições operacionais

3.12.1. Alimentação / tensão de 100-240 VAC

3.12.2. Possuir fonte de alimentação redundante, ou seja, deve ser fornecido com no mínimo duas fontes.

3.12.3. As fontes de alimentação devem ser “hot swappable”, ou seja, podem ser trocadas sem a necessidade de interromper o funcionamento do equipamento.

3.12.4. Alimentação / frequência de 50/60 Hz

3.12.5. Temperatura - faixa de operação de 0º a 40º C

3.13. Suporte técnico e licenciamento

3.13.1. Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

3.13.2. Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

3.13.3. Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

3.13.4. A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados;

3.13.5. Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo possível solicitar atendimento em língua portuguesa;

3.13.6. Na apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

3.14.Serviços de configuração

3.14.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada:

3.14.2. Configurações básicas de conectividade

3.14.3. Registro e ativação de licenças Atualização de software

3.14.4. Configuração de zonas de segurança, VLANs e roteamento interno

3.14.5. Configurações dos serviços de segurança como IPS e Anti-Malware

3.14.6. Configuração de balanceamento de cagar de links WAN

3.14.7. Migração e/ou configuração de regras de firewall

3.14.8. Configuração de VPN

3.14.9. Configuração de regras de aplicação

3.14.10. Integração com base LDAP ou Radius

3.14.11. Configuração de autenticação SSO

3.14.12. Configuração de filtro de conteúdo por grupo de usuários

3.14.13. Configuração da unidade de alta disponibilidade

3.14.14. Configuração de QoS por serviços e/ou aplicações

3.14.15. Testes de funcionalidade

3.15.Treinamento

3.15.1. Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel:

3.15.2. Funcionalidades básicas do equipamento: senha de administração, hora e data, schedules e etc

3.15.3. Procedimento de registro e ativação de licenças

3.15.4. Procedimento de atualização de software

3.15.5. Zonas de segurança e objetos

3.15.6. Interfaces físicas, interfaces virtuais (VLANs) e roteamento interno

3.15.7. NAT

3.15.8. Serviços de segurança como IPS e Anti-Malware

3.15.9. Balanceamento de cagar de links WAN

3.15.10. Regras de firewall

3.15.11. VPN

3.15.12. Regras de aplicação, incluindo visibilidade das mesmas

3.15.13. Integração com base LDAP ou Radius

3.15.14. Autenticação SSO

3.15.15. Filtro de conteúdo por grupo de usuários

3.15.16. Unidade de alta disponibilidade

3.15.17. QoS por serviços e/ou aplicações

3.15.18. Instâncias ou contextos virtuais

LOTE 1 - ITEM 4

4. FIREWALL TIPO IV

4.1.Características de hardware e performance

4.1.1.Throughput de, no mínimo, 24 Gbps com a funcionalidade de firewall habilitada para tráfego IPv4 e IPv6, independentemente do tamanho do pacote

4.1.2.Suporte a, no mínimo, 5M conexões simultâneas 4.1.3.Suporte a, no mínimo, 270K novas conexões por segundo 4.1.4.Throughput de, no mínimo, 16 Gbps de VPN IPSec

4.1.5.Estar licenciado para ou suportar sem o uso de licença, 2K túneis de VPN IPSEC Site-to-Site simultâneos

4.1.6.Estar licenciado para ou suportar sem o uso de licença, 10K túneis de clientes VPN IPSEC simultâneos

4.1.7.Throughput de, no mínimo, 2.2 Gbps de VPN SSL 4.1.8.Suporte a, no mínimo, 5K clientes de VPN SSL simultâneos 4.1.9.Suportar no mínimo 4 Gbps de throughput de IPS

4.1.10. Suportar no mínimo 3.5 Gbps de throughput de Inspeção SSL

4.1.11. Throughput de, no mínimo, 2.4 Gbps com as seguintes funcionalidade habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware. Caso o fabricante

divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito;

4.1.12. Possuir ao menos 16 interfaces 1Gbps

4.1.13. Possuir ao menos 2 interfaces 10Gbps

4.1.14. Disco de, no mínimo, 120 GBytes para armazenamento de informações locais

4.1.15. Estar licenciado e/ou ter incluído sem custo adicional, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

4.1.16. Suporte a, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

4.2.Requisitos Mínimos de Funcionalidade

4.2.1.A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;

4.2.2.Deverá ser do mesmo fabricante dos itens “SOFTWARE DE GERENCIAMENTO” e “SOFTWARE DE RELATÓRIOS”, para garantir total compatibilidade;

4.2.3. 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;

4.2.4. 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;

4.2.5. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;

4.2.6. 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;

4.2.7. O software deverá ser fornecido em sua versão mais atualizada;

4.2.8. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

4.2.9. O gerenciamento da solução deve suportar a interface de administração via web no próprio dispositivo de proteção de rede

4.2.10. Os dispositivos de proteção de rede devem possuir suporte a 1024 VLAN Tags 802.1q;

4.2.11. Os dispositivos de proteção de rede devem possuir suporte a agregação de links 8023ad e LACP;

4.2.12. Os dispositivos de proteção de rede devem possuir suporte a Policy based routing ou policy based forwarding;

4.2.13. Os dispositivos de proteção de rede devem possuir suporte a roteamento multicast (PIM-SM e PIM-DM);

4.2.14. Os dispositivos de proteção de rede devem possuir suporte a DHCP Relay;

4.2.15. Os dispositivos de proteção de rede devem possuir suporte a DHCP Server;

4.2.16. Os dispositivos de proteção de rede devem possuir suporte a Jumbo Frames;

4.2.17. Os dispositivos de proteção de rede devem suportar sub-interfaces ethernet logicas

4.2.18. Deve suportar NAT dinâmico (Many-to-1);

4.2.19. Deve suportar NAT dinâmico (Many-to-Many);

4.2.20. Deve suportar NAT estático (1-to-1);

4.2.21. Deve suportar NAT estático (Many-to-Many);

4.2.22. Deve suportar NAT estático bidirecional 1-to-1;

4.2.23. Deve suportar Tradução de porta (PAT);

4.2.24. Deve suportar NAT de Origem;

4.2.25. Deve suportar NAT de Destino;

4.2.26. Deve suportar NAT de Origem e NAT de Destino simultaneamente;

4.2.27. Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico;

4.2.28. Deve suportar NAT64 e NAT46;

4.2.29. Deve implementar o protocolo ECMP;

4.2.30. Deve implementar balanceamento de link por hash do IP de origem;

4.2.31. Deve implementar balanceamento de link por hash do IP de origem e destino;

4.2.32. 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;

4.2.33. Deve permitir monitorar via SNMP falhas de hardware, uso de recursos por número elevado de sessões, conexões por segundo, número de túneis estabelecidos na VPN, CPU, memória, status do cluster, ataques e estatísticas de uso das interfaces de rede

4.2.34. Enviar log para sistemas de monitoração externos, simultaneamente;

4.2.35. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;

4.2.36. Proteção anti-spoofing;

4.2.37. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);

4.2.38. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);

4.2.39. Suportar OSPF graceful restart;

4.2.40. 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);

4.2.41. Deve suportar Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;

4.2.42. Deve suportar 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;

4.2.43. Deve suportar 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;

4.2.44. Deve suportar Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;

4.2.45. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente;

4.2.46. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3;

4.2.47. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster;

4.2.48. A configuração em alta disponibilidade deve sincronizar: Sessões;

4.2.49. A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede;

4.2.50. A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs;

4.2.51. A configuração em alta disponibilidade deve sincronizar:Tabelas FIB;

4.2.52. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link;

4.2.53. Deve possuir suporte a criação de sistemas virtuais no mesmo appliance;

4.2.54. A utilização dos dispositivos em alta disponibilidade não deve impor limitações quanto à utilização de sistemas virtuais (contextos);

4.2.55. Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas;

4.2.56. O gerenciamento da solução deve suportar acesso via SSH e interface WEB (HTTPS), incluindo, mas não limitado à, exportar configuração dos sistemas virtuais (contextos) por ambas interfaces;

4.2.57. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema virtual, ou seja, isolação das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos)

4.2.58. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH 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;

4.2.59. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH Decryption e protocolos de roteamento dinâmico devem operar em caráter permanente, o licenciamento do dispositivo de segurança não pode ter nenhuma relação com sua configuração de rede como, mas não limitado a, configuração de interfaces, endereços lógicos, etc , podendo ser utilizado 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;

4.3.Controle por Política de Firewall

4.3.1.Deverá suportar controles por zona de segurança 4.3.2.Controles de políticas por porta e protocolo

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

4.3.4.Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança 4.3.5.Controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS)

4.3.6.Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound)

4.3.7.Deve suportar offload de certificado em inspeção de conexões SSL de entrada (Inbound); 4.3.8.Deve de-criptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2; 4.3.9.Controle de inspeção e de-criptografia de SSH por política;

4.3.10. Suporte a objetos e regras IPV6;

4.3.11. Suporte a objetos e regras multicast;

4.3.12. Deve suportar no mínimo 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 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;

4.3.13. Suportar a atribuição de agendamento das políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente;

4.4.Controle de Aplicações

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

4.4.2.Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos

4.4.3.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;

4.4.4.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;

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

4.4.6.Deve 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;

4.4.7.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 utilização da rede Tor

4.4.8.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;

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

4.4.10. Identificar o uso de táticas evasivas via comunicações criptografadas;

4.4.11. Atualizar a base de assinaturas de aplicações automaticamente;

4.4.12. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos do LDAP/AD;

4.4.13. 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;

4.4.14. 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;

4.4.15. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos;

4.4.16. Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;

4.4.17. 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;

4.4.18. 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: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS- SQL, IMAP, DNS, LDAP, RTSP e SSL

4.4.19. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;

4.4.20. Deve alertar o usuário quando uma aplicação for bloqueada;

4.4.21. Deve possibilitar que o controle de portas seja aplicado para todas as aplicações;

4.4.22. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc) possuindo granularidade de controle/políticas para os mesmos;

4.4.23. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos;

4.4.24. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo;

4.4.25. Deve possibilitar a diferenciação de aplicações Proxies (psiphon3, freegate, etc) possuindo granularidade de controle/políticas para os mesmos;

4.4.26. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como:

4.4.27. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client- Server, Browse Based, Network Protocol, etc)

4.4.28. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação

4.4.29. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Categoria da aplicação

4.4.30. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Aplicações que usem técnicas evasivas, utilizadas por malwares como uso excessivo de banda, tunelamento de tráfego ou transferência de arquivos, etc;

4.5.Prevenção de Ameaças

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

4.5.2.Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);

0.0.0.Xx 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 atualizações ou que não haja contrato de garantia de software com o fabricante;

4.5.4.Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade ativo/ativo e ativo/passivo;

4.5.5.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;

0.0.0.Xx assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;

4.5.7.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

4.5.8.Exceções por IP de origem ou de destino devem ser possíveis nas regras e assinatura a assinatura;

4.5.9.Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens

4.5.10. Deve permitir o bloqueio de vulnerabilidades

4.5.11. Deve permitir o bloqueio de exploits conhecidos

4.5.12. Deve incluir proteção contra ataques de negação de serviços

4.5.13. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de padrões de estado de conexões;

4.5.14. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de decodificação de protocolo;

4.5.15. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise para detecção de anomalias de protocolo;

4.5.16. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise heurística;

4.5.17. Deverá possuir o seguinte mecanismos de inspeção de IPS: IP Defragmentation;

4.5.18. Deverá possuir o seguinte mecanismos de inspeção de IPS: Remontagem de pacotes de TCP;

4.5.19. Deverá possuir o seguinte mecanismos de inspeção de IPS: Bloqueio de pacotes malformados

4.5.20. Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood, etc;

4.5.21. Detectar e bloquear a origem de portscans;

4.5.22. Bloquear ataques efetuados por worms conhecidos, permitindo ao administrador acrescentar novos padrões;

4.5.23. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;

4.5.24. Possuir assinaturas para bloqueio de ataques de buffer overflow;

4.5.25. Deverá possibilitar a criação de assinaturas customizadas pela interface gráfica do produto;

4.5.26. 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;

4.5.27. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;

4.5.28. Identificar e bloquear comunicação com botnets;

4.5.29. 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;

4.5.30. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS e controle de aplicação;

4.5.31. Deve permitir que na captura de pacotes por assinaturas de IPS seja definido o número de pacotes a serem capturados ou permitir capturar o pacote que deu origem ao alerta assim como seu contexto, facilitando a análise forense e identificação de falsos positivos

4.5.32. Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas;

4.5.33. Os eventos devem identificar o país de onde partiu a ameaça;

4.5.34. Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms

4.5.35. Proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos

4.5.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, zonas de segurança, 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

4.6.Filtro de URL

4.6.1.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);

4.6.2.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

4.6.3.Deve possuir 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, Active Directory e base de dados local;

4.6.4.Suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL;

4.6.5.Deve possuir base ou cache de URLs local no appliance ou em nuvem do próprio fabricante, evitando delay de comunicação/validação das URLs;

4.6.6.Possuir pelo menos 60 categorias de URLs;

4.6.7.Deve possuir a função de exclusão de URLs do bloqueio, por categoria; 4.6.8.Permitir a customização de página de bloqueio;

4.6.9.Permitir 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);

4.7.Identificação de Usuários

4.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;

4.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;

4.7.3.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, suportando single sign-on, essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à, utilização de sistemas virtuais, segmentos de rede, etc;

4.7.4.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;

4.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;

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

4.7.7.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;

4.7.8.Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;

4.7.9.Permitir integração com tokens para autenticação dos usuários, incluindo, mas não limitado a acesso a internet e gerenciamento da solução

4.7.10. Prover no mínimo um token nativamente, possibilitando autenticação de duplo fator

4.8.QoS e Traffic Shaping

4.8.1.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem; 4.8.2.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino; 4.8.3.Suportar a criação de políticas de QoS e Traffic Shaping por porta;

4.8.4.O QoS deve possibilitar a definição de classes por Banda Garantida;

4.8.5.O QoS deve possibilitar a definição de classes por Banda Máxima;

4.8.6.O QoS deve possibilitar a definição de classes por Fila de Prioridade 4.8.7.Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping; 4.8.8.Deve suportar QOS (traffic-shapping), em interface agregadas ou redundantes;

4.9.Filtro de Dados

4.9.1.Suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

4.9.2.Suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

4.9.3.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;

4.10. Geo Localização

4.10.1. Suportar a criação de políticas por geo-localização, permitindo o trafego de determinado Pais/Países sejam bloqueados;

4.10.2. Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos;

4.10.3. Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas;

4.11. VPN

4.11.1. Suportar VPN Site-to-Site e Cliente-To-Site;

4.11.2. Suportar IPSec VPN;

4.11.3. Suportar SSL VPN;

4.11.4. A VPN IPSEc deve suportar 3DES;

4.11.5. A VPN IPSEc deve suportar Autenticação MD5 e SHA-1;

4.11.6. A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14;

4.11.7. A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2);

4.11.8. A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard);

4.11.9. A VPN IPSEc deve suportar Autenticação via certificado IKE PKI

4.11.10. Deve possuir interoperabilidade com os seguintes fabricantes: Cisco, Check Point, Juniper, Palo Alto Networks, Fortinet, SonicWall;

4.11.11. Suportar VPN em em IPv4 e IPv6, assim como tráfego IPv4 dentro de túneis IPSec IPv6

4.11.12. 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;

4.11.13. 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;

4.11.14. A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;

4.11.15. 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;

4.11.16. Atribuição de DNS nos clientes remotos de VPN;

4.11.17. 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;

4.11.18. Suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local;

4.11.19. Suportar leitura e verificação de CRL (certificate revocation list);

4.11.20. Permitir a aplicação de políticas de segurança e visibilidade para as aplicações que circulam dentro dos túneis SSL;

4.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 SCCM, Active Directory e ser descarregado diretamente desde o seu próprio portal, o qual residirá no centralizador de VPN;

4.11.22. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Antes do usuário autenticar na estação;

4.11.23. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Após autenticação do usuário na estação;

4.11.24. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Sob demanda do usuário;

4.11.25. Deverá manter uma conexão segura com o portal durante a sessão;

4.11.26. O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows XP (32 bit), Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior);

4.12. Condições operacionais

4.12.1. Alimentação / tensão de 100-240 VAC

4.12.2. Possuir conector para fonte de alimentação externa redundante;

4.12.3. Alimentação / frequência de 50/60 Hz

4.12.4. Temperatura - faixa de operação de 0º a 40º C

4.13. Suporte técnico e licenciamento

4.13.1. Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

4.13.2. Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

4.13.3. Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

4.13.4. A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados;

4.13.5. Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo possível solicitar atendimento em língua portuguesa;

4.13.6. Na apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

4.14.Serviços de configuração

4.14.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada:

4.14.2. Configurações básicas de conectividade

4.14.3. Registro e ativação de licenças Atualização de software

4.14.4. Configuração de zonas de segurança, VLANs e roteamento interno

4.14.5. Configurações dos serviços de segurança como IPS e Anti-Malware

4.14.6. Configuração de balanceamento de cagar de links WAN

4.14.7. Migração e/ou configuração de regras de firewall

4.14.8. Configuração de VPN

4.14.9. Configuração de regras de aplicação

4.14.10. Integração com base LDAP ou Radius

4.14.11. Configuração de autenticação SSO

4.14.12. Configuração de filtro de conteúdo por grupo de usuários

4.14.13. Configuração da unidade de alta disponibilidade

4.14.14. Configuração de QoS por serviços e/ou aplicações

4.14.15. Testes de funcionalidade

4.15.Treinamento

4.15.1. Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel:

4.15.2. Funcionalidades básicas do equipamento: senha de administração, hora e data, schedules e etc

4.15.3. Procedimento de registro e ativação de licenças

4.15.4. Procedimento de atualização de software

4.15.5. Zonas de segurança e objetos

4.15.6. Interfaces físicas, interfaces virtuais (VLANs) e roteamento interno

4.15.7. NAT

4.15.8. Serviços de segurança como IPS e Anti-Malware

4.15.9. Balanceamento de cagar de links WAN

4.15.10. Regras de firewall

4.15.11. VPN

4.15.12. Regras de aplicação, incluindo visibilidade das mesmas

4.15.13. Integração com base LDAP ou Radius

4.15.14. Autenticação SSO

4.15.15. Filtro de conteúdo por grupo de usuários

4.15.16. Unidade de alta disponibilidade

4.15.17. QoS por serviços e/ou aplicações

4.15.18. Instâncias ou contextos virtuais

LOTE 1 - ITEM 5

5. FIREWALL TIPO V

5.1.Características de hardware e performance

5.1.1.Throughput de, no mínimo, 8 Gbps com a funcionalidade de firewall habilitada para tráfego IPv4 e IPv6, independentemente do tamanho do pacote

5.1.2.Suporte a, no mínimo, 6M conexões simultâneas 5.1.3.Suporte a, no mínimo, 200K novas conexões por segundo 5.1.4.Throughput de, no mínimo, 7 Gbps de VPN IPSec

5.1.5.Estar licenciado para ou suportar sem o uso de licença, 2K túneis de VPN IPSEC Site-to-Site simultâneos

5.1.6.Estar licenciado para ou suportar sem o uso de licença, 10K túneis de clientes VPN IPSEC simultâneos

5.1.7.Throughput de, no mínimo, 350 Mbps de VPN SSL 5.1.8.Suporte a, no mínimo, 500 clientes de VPN SSL simultâneos 5.1.9.Suportar no mínimo 2 Gbps de throughput de IPS

5.1.10. Suportar no mínimo 1.9 Gbps de throughput de Inspeção SSL

5.1.11. Throughput de, no mínimo, 1.5 Gbps com as seguintes funcionalidade habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware. Caso o fabricante divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito;

5.1.12. Possuir ao menos 10 interfaces 1Gbps

5.1.13. Disco de, no mínimo, 120 GBytes para armazenamento de informações locais

5.1.14. Estar licenciado e/ou ter incluído sem custo adicional, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

5.1.15. Suporte a, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

5.2.Requisitos Mínimos de Funcionalidade

5.2.1.A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;

5.2.2.Deverá ser do mesmo fabricante dos itens “SOFTWARE DE GERENCIAMENTO” e “SOFTWARE DE RELATÓRIOS”, para garantir total compatibilidade;

5.2.3. 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;

0.0.0.Xx 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;

5.2.5. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;

5.2.6. 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;

5.2.7. O software deverá ser fornecido em sua versão mais atualizada;

5.2.8. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

5.2.9. O gerenciamento da solução deve suportar a interface de administração via web no próprio dispositivo de proteção de rede

5.2.10. Os dispositivos de proteção de rede devem possuir suporte a 1024 VLAN Tags 802.1q;

5.2.11. Os dispositivos de proteção de rede devem possuir suporte a agregação de links 8023ad e LACP;

5.2.12. Os dispositivos de proteção de rede devem possuir suporte a Policy based routing ou policy based forwarding;

5.2.13. Os dispositivos de proteção de rede devem possuir suporte a roteamento multicast (PIM-SM e PIM-DM);

5.2.14. Os dispositivos de proteção de rede devem possuir suporte a DHCP Relay;

5.2.15. Os dispositivos de proteção de rede devem possuir suporte a DHCP Server;

5.2.16. Os dispositivos de proteção de rede devem possuir suporte a Jumbo Frames;

5.2.17. Os dispositivos de proteção de rede devem suportar sub-interfaces ethernet logicas

5.2.18. Deve suportar NAT dinâmico (Many-to-1);

5.2.19. Deve suportar NAT dinâmico (Many-to-Many);

5.2.20. Deve suportar NAT estático (1-to-1);

5.2.21. Deve suportar NAT estático (Many-to-Many);

5.2.22. Deve suportar NAT estático bidirecional 1-to-1;

5.2.23. Deve suportar Tradução de porta (PAT);

5.2.24. Deve suportar NAT de Origem;

5.2.25. Deve suportar NAT de Destino;

5.2.26. Deve suportar NAT de Origem e NAT de Destino simultaneamente;

5.2.27. Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico;

5.2.28. Deve suportar NAT64 e NAT46;

5.2.29. Deve implementar o protocolo ECMP;

5.2.30. Deve implementar balanceamento de link por hash do IP de origem;

5.2.31. Deve implementar balanceamento de link por hash do IP de origem e destino;

5.2.32. 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;

5.2.33. Deve permitir monitorar via SNMP falhas de hardware, uso de recursos por número elevado de sessões, conexões por segundo, número de túneis estabelecidos na VPN, CPU, memória, status do cluster, ataques e estatísticas de uso das interfaces de rede

5.2.34. Enviar log para sistemas de monitoração externos, simultaneamente;

5.2.35. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;

5.2.36. Proteção anti-spoofing;

5.2.37. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);

5.2.38. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);

5.2.39. Suportar OSPF graceful restart;

5.2.40. 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);

5.2.41. Deve suportar Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;

5.2.42. Deve suportar 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;

5.2.43. Deve suportar 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;

5.2.44. Deve suportar Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;

5.2.45. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente;

5.2.46. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3;

5.2.47. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster;

5.2.48. A configuração em alta disponibilidade deve sincronizar: Sessões;

5.2.49. A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede;

5.2.50. A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs;

5.2.51. A configuração em alta disponibilidade deve sincronizar:Tabelas FIB;

5.2.52. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link;

5.2.53. Deve possuir suporte a criação de sistemas virtuais no mesmo appliance;

5.2.54. A utilização dos dispositivos em alta disponibilidade não deve impor limitações quanto à utilização de sistemas virtuais (contextos);

5.2.55. Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas;

5.2.56. O gerenciamento da solução deve suportar acesso via SSH e interface WEB (HTTPS), incluindo, mas não limitado à, exportar configuração dos sistemas virtuais (contextos) por ambas interfaces;

5.2.57. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema virtual, ou seja, isolação das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos)

5.2.58. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH 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;

5.2.59. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH Decryption e protocolos de roteamento dinâmico devem operar em caráter permanente, o licenciamento do dispositivo de segurança não pode ter nenhuma relação com sua configuração de rede como, mas não limitado a, configuração de interfaces, endereços lógicos, etc , podendo ser utilizado 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;

5.3.Controle por Política de Firewall

5.3.1.Deverá suportar controles por zona de segurança 5.3.2.Controles de políticas por porta e protocolo

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

5.3.4.Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança 5.3.5.Controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS)

5.3.6.Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound)

5.3.7.Deve suportar offload de certificado em inspeção de conexões SSL de entrada (Inbound); 5.3.8.Deve de-criptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2; 5.3.9.Controle de inspeção e de-criptografia de SSH por política;

5.3.10. Suporte a objetos e regras IPV6;

5.3.11. Suporte a objetos e regras multicast;

5.3.12. Deve suportar no mínimo 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 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;

5.3.13. Suportar a atribuição de agendamento das políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente;

5.4.Controle de Aplicações

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

5.4.2.Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos

5.4.3.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;

5.4.4.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;

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

5.4.6.Deve 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;

5.4.7.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 utilização da rede Tor

5.4.8.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;

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

5.4.10. Identificar o uso de táticas evasivas via comunicações criptografadas;

5.4.11. Atualizar a base de assinaturas de aplicações automaticamente;

5.4.12. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos do LDAP/AD;

5.4.13. 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;

5.4.14. 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;

5.4.15. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos;

5.4.16. Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;

5.4.17. 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;

5.4.18. 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: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS- SQL, IMAP, DNS, LDAP, RTSP e SSL

5.4.19. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;

5.4.20. Deve alertar o usuário quando uma aplicação for bloqueada;

5.4.21. Deve possibilitar que o controle de portas seja aplicado para todas as aplicações;

5.4.22. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc) possuindo granularidade de controle/políticas para os mesmos;

5.4.23. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos;

5.4.24. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo;

5.4.25. Deve possibilitar a diferenciação de aplicações Proxies (psiphon3, freegate, etc) possuindo granularidade de controle/políticas para os mesmos;

5.4.26. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como:

5.4.27. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client- Server, Browse Based, Network Protocol, etc)

5.4.28. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação

5.4.29. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Categoria da aplicação

5.4.30. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Aplicações que usem técnicas evasivas, utilizadas por malwares como uso excessivo de banda, tunelamento de tráfego ou transferência de arquivos, etc;

5.5.Prevenção de Ameaças

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

5.5.2.Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);

0.0.0.Xx 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 atualizações ou que não haja contrato de garantia de software com o fabricante;

5.5.4.Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade ativo/ativo e ativo/passivo;

5.5.5.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;

0.0.0.Xx assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;

5.5.7.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

5.5.8.Exceções por IP de origem ou de destino devem ser possíveis nas regras e assinatura a assinatura; 5.5.9.Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a

criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens

5.5.10. Deve permitir o bloqueio de vulnerabilidades

5.5.11. Deve permitir o bloqueio de exploits conhecidos

5.5.12. Deve incluir proteção contra ataques de negação de serviços

5.5.13. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de padrões de estado de conexões;

5.5.14. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de decodificação de protocolo;

5.5.15. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise para detecção de anomalias de protocolo;

5.5.16. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise heurística;

5.5.17. Deverá possuir o seguinte mecanismos de inspeção de IPS: IP Defragmentation;

5.5.18. Deverá possuir o seguinte mecanismos de inspeção de IPS: Remontagem de pacotes de TCP;

5.5.19. Deverá possuir o seguinte mecanismos de inspeção de IPS: Bloqueio de pacotes malformados

5.5.20. Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood, etc;

5.5.21. Detectar e bloquear a origem de portscans;

5.5.22. Bloquear ataques efetuados por worms conhecidos, permitindo ao administrador acrescentar novos padrões;

5.5.23. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;

5.5.24. Possuir assinaturas para bloqueio de ataques de buffer overflow;

5.5.25. Deverá possibilitar a criação de assinaturas customizadas pela interface gráfica do produto;

5.5.26. 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;

5.5.27. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;

5.5.28. Identificar e bloquear comunicação com botnets;

5.5.29. 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;

5.5.30. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS e controle de aplicação;

5.5.31. Deve permitir que na captura de pacotes por assinaturas de IPS seja definido o número de pacotes a serem capturados ou permitir capturar o pacote que deu origem ao alerta assim como seu contexto, facilitando a análise forense e identificação de falsos positivos

5.5.32. Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas;

5.5.33. Os eventos devem identificar o país de onde partiu a ameaça;

5.5.34. Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms

5.5.35. Proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos

5.5.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, zonas de segurança, 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

5.6.Filtro de URL

5.6.1.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);

5.6.2.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

5.6.3.Deve possuir 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, Active Directory e base de dados local;

5.6.4.Suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL; 5.6.5.Deve possuir base ou cache de URLs local no appliance ou em nuvem do próprio fabricante,

evitando delay de comunicação/validação das URLs; 5.6.6.Possuir pelo menos 60 categorias de URLs;

5.6.7.Deve possuir a função de exclusão de URLs do bloqueio, por categoria; 5.6.8.Permitir a customização de página de bloqueio;

5.6.9.Permitir 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);

5.7.Identificação de Usuários

5.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;

5.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;

5.7.3.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, suportando single sign-on, essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à, utilização de sistemas virtuais, segmentos de rede, etc;

5.7.4.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;

5.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;

5.7.6.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);

5.7.7.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;

5.7.8.Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;

5.7.9.Permitir integração com tokens para autenticação dos usuários, incluindo, mas não limitado a acesso a internet e gerenciamento da solução

5.7.10. Prover no mínimo um token nativamente, possibilitando autenticação de duplo fator

5.8.QoS e Traffic Shaping

5.8.1.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem; 5.8.2.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino; 5.8.3.Suportar a criação de políticas de QoS e Traffic Shaping por porta;

5.8.4.O QoS deve possibilitar a definição de classes por Banda Garantida;

5.8.5.O QoS deve possibilitar a definição de classes por Banda Máxima;

5.8.6.O QoS deve possibilitar a definição de classes por Fila de Prioridade 5.8.7.Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping; 5.8.8.Deve suportar QOS (traffic-shapping), em interface agregadas ou redundantes;

5.9.Filtro de Dados

5.9.1.Suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

5.9.2.Suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

5.9.3.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;

5.10. Geo Localização

5.10.1. Suportar a criação de políticas por geo-localização, permitindo o trafego de determinado Pais/Países sejam bloqueados;

5.10.2. Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos;

5.10.3. Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas;

5.11. VPN

5.11.1. Suportar VPN Site-to-Site e Cliente-To-Site;

5.11.2. Suportar IPSec VPN;

5.11.3. Suportar SSL VPN;

5.11.4. A VPN IPSEc deve suportar 3DES;

5.11.5. A VPN IPSEc deve suportar Autenticação MD5 e SHA-1;

5.11.6. A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14;

5.11.7. A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2);

5.11.8. A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard);

5.11.9. A VPN IPSEc deve suportar Autenticação via certificado IKE PKI

5.11.10. Deve possuir interoperabilidade com os seguintes fabricantes: Cisco, Check Point, Juniper, Palo Alto Networks, Fortinet, SonicWall;

5.11.11. Suportar VPN em em IPv4 e IPv6, assim como tráfego IPv4 dentro de túneis IPSec IPv6

5.11.12. 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;

5.11.13. 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;

5.11.14. A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;

5.11.15. 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;

5.11.16. Atribuição de DNS nos clientes remotos de VPN;

5.11.17. 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;

5.11.18. Suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local;

5.11.19. Suportar leitura e verificação de CRL (certificate revocation list);

5.11.20. Permitir a aplicação de políticas de segurança e visibilidade para as aplicações que circulam dentro dos túneis SSL;

5.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 SCCM, Active Directory e ser descarregado diretamente desde o seu próprio portal, o qual residirá no centralizador de VPN;

5.11.22. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Antes do usuário autenticar na estação;

5.11.23. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Após autenticação do usuário na estação;

5.11.24. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Sob demanda do usuário;

5.11.25. Deverá manter uma conexão segura com o portal durante a sessão;

5.11.26. O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows XP (32 bit), Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior);

5.12. Condições operacionais

5.12.1. Alimentação / tensão de 100-240 VAC

5.12.2. Possuir conector para fonte de alimentação externa redundante;

5.12.3. Alimentação / frequência de 50/60 Hz

5.12.4. Temperatura - faixa de operação de 0º a 40º C

5.13. Suporte técnico e licenciamento

5.13.1. Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

5.13.2. Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

5.13.3. Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

5.13.4. A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados;

5.13.5. Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo possível solicitar atendimento em língua portuguesa;

5.13.6. Na apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

5.14.Serviços de configuração

5.14.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada:

5.14.2. Configurações básicas de conectividade

5.14.3. Registro e ativação de licenças Atualização de software

5.14.4. Configuração de zonas de segurança, VLANs e roteamento interno

5.14.5. Configurações dos serviços de segurança como IPS e Anti-Malware

5.14.6. Configuração de balanceamento de cagar de links WAN

5.14.7. Migração e/ou configuração de regras de firewall

5.14.8. Configuração de VPN

5.14.9. Configuração de regras de aplicação

5.14.10. Integração com base LDAP ou Radius

5.14.11. Configuração de autenticação SSO

5.14.12. Configuração de filtro de conteúdo por grupo de usuários

5.14.13. Configuração da unidade de alta disponibilidade

5.14.14. Configuração de QoS por serviços e/ou aplicações

5.14.15. Testes de funcionalidade

5.15.Treinamento

5.15.1. Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel:

5.15.2. Funcionalidades básicas do equipamento: senha de administração, hora e data, schedules e etc

5.15.3. Procedimento de registro e ativação de licenças

5.15.4. Procedimento de atualização de software

5.15.5. Zonas de segurança e objetos

5.15.6. Interfaces físicas, interfaces virtuais (VLANs) e roteamento interno

5.15.7. NAT

5.15.8. Serviços de segurança como IPS e Anti-Malware

5.15.9. Balanceamento de cagar de links WAN

5.15.10. Regras de firewall

5.15.11. VPN

5.15.12. Regras de aplicação, incluindo visibilidade das mesmas

5.15.13. Integração com base LDAP ou Radius

5.15.14. Autenticação SSO

5.15.15. Filtro de conteúdo por grupo de usuários

5.15.16. Unidade de alta disponibilidade

5.15.17. QoS por serviços e/ou aplicações

5.15.18. Instâncias ou contextos virtuais

LOTE 1 - ITEM 6

6. FIREWALL TIPO VI

6.1.Características de hardware e performance

6.1.1.Throughput de, no mínimo, 3 Gbps com a funcionalidade de firewall habilitada para tráfego IPv4 e IPv6, independentemente do tamanho do pacote

6.1.2.Suporte a, no mínimo, 1.3M conexões simultâneas 6.1.3.Suporte a, no mínimo, 30K novas conexões por segundo 6.1.4.Throughput de, no mínimo, 2 Gbps de VPN IPSec

6.1.5.Estar licenciado para ou suportar sem o uso de licença, 200 túneis de VPN IPSEC Site-to-Site simultâneos

6.1.6.Estar licenciado para ou suportar sem o uso de licença, 500 túneis de clientes VPN IPSEC simultâneos

6.1.7.Throughput de, no mínimo, 150 Mbps de VPN SSL 6.1.8.Suporte a, no mínimo, 100 clientes de VPN SSL simultâneos 6.1.9.Suportar no mínimo 350 Mbps de throughput de IPS

6.1.10. Suportar no mínimo 340 Mbps de throughput de Inspeção SSL

6.1.11. Throughput de, no mínimo, 180 Mbps com as seguintes funcionalidade habilitadas simultaneamente para todas as assinaturas que a plataforma de segurança possuir devidamente ativadas e atuantes: controle de aplicação, IPS, Antivírus e Antispyware. Caso o fabricante divulgue múltiplos números de desempenho para qualquer uma destas funcionalidades, somente o de menor valor será aceito;

6.1.12. Possuir ao menos 10 interfaces 1Gbps

6.1.13. Estar licenciado e/ou ter incluído sem custo adicional, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

6.1.14. Suporte a, no mínimo, 10 sistemas virtuais lógicos (Contextos) por appliance

6.2.Requisitos Mínimos de Funcionalidade

6.2.1.A solução deve consistir em plataforma de proteção de rede baseada em appliance com funcionalidades de Next Generation Firewall (NGFW), e console de gerência e monitoração;

6.2.2.Deverá ser do mesmo fabricante dos itens “SOFTWARE DE GERENCIAMENTO” e “SOFTWARE DE RELATÓRIOS”, para garantir total compatibilidade;

6.2.3. 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;

6.2.4. 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;

6.2.5. A plataforma deve ser otimizada para análise de conteúdo de aplicações em camada 7;

6.2.6. 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;

6.2.7. O software deverá ser fornecido em sua versão mais atualizada;

6.2.8. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

6.2.9. O gerenciamento da solução deve suportar a interface de administração via web no próprio dispositivo de proteção de rede

6.2.10. Os dispositivos de proteção de rede devem possuir suporte a 1024 VLAN Tags 802.1q;

6.2.11. Os dispositivos de proteção de rede devem possuir suporte a agregação de links 8023ad e LACP;

6.2.12. Os dispositivos de proteção de rede devem possuir suporte a Policy based routing ou policy based forwarding;

6.2.13. Os dispositivos de proteção de rede devem possuir suporte a roteamento multicast (PIM-SM e PIM-DM);

6.2.14. Os dispositivos de proteção de rede devem possuir suporte a DHCP Relay;

6.2.15. Os dispositivos de proteção de rede devem possuir suporte a DHCP Server;

6.2.16. Os dispositivos de proteção de rede devem possuir suporte a Jumbo Frames;

6.2.17. Os dispositivos de proteção de rede devem suportar sub-interfaces ethernet logicas

6.2.18. Deve suportar NAT dinâmico (Many-to-1);

6.2.19. Deve suportar NAT dinâmico (Many-to-Many);

6.2.20. Deve suportar NAT estático (1-to-1);

6.2.21. Deve suportar NAT estático (Many-to-Many);

6.2.22. Deve suportar NAT estático bidirecional 1-to-1;

6.2.23. Deve suportar Tradução de porta (PAT);

6.2.24. Deve suportar NAT de Origem;

6.2.25. Deve suportar NAT de Destino;

6.2.26. Deve suportar NAT de Origem e NAT de Destino simultaneamente;

6.2.27. Deve implementar Network Prefix Translation (NPTv6) ou NAT66, prevenindo problemas de roteamento assimétrico;

6.2.28. Deve suportar NAT64 e NAT46;

6.2.29. Deve implementar o protocolo ECMP;

6.2.30. Deve implementar balanceamento de link por hash do IP de origem;

6.2.31. Deve implementar balanceamento de link por hash do IP de origem e destino;

6.2.32. 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;

6.2.33. Deve permitir monitorar via SNMP falhas de hardware, uso de recursos por número elevado de sessões, conexões por segundo, número de túneis estabelecidos na VPN, CPU, memória, status do cluster, ataques e estatísticas de uso das interfaces de rede

6.2.34. Enviar log para sistemas de monitoração externos, simultaneamente;

6.2.35. Deve haver a opção de enviar logs para os sistemas de monitoração externos via protocolo TCP e SSL;

6.2.36. Proteção anti-spoofing;

6.2.37. Para IPv4, deve suportar roteamento estático e dinâmico (RIPv2, BGP e OSPFv2);

6.2.38. Para IPv6, deve suportar roteamento estático e dinâmico (OSPFv3);

6.2.39. Suportar OSPF graceful restart;

6.2.40. 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);

6.2.41. Deve suportar Modo Sniffer, para inspeção via porta espelhada do tráfego de dados da rede;

6.2.42. Deve suportar 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;

6.2.43. Deve suportar 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;

6.2.44. Deve suportar Modo misto de trabalho Sniffer, L2 e L3 em diferentes interfaces físicas;

6.2.45. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em modo transparente;

6.2.46. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3;

6.2.47. Suporte a configuração de alta disponibilidade Ativo/Passivo e Ativo/Ativo: Em layer 3 e com no mínimo 3 equipamentos no cluster;

6.2.48. A configuração em alta disponibilidade deve sincronizar: Sessões;

6.2.49. A configuração em alta disponibilidade deve sincronizar: Configurações, incluindo, mas não limitado as políticas de Firewall, NAT, QOS e objetos de rede;

6.2.50. A configuração em alta disponibilidade deve sincronizar: Associações de Segurança das VPNs;

6.2.51. A configuração em alta disponibilidade deve sincronizar:Tabelas FIB;

6.2.52. O HA (modo de Alta-Disponibilidade) deve possibilitar monitoração de falha de link;

6.2.53. Deve possuir suporte à criação de sistemas virtuais no mesmo appliance;

6.2.54. A utilização dos dispositivos em alta disponibilidade não deve impor limitações quanto à utilização de sistemas virtuais (contextos);

6.2.55. Deve permitir a criação de administradores independentes, para cada um dos sistemas virtuais existentes, de maneira a possibilitar a criação de contextos virtuais que podem ser administrados por equipes distintas;

6.2.56. O gerenciamento da solução deve suportar acesso via SSH e interface WEB (HTTPS), incluindo, mas não limitado à, exportar configuração dos sistemas virtuais (contextos) por ambas interfaces;

6.2.57. Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound), sendo que deve suportar o controle dos certificados individualmente dentro de cada sistema virtual, ou seja, isolação das operações de adição, remoção e utilização dos certificados diretamente nos sistemas virtuais (contextos)

6.2.58. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH 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;

6.2.59. As funcionalidades de controle de aplicações, VPN IPSec e SSL, QOS, SSL e SSH Decryption e protocolos de roteamento dinâmico devem operar em caráter permanente, o licenciamento do dispositivo de segurança não pode ter nenhuma relação com sua configuração de rede como, mas não limitado a, configuração de interfaces, endereços lógicos, etc , podendo ser utilizado 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;

6.3.Controle por Política de Firewall

6.3.1.Deverá suportar controles por zona de segurança 6.3.2.Controles de políticas por porta e protocolo

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

6.3.4.Controle de políticas por usuários, grupos de usuários, IPs, redes e zonas de segurança 6.3.5.Controle de políticas por código de País (Por exemplo: BR, USA, UK, RUS)

6.3.6.Controle, inspeção e de-criptografia de SSL por política para tráfego de entrada (Inbound) e Saída (Outbound)

6.3.7.Deve suportar offload de certificado em inspeção de conexões SSL de entrada (Inbound); 6.3.8.Deve de-criptografar tráfego Inbound e Outbound em conexões negociadas com TLS 1.2; 6.3.9.Controle de inspeção e de-criptografia de SSH por política;

6.3.10. Suporte a objetos e regras IPV6;

6.3.11. Suporte a objetos e regras multicast;

6.3.12. Deve suportar no mínimo 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 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;

6.3.13. Suportar a atribuição de agendamento das políticas com o objetivo de habilitar e desabilitar políticas em horários pré-definidos automaticamente;

6.4.Controle de Aplicações

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

6.4.2.Deve ser possível a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos

6.4.3.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;

6.4.4.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;

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

6.4.6.Deve 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;

6.4.7.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 utilização da rede Tor

6.4.8.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;

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

6.4.10. Identificar o uso de táticas evasivas via comunicações criptografadas;

6.4.11. Atualizar a base de assinaturas de aplicações automaticamente;

6.4.12. Limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem, usuários e grupos do LDAP/AD;

6.4.13. 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;

6.4.14. 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;

6.4.15. Deve suportar múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas e decodificação de protocolos;

6.4.16. Para manter a segurança da rede eficiente, deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;

6.4.17. 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;

6.4.18. 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: HTTP, FTP, NBSS, DCE RPC, SMTP, Telnet, SSH, MS- SQL, IMAP, DNS, LDAP, RTSP e SSL

6.4.19. O fabricante deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;

6.4.20. Deve alertar o usuário quando uma aplicação for bloqueada;

6.4.21. Deve possibilitar que o controle de portas seja aplicado para todas as aplicações;

6.4.22. Deve possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc) possuindo granularidade de controle/políticas para os mesmos;

6.4.23. Deve possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, Hangouts, Facebook Chat, etc) possuindo granularidade de controle/políticas para os mesmos;

6.4.24. Deve possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir o Hangouts chat e bloquear a chamada de vídeo;

6.4.25. Deve possibilitar a diferenciação de aplicações Proxies (psiphon3, freegate, etc) possuindo granularidade de controle/políticas para os mesmos;

6.4.26. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como:

6.4.27. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Tecnologia utilizada nas aplicações (Client- Server, Browse Based, Network Protocol, etc)

6.4.28. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Nível de risco da aplicação

6.4.29. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Categoria da aplicação

6.4.30. Deve ser possível a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: Aplicações que usem técnicas evasivas, utilizadas por malwares como uso excessivo de banda, tunelamento de tráfego ou transferência de arquivos, etc;

6.5.Prevenção de Ameaças

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

6.5.2.Deve incluir assinaturas de prevenção de intrusão (IPS) e bloqueio de arquivos maliciosos (Antivírus e Anti-Spyware);

0.0.0.Xx 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 atualizações ou que não haja contrato de garantia de software com o fabricante;

6.5.4.Deve sincronizar as assinaturas de IPS, Antivírus, Anti-Spyware quando implementado em alta disponibilidade ativo/ativo e ativo/passivo;

6.5.5.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;

0.0.0.Xx assinaturas devem poder ser ativadas ou desativadas, ou ainda habilitadas apenas em modo de monitoração;

6.5.7.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

6.5.8.Exceções por IP de origem ou de destino devem ser possíveis nas regras e assinatura a assinatura; 6.5.9.Deve suportar granularidade nas políticas de IPS, Antivírus e Anti-Spyware, possibilitando a

criação de diferentes politicas por zona de segurança, endereço de origem, endereço de destino, serviço e a combinação de todos esses itens

6.5.10. Deve permitir o bloqueio de vulnerabilidades

6.5.11. Deve permitir o bloqueio de exploits conhecidos

6.5.12. Deve incluir proteção contra ataques de negação de serviços

6.5.13. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de padrões de estado de conexões;

6.5.14. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise de decodificação de protocolo;

6.5.15. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise para detecção de anomalias de protocolo;

6.5.16. Deverá possuir o seguinte mecanismos de inspeção de IPS: Análise heurística;

6.5.17. Deverá possuir o seguinte mecanismos de inspeção de IPS: IP Defragmentation;

6.5.18. Deverá possuir o seguinte mecanismos de inspeção de IPS: Remontagem de pacotes de TCP;

6.5.19. Deverá possuir o seguinte mecanismos de inspeção de IPS: Bloqueio de pacotes malformados

6.5.20. Ser imune e capaz de impedir ataques básicos como: Syn flood, ICMP flood, UDP flood, etc;

6.5.21. Detectar e bloquear a origem de portscans;

6.5.22. Bloquear ataques efetuados por worms conhecidos, permitindo ao administrador acrescentar novos padrões;

6.5.23. Possuir assinaturas específicas para a mitigação de ataques DoS e DDoS;

6.5.24. Possuir assinaturas para bloqueio de ataques de buffer overflow;

6.5.25. Deverá possibilitar a criação de assinaturas customizadas pela interface gráfica do produto;

6.5.26. 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;

6.5.27. Permitir o bloqueio de vírus e spywares em, pelo menos, os seguintes protocolos: HTTP, FTP, SMB, SMTP e POP3;

6.5.28. Identificar e bloquear comunicação com botnets;

6.5.29. 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;

6.5.30. Deve suportar a captura de pacotes (PCAP), por assinatura de IPS e controle de aplicação;

6.5.31. Deve permitir que na captura de pacotes por assinaturas de IPS seja definido o número de pacotes a serem capturados ou permitir capturar o pacote que deu origem ao alerta assim como seu contexto, facilitando a análise forense e identificação de falsos positivos

6.5.32. Deve possuir a função de proteção a resolução de endereços via DNS, identificando requisições de resolução de nome para domínios maliciosos de botnets conhecidas;

6.5.33. Os eventos devem identificar o país de onde partiu a ameaça;

6.5.34. Deve incluir proteção contra vírus em conteúdo HTML e javascript, software espião (spyware) e worms

6.5.35. Proteção contra downloads involuntários usando HTTP de arquivos executáveis e maliciosos

6.5.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, zonas de segurança, 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

6.6.Filtro de URL

6.6.1.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);

6.6.2.Deve ser possível a criação de políticas por usuários, grupos de usuários, IPs, redes ou zonas de segurança;

6.6.3.Deve possuir 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, Active Directory e base de dados local;

6.6.4.Suportar a capacidade de criação de políticas baseadas no controle por URL e categoria de URL; 6.6.5.Deve possuir base ou cache de URLs local no appliance ou em nuvem do próprio fabricante,

evitando delay de comunicação/validação das URLs; 6.6.6.Possuir pelo menos 60 categorias de URLs;

6.6.7.Deve possuir a função de exclusão de URLs do bloqueio, por categoria;

6.6.8.Permitir a customização de página de bloqueio;

6.6.9.Permitir 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);

6.7.Identificação de Usuários

6.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;

6.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;

6.7.3.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, suportando single sign-on, essa funcionalidade não deve possuir limites licenciados de usuários ou qualquer tipo de restrição de uso como, mas não limitado à, utilização de sistemas virtuais, segmentos de rede, etc;

6.7.4.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;

6.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;

6.7.6.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);

6.7.7.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;

6.7.8.Deve implementar a criação de grupos customizados de usuários no firewall, baseado em atributos do LDAP/AD;

6.7.9.Permitir integração com tokens para autenticação dos usuários, incluindo, mas não limitado a acesso a internet e gerenciamento da solução

6.7.10. Prover no mínimo um token nativamente, possibilitando autenticação de duplo fator

6.8.QoS e Traffic Shaping

6.8.1.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de origem; 6.8.2.Suportar a criação de políticas de QoS e Traffic Shaping por endereço de destino; 6.8.3.Suportar a criação de políticas de QoS e Traffic Shaping por porta;

6.8.4.O QoS deve possibilitar a definição de classes por Banda Garantida;

6.8.5.O QoS deve possibilitar a definição de classes por Banda Máxima;

6.8.6.O QoS deve possibilitar a definição de classes por Fila de Prioridade 6.8.7.Disponibilizar estatísticas em tempo real para classes de QoS ou Traffic Shaping; 6.8.8.Deve suportar QOS (traffic-shapping), em interface agregadas ou redundantes;

6.9.Filtro de Dados

6.9.1.Suportar identificação de arquivos compactados ou a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

6.9.2.Suportar a identificação de arquivos criptografados e a aplicação de políticas sobre o conteúdo desses tipos de arquivos;

6.9.3.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;

6.10. Geo Localização

6.10.1. Suportar a criação de políticas por geo-localização, permitindo o trafego de determinado Pais/Países sejam bloqueados;

6.10.2. Deve possibilitar a visualização dos países de origem e destino nos logs dos acessos;

6.10.3. Deve possibilitar a criação de regiões geográficas pela interface gráfica e criar políticas utilizando as mesmas;

6.11. VPN

6.11.1. Suportar VPN Site-to-Site e Cliente-To-Site;

6.11.2. Suportar IPSec VPN;

6.11.3. Suportar SSL VPN;

6.11.4. A VPN IPSEc deve suportar 3DES;

6.11.5. A VPN IPSEc deve suportar Autenticação MD5 e SHA-1;

6.11.6. A VPN IPSEc deve suportar Diffie-Hellman Group 1, Group 2, Group 5 e Group 14;

6.11.7. A VPN IPSEc deve suportar Algoritmo Internet Key Exchange (IKEv1 e v2);

6.11.8. A VPN IPSEc deve suportar AES 128, 192 e 256 (Advanced Encryption Standard);

6.11.9. A VPN IPSEc deve suportar Autenticação via certificado IKE PKI

6.11.10. Deve possuir interoperabilidade com os seguintes fabricantes: Cisco, Check Point, Juniper, Palo Alto Networks, Fortinet, SonicWall;

6.11.11. Suportar VPN em em IPv4 e IPv6, assim como tráfego IPv4 dentro de túneis IPSec IPv6

6.11.12. 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;

6.11.13. 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;

6.11.14. A funcionalidades de VPN SSL devem ser atendidas com ou sem o uso de agente;

6.11.15. 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;

6.11.16. Atribuição de DNS nos clientes remotos de VPN;

6.11.17. 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;

6.11.18. Suportar autenticação via AD/LDAP, Secure id, certificado e base de usuários local;

6.11.19. Suportar leitura e verificação de CRL (certificate revocation list);

6.11.20. Permitir a aplicação de políticas de segurança e visibilidade para as aplicações que circulam dentro dos túneis SSL;

6.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 SCCM, Active Directory e ser descarregado diretamente desde o seu próprio portal, o qual residirá no centralizador de VPN;

6.11.22. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Antes do usuário autenticar na estação;

6.11.23. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Após autenticação do usuário na estação;

6.11.24. Deve permitir que a conexão com a VPN seja estabelecida das seguintes forma: Sob demanda do usuário;

6.11.25. Deverá manter uma conexão segura com o portal durante a sessão;

6.11.26. O agente de VPN SSL ou IPSEC client-to-site deve ser compatível com pelo menos: Windows XP (32 bit), Windows 7 (32 e 64 bit), Windows 8 (32 e 64 bit), Windows 10 (32 e 64 bit) e Mac OS X (v10.10 ou superior);

6.12. Condições operacionais

6.12.1. Alimentação / tensão de 100-240 VAC

6.12.2. Alimentação / frequência de 50/60 Hz

6.12.3. Temperatura - faixa de operação de 0º a 40º C

6.13. Suporte técnico e licenciamento

6.13.1. Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

6.13.2. Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

6.13.3. Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

6.13.4. A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados;

6.13.5. Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo possível solicitar atendimento em língua portuguesa;

6.13.6. Na apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

6.14.Serviços de configuração

6.14.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada:

6.14.2. Configurações básicas de conectividade

6.14.3. Registro e ativação de licenças Atualização de software

6.14.4. Configuração de zonas de segurança, VLANs e roteamento interno

6.14.5. Configurações dos serviços de segurança como IPS e Anti-Malware

6.14.6. Configuração de balanceamento de cagar de links WAN

6.14.7. Migração e/ou configuração de regras de firewall

6.14.8. Configuração de VPN

6.14.9. Configuração de regras de aplicação

6.14.10. Integração com base LDAP ou Radius

6.14.11. Configuração de autenticação SSO

6.14.12. Configuração de filtro de conteúdo por grupo de usuários

6.14.13. Configuração da unidade de alta disponibilidade

6.14.14. Configuração de QoS por serviços e/ou aplicações

6.14.15. Testes de funcionalidade

6.15.Treinamento

6.15.1. Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel:

6.15.2. Funcionalidades básicas do equipamento: senha de administração, hora e data, schedules e etc

6.15.3. Procedimento de registro e ativação de licenças

6.15.4. Procedimento de atualização de software

6.15.5. Zonas de segurança e objetos

6.15.6. Interfaces físicas, interfaces virtuais (VLANs) e roteamento interno

6.15.7. NAT

6.15.8. Serviços de segurança como IPS e Anti-Malware

6.15.9. Balanceamento de cagar de links WAN

6.15.10. Regras de firewall

6.15.11. VPN

6.15.12. Regras de aplicação, incluindo visibilidade das mesmas

6.15.13. Integração com base LDAP ou Radius

6.15.14. Autenticação SSO

6.15.15. Filtro de conteúdo por grupo de usuários

6.15.16. Unidade de alta disponibilidade

6.15.17. QoS por serviços e/ou aplicações

6.15.18. Instâncias ou contextos virtuais

LOTE 1 - ITEM 7

7. SOFTWARE DE GERENCIAMENTO

7.1. Características Gerais

7.1.1. Deve ser do mesmo fabricante dos itens de firewall, a fim de garantir compatibilidade;

7.1.2. Deve permitir gerenciar ao menos 10 dispositivos

7.1.3. Deve permitir e estar licenciado para operar em alta disponibilidade (HA) sincronizando as configurações, objetos e políticas entre as estações de gerência

7.1.4. Caso a solução de gerenciamento seja ofertada em appliance físico deverá possuir:

7.1.4.1. Possuir ao menos 4 interfaces de 1Gbps RJ-45;

7.1.4.2. Possuir ao menos 8GB de memória RAM;

7.1.4.3. Possuir ao menos um processador octacore;

7.1.4.4. Possuir ao menos 1TB de armazenamento configurados em RAID 1

7.1.5. Caso a solução de gerenciamento seja ofertada em appliance virtual deverá:

7.1.5.1. Ser compatível com ambiente VMware ESXi 5.5;

7.1.5.2. Deve estar licenciado para pelo menos 200 GB de espaço em disco

7.1.5.3. Não deve possuir limite na quantidade de múltiplas vCPU caso virtual;

7.1.5.4. Não deve possuir limite para suporte a expansão de memória RAM caso virtual;

7.2. Funcionalidades da Solução de Gerência

7.2.1. 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;

7.2.2. O gerenciamento da solução deve suportar acesso via SSH, cliente ou WEB (HTTPS) e API aberta;

7.2.3. Permitir acesso concorrente de administradores;

7.2.4. Possuir interface baseada em linha de comando para administração da solução de gerência

7.2.5. Deve possuir um mecanismo de busca por comandos no gerenciamento via SSH, facilitando a localização de comandos;

7.2.6. Bloqueio de alterações, no caso acesso simultâneo de dois ou mais administradores;

7.2.7. 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;

7.2.8. Gerar alertas automáticos via Email

7.2.9. Gerar alertas automáticos via SNMP

7.2.10. Gerar alertas automáticos via Syslog

7.2.11. Deve suportar XML API

7.2.12. O gerenciamento deve possibilitar a criação e administração de políticas de firewall e controle de aplicação;

7.2.13. O gerenciamento deve possibilitar a criação e administração de políticas de IPS, Antivírus e Anti-Spyware;

7.2.14. O gerenciamento deve possibilitar a criação e administração de políticas de Filtro de URL;

7.2.15. Deve permitir usar palavras chaves ou cores para facilitar identificação de regras;

7.2.16. Permitir localizar quais regras um objeto está sendo utilizado;

7.2.17. Deve atribuir sequencialmente um número a cada regra de firewall;

7.2.18. Deve atribuir sequencialmente um número a cada regra de NAT;

7.2.19. Deve atribuir sequencialmente um número a cada regra de QOS;

7.2.20. Deve atribuir sequencialmente um número a cada regra de DOS;

7.2.21. Permitir criação de regras que fiquem ativas em horário definido;

7.2.22. Permitir criação de regras com data de expiração;

7.2.23. Permitir backup das configurações e rollback de configuração para a última configuração salva;

7.2.24. Deve possuir mecanismo de Validação das políticas, avisando quando houver regras que, ofusquem ou conflitem com outras (shadowing);

7.2.25. Deve possibilitar a visualização e comparação de configurações atuais, configuração anterior e configurações antigas;

7.2.26. Deve permitir que todos os firewalls sejam controlados de forma centralizada utilizando apenas um servidor de gerência.

7.2.27. Um sistema de backup/restore de todas as configurações da solução de gerência deve estar incluso e deve permitir ao administrador agendar backups da configuração em um determinado dia e hora.

7.2.28. Deve ser permitido ao administrador transferir os backups para um servidor FTP.

7.2.29. Deve ser permitido ao administrador transferir os backups para um servidor SCP

7.2.30. As alterações realizadas em um servidor de gerência deverão ser automaticamente replicadas para o servidor redundante

7.2.31. Cada servidor de gerência deve ser hospedado em um equipamento independente, não exercendo funções de firewall.

7.2.32. Caso os appliances percam comunicação com os servidores de gerência, os firewalls deverão continuar tratando o tráfego corretamente, sem causar interrupção das comunicações.

7.2.33. A solução deve incluir uma ferramenta para gerenciar centralmente as licenças de todos os appliances controlados pela estação de gerenciamento, permitindo ao administrador atualizar licenças nos appliances através dessa ferramenta.

7.2.34. A solução deve possibilitar a distribuição e instalação remota, de maneira centralizada, de novas versões de software dos appliances.

7.2.35. Deve ser permitido aos administradores se autenticarem nos servidores de gerência através de contas de usuários LOCAIS

7.2.36. Deve ser permitido aos administradores se autenticarem nos servidores de gerência através de usuários de base externa LDAP

7.2.37. Deve ser permitido aos administradores se autenticarem nos servidores de gerência através de base externa RADIUS

7.2.38. Deve ser permitido aos administradores se autenticarem nos servidores de gerência através de Certificado Digital X.509 (PKI)

7.2.39. Deve suportar sincronização do relógio interno via protocolo NTP.

7.2.40. Deve registrar login ou tentativa de login de qualquer usuário.

7.2.41. Logs de auditoria para configurações de regras e objetos devem ser visualizados em uma lista diferente da que exibe os logs relacionados a tráfego de dados.

7.2.42. Devem ser fornecidos manuais de instalação, configuração e operação de toda a solução, na língua portuguesa ou inglesa, com apresentação de boa qualidade.

7.2.43. Deve ser capaz de gerar relatórios ou exibir comparativos entre duas sessões diferentes, resumindo todas as alterações efetuadas.

7.2.44. Suportar SNMP versão 2 e versão 3 nos equipamentos de gerência

7.2.45. Deve permitir habilitar e desabilitar, para cada interface de rede da solução de gerência, permissões de acesso HTTP, HTTPS, SSH, SNMP e Telnet

7.2.46. Deve permitir virtualizar a solução de gerência, de forma que cada administrador possa gerenciar, visualizar e editar apenas os dispositivos autorizados e cadastrados no seu ambiente virtualizado

7.2.47. A solução de gerência deve permitir criar administradores que tenham acesso à todas as instâncias de virtualização

7.2.48. Permitir que eventuais políticas e objetos já presentes nos dispositivos sejam importados quando o mesmo for adicionado à solução de gerência

7.2.49. Permitir visualizar, a partir da estação de gerência centralizada, informações detalhadas dos dispositivos gerenciados, tais como licenças, horário do sistema e firmware.

7.2.50. Permitir criar na solução de gerência templates de configuração dos dispositivos com informações de DNS, SNMP, Configurações de LOG e Administração

7.2.51. Permitir criar os objetos que serão utilizados nas políticas de forma centralizada

7.3. Suporte técnico e licenciamento

7.3.1.Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

7.3.2.Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

7.3.3.Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

7.3.4.A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados;

7.3.5.Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo possível solicitar atendimento em língua portuguesa;

0.0.0.Xx apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

7.4. Serviços de configuração

7.4.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada

7.4.2. Instalação física ou virtual

7.4.3. Configurações básicas de conectividade

7.4.4. Registro e ativação de licenças

7.4.5. Atualização de software

7.4.6. Integração dos firewalls com software de gerenciamento

7.4.7. Configuração de rotinas de backup e atualizações de firmware;

7.5. Treinamento

7.5.1.Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel:

7.5.2. Operação da ferramenta de gerência;

7.5.3. Aplicação de políticas em grupos de equipamentos;

7.5.4. Procedimento de backup e restore dos firewalls;

7.5.5. Manutenção;

LOTE 1 - ITEM 8

8. SOFTWARE DE RELATÓRIOS TIPO I

8.1. Características Gerais

8.1.1. Deve ser do mesmo fabricante dos itens de firewall, a fim de garantir compatibilidade;

8.1.2. Deve estar licenciado para coletar logs e gerar relatório de múltiplos firewalls;

8.1.3. Possuir capacidade receber ao menos 25GBytes de logs diários

8.1.4. Caso a solução de coleta de logs e relatórios seja ofertada em appliance físico deverá possuir:

8.1.4.1. Possuir ao menos 4 interfaces de 1Gbps RJ-45;

8.1.4.2. Possuir ao menos 16GB de memória RAM;

8.1.4.3. Possuir ao menos um processador octacore;

8.1.4.4. Possuir ao menos 10 TB de armazenamento configurados em RAID 1

8.1.5. Caso a solução de gerenciamento seja ofertada em appliance virtual deverá:

8.1.5.1. Ser compatível com ambiente VMware ESXi 5.5;

8.1.5.2. Deve estar licenciado para pelo menos 10 TB de espaço em disco

8.1.5.3. Não deve possuir limite na quantidade de múltiplas vCPU caso virtual;

8.1.5.4. Não deve possuir limite para suporte a expansão de memória RAM caso virtual;

8.2. Funcionalidades da Solução de Relatórios

8.2.1. Deve suportar acesso via SSH, WEB (HTTPS) e Telnet para o gerenciamento da solução.

8.2.2. Possuir comunicação cifrada e autenticada com usuário e senha para solução de relatórios, tanto como para a interface gráfica de usuário e console de administração por linha de comandos (SSH)

8.2.3. Permitir acesso simultâneo de administradores permitindo a criação de ao menos 2 (dois) perfis para administração e monitoração

8.2.4. Suportar SNMP versão 2 e versão 3 na solução de relatórios

8.2.5. Permitir virtualizar a solução de relatórios, onde cada administrador gerencie, visualize e edite apenas os dispositivos autorizados e cadastrados no seu ambiente virtualizado

8.2.6. Deve permitir a criação de administradores que acessem à todas as instâncias de virtualização da solução de relatórios

8.2.7. Deve permitir habilitar e desabilitar, para cada interface de rede da solução de relatórios, permissões de acesso HTTP, HTTPS, SSH, SNMP e Telnet

8.2.8. Autenticação integrada a servidor Radius

8.2.9. Geração de relatórios com mapas geográficos ou modo tabela gerados em tempo real para a visualização de origens e destinos do tráfego gerado na instituição;

8.2.10. Autenticação integrada ao Microsoft Active Directory

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

8.2.12. Xxxx possuir um assistente para adicionar dispositivos via interface gráfica usando o IP, login e senha do mesmo

8.2.13. Deve ser possível visualizar a quantidade de logs enviado de cada dispositivo monitorado

8.2.14. Possuir mecanismo para que logs antigos sejam removidos automaticamente

8.2.15. Permitir a importação e exportação de relatórios

8.2.16. Deve ser possível exportar os logs em CSV

8.2.17. Geração de logs de auditoria detalhados, informando a configuração realizada, o administrador que a realizou e o horário da alteração

8.2.18. Os logs gerados pelos appliances devem ser centralizados nos servidores de gerência, mas a solução deve oferecer também a possibilidade de utilização de um syslog externo ou similar

8.2.19. A solução deve possuir relatórios pré-definidos

8.2.20. Possuir envio automático de logs para um servidor FTP externo a solução

8.2.21. Possibilitar a duplicação de relatórios existentes e edita-los logo após

8.2.22. Possuir a capacidade de personalização de capas para os relatórios

8.2.23. Possibilitar a duplicação de gráficos existentes de relatórios

8.2.24. Permitir de forma centralizada visualizar os logs recebidos por um ou vários dispositivos externos incluindo a capacidade de uso de filtros nas pesquisas deste log

8.2.25. Logs de auditoria para configurações de regras e objetos devem ser visualizados em uma lista diferente da que exibe os logs relacionados a tráfego de dados.

8.2.26. Possuir a capacidade de personalização de gráficos como barra, linha e tabela para inserção aos relatórios

8.2.27. Deve possuir mecanismo "Drill-Down" para navegação nos relatórios em realtime;

8.2.28. Dever ser possível fazer download dos arquivos de logs recebidos

8.2.29. Deve possuir agendamento para gerar e enviar automaticamente relatórios

8.2.30. Permitir customização de quaisquer relatórios fornecidos pela solução, exclusivamente pelo administrador, adaptando-o às suas necessidades.

8.2.31. Permitir o envio de maneira automática de relatórios por email

8.2.32. Deve permitir a escolha do email a ser enviado para cada relatório escolhido

8.2.33. Permitir programar a geração de relatórios, conforme calendário definido pelo administrador

8.2.34. Deve ser possível definir filtros nos relatórios

8.2.35. Deve ser capaz de definir o layout do relatório, incluir gráficos, inserir textos e imagens, alinhamento, quebras de páginas, definir fontes, cores, entre outros

8.2.36. Permitir que relatórios criado sejam no idioma Português

8.2.37. Gerar alertas automáticos via Email, SNMP e Syslog baseados em eventos como ocorrência como log, severidade de log, entre outros

8.2.38. Deve permitir a criação de Dashboards customizados para visibilidades do tráfego de aplicativos, categorias de URL, ameaças, serviços, países, origem e destino;

8.2.39. Deve ser capaz de criar consultas SQL ou semelhante para uso nos gráficos e tabelas de relatórios

8.2.40. Ter a capacidade de visualizar na GUI da solução de relatórios informações do sistema como licenças, memória, disco, uso de CPU, taxa de logs por segundo recebidos, total de logs diários recebidos, alertas gerados entre outros

8.2.41. Deve possuir a informação de Indicador de Compromisso (IoC)

8.2.42. Deve possuir uma ferramenta para análise de desempenho para cada relatório gerado, com o objetivo de detectar problemas de performance de sistema de acordo com o relatório criado.

8.2.43. Permitir que a solução busque log arquivados de outros dispositivos da mesma solução

8.2.44. Deve possuir relatório de PCI DSS Compliance

8.2.45. Deve ser possível definir o espaço que cada instância de virtualização poderá utilizar para armazenamento de logs

8.2.46. A solução deve servir como um servidor de syslog e aceitar logs de diferentes fabricantes

8.2.47. Deve suportar duplo fator de autenticação (token) para os administradores do sistema de relatórios

8.2.48. Deve permitir aplicar políticas de senhas para os administradores do sistema como tamanho mínimo e caracteres a usar

8.2.49. Deve permitir ver em tempo real os logs recebidos

8.3. Suporte técnico e licenciamento

8.3.1.Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

8.3.2.Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

8.3.3.Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

8.3.4.A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados; 8.3.5.Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo

possível solicitar atendimento em língua portuguesa;

0.0.0.Xx apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

8.4. Serviços de configuração

8.4.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento. Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada

8.4.2. Configurações básicas de conectividade

8.4.3. Registro e ativação de licenças

8.4.4. Atualização de software

8.4.5. Configuração para receber logs dos firewalls

8.4.6. Configuração de relatórios periódicos

8.5. Treinamento

8.5.1.Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel.

8.5.2. Operação da ferramenta de relatórios;

8.5.3. Customização dos relatórios;

8.5.4. Procedimento de backup e restore da base de dados;

8.5.5. Manutenção;

LOTE 1 - ITEM 9

9. SOFTWARE DE RELATÓRIOS TIPO II

9.1. Características Gerais

9.1.1. Deve ser do mesmo fabricante dos itens de firewall, a fim de garantir compatibilidade;

9.1.2. Deve estar licenciado para coletar logs e gerar relatório de múltiplos firewalls;

9.1.3. Possuir capacidade receber ao menos 5GBytes de logs diários

9.1.4. Caso a solução de coleta de logs e relatórios seja ofertada em appliance físico deverá possuir:

9.1.4.1. Possuir ao menos 4 interfaces de 1Gbps RJ-45;

9.1.4.2. Possuir ao menos 16GB de memória RAM;

9.1.4.3. Possuir ao menos um processador octacore;

9.1.4.4. Possuir ao menos 3 TB de armazenamento configurados em RAID 1

9.1.5. Caso a solução de gerenciamento seja ofertada em appliance virtual deverá:

9.1.5.1. Ser compatível com ambiente VMware ESXi 5.5;

9.1.5.2. Deve estar licenciado para pelo menos 3 TB de espaço em disco

9.1.5.3. Não deve possuir limite na quantidade de múltiplas vCPU caso virtual;

9.1.5.4. Não deve possuir limite para suporte a expansão de memória RAM caso virtual;

9.2. Funcionalidades da Solução de Relatórios

9.2.1. Deve suportar acesso via SSH, WEB (HTTPS) e Telnet para o gerenciamento da solução.

9.2.2. Possuir comunicação cifrada e autenticada com usuário e senha para solução de relatórios, tanto como para a interface gráfica de usuário e console de administração por linha de comandos (SSH)

9.2.3. Permitir acesso simultâneo de administradores permitindo a criação de ao menos 2 (dois) perfis para administração e monitoração

9.2.4. Suportar SNMP versão 2 e versão 3 na solução de relatórios

9.2.5. Permitir virtualizar a solução de relatórios, onde cada administrador gerencie, visualize e edite apenas os dispositivos autorizados e cadastrados no seu ambiente virtualizado

9.2.6. Deve permitir a criação de administradores que acessem à todas as instâncias de virtualização da solução de relatórios

9.2.7. Deve permitir habilitar e desabilitar, para cada interface de rede da solução de relatórios, permissões de acesso HTTP, HTTPS, SSH, SNMP e Telnet

9.2.8. Autenticação integrada a servidor Radius

9.2.9. Geração de relatórios com mapas geográficos ou modo tabela gerados em tempo real para a visualização de origens e destinos do tráfego gerado na instituição;

9.2.10. Autenticação integrada ao Microsoft Active Directory

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

9.2.12. Xxxx possuir um assistente para adicionar dispositivos via interface gráfica usando o IP, login e senha do mesmo

9.2.13. Deve ser possível visualizar a quantidade de logs enviado de cada dispositivo monitorado

9.2.14. Possuir mecanismo para que logs antigos sejam removidos automaticamente

9.2.15. Permitir a importação e exportação de relatórios

9.2.16. Deve ser possível exportar os logs em CSV

9.2.17. Geração de logs de auditoria detalhados, informando a configuração realizada, o administrador que a realizou e o horário da alteração

9.2.18. Os logs gerados pelos appliances devem ser centralizados nos servidores de gerência, mas a solução deve oferecer também a possibilidade de utilização de um syslog externo ou similar

9.2.19. A solução deve possuir relatórios pré-definidos

9.2.20. Possuir envio automático de logs para um servidor FTP externo a solução

9.2.21. Possibilitar a duplicação de relatórios existentes e edita-los logo após

9.2.22. Possuir a capacidade de personalização de capas para os relatórios

9.2.23. Possibilitar a duplicação de gráficos existentes de relatórios

9.2.24. Permitir de forma centralizada visualizar os logs recebidos por um ou vários dispositivos externos incluindo a capacidade de uso de filtros nas pesquisas deste log

9.2.25. Logs de auditoria para configurações de regras e objetos devem ser visualizados em uma lista diferente da que exibe os logs relacionados a tráfego de dados.

9.2.26. Possuir a capacidade de personalização de gráficos como barra, linha e tabela para inserção aos relatórios

9.2.27. Deve possuir mecanismo "Drill-Down" para navegação nos relatórios em realtime;

9.2.28. Dever ser possível fazer download dos arquivos de logs recebidos

9.2.29. Deve possuir agendamento para gerar e enviar automaticamente relatórios

9.2.30. Permitir customização de quaisquer relatórios fornecidos pela solução, exclusivamente pelo administrador, adaptando-o às suas necessidades.

9.2.31. Permitir o envio de maneira automática de relatórios por email

9.2.32. Deve permitir a escolha do email a ser enviado para cada relatório escolhido

9.2.33. Permitir programar a geração de relatórios, conforme calendário definido pelo administrador

9.2.34. Deve ser possível definir filtros nos relatórios

9.2.35. Deve ser capaz de definir o layout do relatório, incluir gráficos, inserir textos e imagens, alinhamento, quebras de páginas, definir fontes, cores, entre outros

9.2.36. Permitir que relatórios criado sejam no idioma Português

9.2.37. Gerar alertas automáticos via Email, SNMP e Syslog baseados em eventos como ocorrência como log, severidade de log, entre outros

9.2.38. Deve permitir a criação de Dashboards customizados para visibilidades do tráfego de aplicativos, categorias de URL, ameaças, serviços, países, origem e destino;

9.2.39. Deve ser capaz de criar consultas SQL ou semelhante para uso nos gráficos e tabelas de relatórios

9.2.40. Ter a capacidade de visualizar na GUI da solução de relatórios informações do sistema como licenças, memória, disco, uso de CPU, taxa de logs por segundo recebidos, total de logs diários recebidos, alertas gerados entre outros

9.2.41. Deve possuir a informação de Indicador de Compromisso (IoC)

9.2.42. Deve possuir uma ferramenta para análise de desempenho para cada relatório gerado, com o objetivo de detectar problemas de performance de sistema de acordo com o relatório criado.

9.2.43. Permitir que a solução busque log arquivados de outros dispositivos da mesma solução

9.2.44. Deve possuir relatório de PCI DSS Compliance

9.2.45. Deve ser possível definir o espaço que cada instância de virtualização poderá utilizar para armazenamento de logs

9.2.46. A solução deve servir como um servidor de syslog e aceitar logs de diferentes fabricantes

9.2.47. Deve suportar duplo fator de autenticação (token) para os administradores do sistema de relatórios

9.2.48. Deve permitir aplicar políticas de senhas para os administradores do sistema como tamanho mínimo e caracteres a usar

9.2.49. Deve permitir ver em tempo real os logs recebidos

9.3. Suporte técnico e licenciamento

9.3.1.Suporte técnico do fabricante na modalidade 8x5h durante 36 meses;

9.3.2.Todas as funcionalidades de segurança que necessitem de atualização deverão estar licenciadas para 36 meses;

9.3.3.Durante a vigência do suporte técnico deverá estar inclusa atualização de software sem nenhum custo adicional;

9.3.4.A prestação do suporte técnico não poderá haver limites no quantitativo de abertura de chamados; 9.3.5.Os chamados deverão ser abertos através de portal WEB e através de telefone 0800, sendo

possível solicitar atendimento em língua portuguesa;

0.0.0.Xx apresentação da proposta comercial a proponente deverá fornecer declaração do fabricante, em papel timbrado, dos produtos ofertados, declarando que a proponente possui credenciamento do mesmo para realizar a instalação, configuração, treinamento e suporte técnico pós-venda de seus produtos.

9.4. Serviços de configuração

9.4.1. Instalação deverá ser realizada presencialmente na localidade da UFSJ e em outras localidades através de ferramentas de acesso remoto como GoToMeeting, Webex, Ammy, ou qualquer outro que permita acesso remoto ao equipamento.

Todo o trabalho de instalação física e conexões de cabos serão realizadas pela equipe da contratante sob orientação dos técnicos da contratada

9.4.2. Configurações básicas de conectividade

9.4.3. Registro e ativação de licenças

9.4.4. Atualização de software

9.4.5. Configuração para receber logs dos firewalls

9.4.6. Configuração de relatórios periódicos

9.5. Treinamento

9.5.1.Treinamento realizado através de ferramentas de conferência remota como GoToMeeting, Webex ou qualquer outro que permita apresentação e comunicação via VoIP com carga horária mínima de 24 horas. Material disponibilizado em PDF para acompanhamento do curso e entrega de certificado de conclusão em papel.

9.5.2. Operação da ferramenta de relatórios;

9.5.3. Customização dos relatórios;

9.5.4. Procedimento de backup e restore da base de dados;

9.5.5. Manutenção;

XXXXX XX

XXXXXXXXXXXX XXXXXXX XX XXX XXXX XXX XXX

XXX XX XXXXXXXX XX XXXXXX Xx XXX/2016 PREGÃO Nº 100/2016

PROCESSO Nº 23122.022278/2016-22

Aos ............... dias do mês de .......... de 2016, a FUNDAÇÃO UNIVERSIDADE FEDERAL DE SÃO

XXXX XXX-XXX, com sede à Xxxxx Xxxx Xxxxxxx, 000, Xxxxxx, CEP: 36.307-352, São João del-Rei, MG, neste ato representada pela Pró-Reitora de Administração, Xxxx Xxxxx Xxxxxxxxx Vale e de

outro lado, a

empresa

, CNPJ nº

, com sede no

                        telefone nº         , e-mail                representada por seu      , Sr.          , RG nº         , CPF nº

          , RESOLVEM registrar os preços da empresa indicada e qualificada nesta ATA, de acordo com a classificação por ela alcançada e na quantidade cotada, atendendo as condições previstas no edital, sujeitando-se as partes às normas constantes na Lei nº 8.666, de 21 de junho de 1993 e suas alterações, no Decreto n.º 7.892, de 23 de janeiro de 2013, e em conformidade com as disposições a seguir:

CLÁUSULA PRIMEIRA – DO OBJETO

1.1 - A presente Xxx tem por objeto o registro de preços para a eventual aquisição de solução de segurança global (firewall) para atendimento aos seis campi da Universidade Federal de São João del-Rei, especificado no itens do Termo de Referência, Pregão nº 100/2016, que é parte integrante desta Ata, assim como a proposta vencedora, independentemente de transcrição.

CLÁUSULA SEGUNDA – DOS PREÇOS, ESPECIFICAÇÕES E QUANTITATIVOS

2.1 - O preço registrado, as especificações do objeto, a quantidade, fornecedor(es) e as demais condições ofertadas na(s) proposta(s) são as que seguem:

Item Especificação Unid. Quant. Marca Preço Unitário R$

CLÁUSULA TERCEIRA – ÓRGÃOS PARTICIPANTES

3.1 - São órgãos e entidades públicas participantes do registro de preços:

Item Órgãos Participantes Unidade Quantidade

CLÁUSULA QUARTA – VALIDADE DA ATA

4.1 - A validade da Ata de Registro de Preços será de 12 meses, a partir da sua assinatura, não podendo ser prorrogada, durante o qual a UFSJ não será obrigada a adquirir o material referido, exclusivamente pelo Sistema de Registro de Preços, podendo fazê-lo mediante outra licitação quando julgar conveniente, sem que caiba recursos ou indenização de qualquer espécie às empresas detentoras, ou, cancelar a Ata, na ocorrência de alguma das hipóteses legalmente previstas para tanto, garantidos à detentora, neste caso, o contraditório e a ampla defesa.

CLÁUSULA QUINTA – REVISÃO E CANCELAMENTO

5.1 - A Administração realizará pesquisa de mercado periodicamente, em intervalos não superiores a 180 (cento e oitenta) dias, a fim de verificar a vantajosidade dos preços registrados nesta Ata.

5.2 - Os preços registrados poderão ser revistos em decorrência de eventual redução dos preços praticados no mercado ou de fato que eleve o custo do objeto registrado, cabendo à Administração promover as negociações junto ao(s) fornecedor(es).

5.3 - Quando o preço registrado tornar-se superior ao preço praticado no mercado por motivo superveniente, a Administração convocará o(s) fornecedor(es) para negociar(em) a redução dos preços aos valores praticados pelo mercado.

5.4 - O fornecedor que não aceitar reduzir seu preço ao valor praticado pelo mercado será liberado do compromisso assumido, sem aplicação de penalidade.

5.4.1 - A ordem de classificação dos fornecedores que aceitarem reduzir seus preços aos valores de mercado observará a classificação original.

5.5 - Quando o preço de mercado tornar-se superior aos preços registrados e o fornecedor não puder cumprir o compromisso, o órgão gerenciador poderá:

5.5.1 - liberar o fornecedor do compromisso assumido, caso a comunicação ocorra antes do pedido de fornecimento, e sem aplicação da penalidade se confirmada a veracidade dos motivos e comprovantes apresentados; e

5.5.2 - convocar os demais fornecedores para assegurar igual oportunidade de negociação.

5.6 - Não havendo êxito nas negociações, o órgão gerenciador deverá proceder à revogação desta ata de registro de preços, adotando as medidas cabíveis para obtenção da contratação mais vantajosa.

5.7 - O registro do fornecedor será cancelado quando:

5.7.1 - descumprir as condições da ata de registro de preços;

5.7.2 - não retirar a nota de empenho ou instrumento equivalente no prazo estabelecido pela Administração, sem justificativa aceitável;

5.7.3 - não aceitar reduzir o seu preço registrado, na hipótese deste se tornar superior àqueles praticados no mercado; ou

5.7.4 - sofrer sanção administrativa cujo efeito torne-o proibido de celebrar contrato administrativo, alcançando o órgão gerenciador e órgão(s) participante(s).

5.8 - O cancelamento de registros nas hipóteses previstas nos itens 5.7.1, 5.7.2 e 5.7.4 será formalizado por despacho do órgão gerenciador, assegurado o contraditório e a ampla defesa.

5.9 - O cancelamento do registro de preços poderá ocorrer por fato superveniente, decorrente de caso fortuito ou força maior, que prejudique o cumprimento da ata, devidamente comprovados e justificados:

5.9.1 - por razão de interesse público; ou

5.9.2 - a pedido do fornecedor.

CLÁUSULA SEXTA – CONDIÇÕES GERAIS

6.1 - As condições gerais do fornecimento, tais como os prazos para entrega e recebimento do objeto, as obrigações da Administração e do fornecedor registrado, penalidades e demais condições do ajuste, encontram-se definidos no Termo de Referência, ANEXO AO EDITAL.

6.2 - É vedado efetuar acréscimos nos quantitativos fixados nesta ata de registro de preços, inclusive o acréscimo de que trata o § 1º do art. 65 da Lei nº 8.666/93.

6.3 - A ata de realização da sessão pública do pregão, contendo a relação dos licitantes que aceitarem cotar os bens ou serviços com preços iguais ao do licitante vencedor do certame, será anexada a esta Ata de Registro de Preços, nos termos do art. 11, §4º do Decreto n. 7.892, de 2014.

Para firmeza e validade do pactuado, a presente Xxx foi lavrada em 2 (duas) vias de igual teor, que, depois de lida e achada em ordem, vai assinada pelas partes.

São João del Rei, XX de XXXXXXXXX de 2016

Xxxx Xxxxx Xxxxxxxxx Xxxx Responsável pela Empresa Pró-Reitora de Administração Carimbo CNPJ

ANEXO III

DECLARAÇÃO PARA EMPRESAS OPTANTES PELO SIMPLES

DECLARAÇÃO A SER APRESENTADA PELA PESSOA JURÍDICA CONSTANTE DO INCISO XI DO ART. 4º

(Redação dada pela Instrução Normativa RFB nº 1.234, de 11 de janeiro de 2012) (Vide art. 3º da IN RFB nº 1.244/2012)

Ilmo. Sr.

(pessoa jurídica pagadora)

(Nome da empresa), com sede (endereço completo), inscrita no CNPJ sob o nº..... DECLARA à (nome da pessoa jurídica pagadora), para fins de não incidência na fonte do IRPJ, da Contribuição Social sobre o Lucro Líquido (CSLL), da Contribuição para o Financiamento da Seguridade Social (Cofins), e da Contribuição para o PIS/Pasep, a que se refere o art. 64 da Lei nº 9.430, de 27 de dezembro de 1996, que é regularmente inscrita no Regime Especial Unificado de Arrecadação de Tributos e Contribuições devidos pelas Microempresas e Empresas de Pequeno Porte - Simples Nacional, de que trata o art. 12 da Lei Complementar nº 123, de 14 de dezembro de 2006.

Para esse efeito, a declarante informa que:

I - preenche os seguintes requisitos:

a) conserva em boa ordem, pelo prazo de 5 (cinco) anos, contado da data da emissão, os documentos que comprovam a origem de suas receitas e a efetivação de suas despesas, bem como a realização de quaisquer outros atos ou operações que venham a modificar sua situação patrimonial; e

b) cumpre as obrigações acessórias a que está sujeita, em conformidade com a legislação pertinente;

II - o signatário é representante legal desta empresa, assumindo o compromisso de informar à Secretaria da Receita Federal do Brasil e à pessoa jurídica pagadora, imediatamente, eventual desenquadramento da presente situação e está ciente de que a falsidade na prestação dessas informações, sem prejuízo do disposto no art. 32 da Lei nº 9.430, de 1996, o sujeitará, com as demais pessoas que para ela concorrem, às penalidades previstas na legislação criminal e tributária, relativas à falsidade ideológica (art. 299 do Decreto-Lei nº 2.848, de 7 de dezembro de 1940 - Código Penal) e ao crime contra a ordem tributária (art. 1º da Lei nº 8.137, de 27 de dezembro de 1990).

Local e data......................................................

Assinatura do Responsável