ESTADO DE GOIÁS

SECRETARIA DE ESTADO DE DESENVOLVIMENTO E INOVAÇÃO

Contrato Nº 39/2020 - SEDI

CONTRATO DE PRESTAÇÃO DE SERVIÇO QUE ENTRE SI CELEBRAM O ESTADO DE GOIÁS, ATRAVÉS DA SECRETARIA DE ESTADO DE DESENVOLVIMENTO E INOVAÇÃO E A EMPRESA ISTI INFORMÁTICA & SERVIÇOS LTDA.

O ESTADO DE GOIÁS, pessoa jurídica de direito público interno, inscrito no CNPJ/MF sob o nº 01.409.580.0001-38, representado, legalmente, pelo Procurador do Estado Chefe da Procuradoria Setorial, nos termos da Lei Complementar 58/2006, art. 47, § 2º, Dr. XXXXXX XXXXXX XX XXXXXXXX, brasileiro, advogado, inscrito na OAB/GO sob o nº 40.221 e no CPF/MF sob o n.º 000.000.000-00, residente e domiciliado nesta Capital, por meio da SECRETARIA DE ESTADO DE DESENVOLVIMENTO E INOVAÇÃO, criada pela Lei nº 18.687/14, inscrita no CNPJ/MF sob o nº 21.652.711/0001-10, com sede administrativa situada na Rua 82, nº 400, Palácio Xxxxx Xxxxxxxx Xxxxxxxx, 1º andar, Setor Sul, em Goiânia – GO, ora representada por seu Secretário, o Sr. XXXXXX XXXXX XXXXXXX, brasileiro, casado, RG nº 22.349.454-9 SSP-SP, devidamente inscrito no CPF sob o nº 000.000.000-00, residente e domiciliado em Goiânia-GO, doravante denominada CONTRATANTE; e a empresa ISTI INFORMÁTICA & SERVIÇOS LTDA, inscrita sob o CNPJ/MF nº 10.554.387/0001-81, estabelecida na Condomínio Centro Comercial Solar 03 Xxxx 000 Bloco A Lote 10 - Bairro Setor Habitacional Jardim Botânico, Brasília/DF, CEP: 71680-349, neste ato representada pelo

(a) Sr.(a) XXXXXXX XX XXXX XXXXXXX, Brasileiro, Xxxxxx, residente e domiciliado no Condomínio Solar da Serra I, 0 Quadra J, Xxxx 02, Lago Sul, CEF: 71680-350, Brasília - DF, portador RG nº

3.145.398 SSP-DF, inscrito no CPF nº 000.000.000-00, doravante denominada simplesmente CONTRATADA, firmam o presente contrato para a prestação de serviços, mediante Processo Administrativo nº 202014304000995, e Pregão Eletrônico nº 013/2020, estando as partes sujeitas aos preceitos da Lei Federal nº 8.666 de 21/06/1993 e suas alterações, Lei Complementar Federal 123/2006, Decreto Estadual 9.666/2020, Lei Estadual nº 17.928 de 27/12/2012, Lei Complementar Estadual nº 117 de 05/10/2015, Decreto Estadual nº 7.466/2011 e demais normas regulamentares aplicáveis à espécie, e às cláusulas e condições seguintes:

1. CLÁUSULA PRIMEIRA - DO OBJETO

1.1. Contratação de empresa especializada para a prestação de serviços de Solução Integrada de Filtragem de Correio Eletrônico, para atendimento às melhores práticas de segurança da informação na utilização do correio eletrônico, assim como a utilização de filtros de conteúdo, reputação, ataques e abusos, pelo período de 12 (doze) meses., conforme demanda da SEDI, condições e especificações no Termo de Referência, anexo I do edital.

1.2. Integram este Contrato, independente de sua transcrição, o Edital de Licitação (000015023900), o Termo de Referência (000013784622) e a Proposta da CONTRATADA (000015361901) e demais elementos constantes do processo 202014304000995.

2. CLÁUSULA SEGUNDA - DA ESPECIFICAÇÃO TÉCNICA DO OBJETO E/OU DESCRIÇÃO DO SERVIÇO

2.1 DA PLATAFORMA

2.1.1. A solução integrada deve possuir controle de caixas postais e fluxo de análise de mensagens/dia ilimitadas, de acordo com os recursos de hardware disponíveis;

2.1.2. Deve ser uma solução MTA (Mail Transfer Agent) completa com suporte ao protocolo SMTP, que controla o envio e o recebimento de todas as mensagens da empresa, com registro de logs das atividades do MTA;

2.1.3. A licença de uso deve atingir ao numero caixas postais contratadas e o consumo da licença somente pode ocorrer para uma caixa postal que efetivamente realizou envio / recebimento de mensagens

2.1.4. Deve ser capaz de filtrar o tráfego de correio, bloqueando a entrada de vírus, spyware, worms, trojans, SPAM, phishing, e-mail marketing, e-mail adulto ou qualquer outra forma de ameaça virtual.

2.1.5. Deve permitir alta disponibilidade das funções de filtragem, de maneira assegurar que o serviço de correio nunca pare por falha da solução.

2.1.6. A solução deve suportar o processamento de no mínimo 20.000 (dez mil) conexões simultâneas e

160.000 (cento e sessenta mil) mensagens por hora.

2.1.7. Deve ser capaz de efetuar implementação em virtual appliance, compatível com os principais sistemas de virtualização do mercado, entre eles:

a. VMWare;

b. Citrix;

c. Microsoft Hyper-V.

2.2 DAS CERTIFICAÇÕES DE COMPATIBILIDADES E PARCERIAS

2.2.1. O antivírus utilizado na solução, deverá participar do programa “Microsoft Active Protection Program” para obtenção de informações de modo a permitir a criação de regras de proteção antes mesmo dos patches serem publicados pelo fabricante;

2.3 PONTOS GERAIS

2.3.1 A licença de uso do software base deve possuir 12 (doze) meses de atualização do fabricante compreendendo os seguintes módulos:

2.3.1.1. Atualização das assinaturas de segurança disponibilizadas automaticamente como por exemplo: assinaturas de vírus, malwares e outras ameaças, serviços de reputação de websites, IPs e assinaturas de Websites e aplicativos web;

2.3.1.2. Direito de uso da versão mais atual do produto licenciado caso esta esteja disponível pelo fabricante bom como atualizações de recursos melhorias dentro da mesma versão;

2.3.1.3. Acesso a base de inteligência global do fabricante para análise online de ameaças;

2.3.1.4 Deve possuir compatibilidade nativa com as principais soluções de mensageiria do mercado,tendo seu uso homologado e todas suas funcionalidades mantidas para integração ao microsoft exchange e zimbra;

2.3.1.5. Garantia de software contra mau funcionamento e correção de Bugs e falhas;

2.3.2 Analisar mensagens, no mínimo, por meio dos seguintes métodos:

2.3.2.1 Proteção dinâmica por reputação;

2.3.2.2 Assinaturas de spam;

2.3.2.3 Filtros de Vírus;

2.3.2.3.1 A verificação de vírus, além da técnica tradicional (por assinatura), também deve ser feito através de BigData do fabricante, bem como utilização de método Fuzzy Hash para detecção de similaridades e detecção de possível variante de malware;

2.3.2.3.2 Possuir dois módulos de antivírus, sendo um do próprio fabricante, já devidamente licenciado para uso simultâneo;

2.3.2.4 Filtros de anexos;

2.3.2.5 Filtros de phishing;

2.3.2.6 Análise heurística;

2.3.2.7 Análise do cabeçalho, corpo e anexo das mensagens;

2.3.2.8 E-mail bounce;

2.3.2.9 Dicionários pré-definidos e customizados com palavras e expressões regulares;

2.3.2.9.1 Já deve vir com dicionários pré-estabelecidos, para posterior utilização, tais como: 2.3.2.9.1.1 Número de cartão de crédito;

2.3.2.9.1.2 CNPJ;

2.3.2.9.1.3 RG e CPF;

2.3.3 Deve possuir mecanismo de backup e recuperação da configuração da solução;

2.3.4 Deve possuir capacidade de envio de backup via FTP e SFTP, sendo configurado diretamente na interface gráfica da solução (sem necessidade de qualquer configuração em linha de comando).

2.3.5 Os manuais necessários à instalação e administração da solução, devem constar no seguinte idioma: Português do Brasil;

2.3.6 A interface de administração do sistema deve ser permitida a instalação, para uso no mínimo nos seguintes idiomas:

2.3.6.1 Português do Brasil;

2.3.6.2 Inglês;

2.3.7 Deve haver a possibilidade de usar o idioma Português do Brasil para administração, manutenção e geração de relatórios;

2.3.8 Deve possuir banco de dados relacional para armazenamento dos registros de acesso, logs de sistema e configurações. Caso a solução necessite de banco de dados específico e proprietário, as licenças deste deverão ser fornecidas pela contratada junto com a solução ofertada sem ônus para o contratante. Não serão aceitas soluções baseadas em armazenamento de Logs em formato Texto;

2.3.9 Deve possuir capacidade de configuração de roteamento de mensagens para múltiplos domínios de origem e destino;

2.3.10 Deve permitir a configuração de múltiplos domínios, com aplicação de regras de forma independente para cada um dos domínios;

2.3.11 Ter a capacidade de processar o tráfego de entrada e de saída de mensagens no mesmo appliance, com base no IP e domínio de origem da mensagem, permitindo criar filtros e ações diferenciadas para cada sentido;

2.3.12 A solução deve ser capaz de efetuar a saída de e-mails indicando um IP específico para a saída de mensagens, isto é, possuir a capacidade de redirecionar as mensagens de saída por IP’s diferentes para cada domínio cadastrado no appliance se o administrador assim desejar;

2.3.13 A solução deve permitir criação de regras por:

2.3.13.1 Grupos de usuários;

2.3.13.2 Domínios;

2.3.13.3 Range de IP;

2.3.13.4 IP/Rede;

2.3.13.5 Remetentes específicos;

2.3.13.6 Destinatários específicos;

2.3.13.7 Grupos de LDAP;

2.3.14 Tratar e analisar mensagens originadas e recebidas possibilitando a aplicação de regras e políticas customizáveis, além de diferenciadas por sentido de tráfego;

2.3.15 Possibilidade de permitir relay autenticado para clientes externos da corporação;

2.3.16 Deve possuir ferramenta de auditoria de email, com facilidade de pesquisa por origem, destino, assunto e conteúdo da mensagem permitindo a concatenação dos filtros através dos operadores lógicos “e” e “ou”;

2.3.17 A console de gerenciamento deve permitir a transferência de arquivos (SCP/FTP) e ser acessada através de protocolo seguro (HTTPS – HyperText Transfer Protocol Secure) com no mínimo as seguintes funcionalidades:

2.3.17.1 Administração centralizada de todas as regras e filtros integrantes da solução;

2.3.17.2 Status da versão das assinaturas do antivírus em uso;

2.3.17.3 Controle de acesso de usuários, com diferentes privilégios de configuração;

2.3.17.4 Criação de relatórios, gráficos e estatísticas, com suporte a múltiplos domínios;

2.3.17.5 Retenção de mensagens com base nas regras em área de quarentena e gerência das áreas de quarentena pelo administrador e possibilidade do usuário gerenciar sua área de quarentena.

2.3.18 Deve possuir administração via shell, através de SSH para CLI (command line interface), para execução de comandos de administração e suporte;

2.3.19 Suporte à assinatura e validação de autenticidade de mensagens através de Domains Keys, DKIM e SPF;

2.3.20 Permitir efetuar controle profundo dos anexos das mensagens, podendo tomar ações diferenciadas para:

2.3.20.1 Conteúdo do anexo;

2.3.20.2 Mime-Type do anexo;

2.3.20.3 Extensão do anexo;

2.3.20.4 Nome completo do anexo;

2.3.20.5 Nome parcial do anexo;

2.3.20.6 Expressão regular;

2.3.20.7 Tamanho do anexo;

2.3.20.8 Figerprint do anexo (permitir efetuar upload de um exemplo de arquivo para que o sistema crie uma assinatura de identificação);

2.3.20.9 Anexos compactados com senha;

2.3.20.10 Quantidade de níveis de compactação no mesmo anexo;

2.3.21 Possuir “Zimlet” de integração com o sistema de correio eletrônico Zimbra, permitindo que através da interface Web do Zimbra seja possível marcar uma mensagem como “Spam” ou “Não Spam”, atualizando o sistema de filtragem e gerando uma nova regra para autoaprendizagem do sistema;

2.3.22 Deve possuir um sistema de Disaster e Recover, ao qual com um só botão é efetuado o upload de um arquivo de backup e restauração do mesmo automaticamente.

2.3.23 Possuir a função de abertura de relay automático para empresas que usam Microsoft Office 365, sem necessidade de cadastro de IP´s ou DNS da Microsoft para abertura de relay.

2.3.24 Deve possuir sistema de diagnóstico, com no mínimo de execução nos seguintes testes:

2.3.24.1 Teste de Conectividade TCP – Bastando informar o Host e Porta a ser testado;

2.3.24.2 Teste de Conectividade ICMP – Bastando Informar o Host a ser testado;

2.3.24.3 Teste de DNS – Bastando informar Host ou Xxxxxxx a ser testado;

2.3.24.4 Teste de Envio de E-mail;

2.3.24.5 Teste de Lookup de E-mail via LDAP;

2.3.24.6 Teste de Conectividade com o fabricante (para isso, testa-se as portas necessárias de comunicação junto ao fabricante);

2.3.24.7 Teste de TRACEROUTE;

2.3.24.8 Teste de DNS Reverso;

2.3.24.9 Teste de SPF, para checar se tem registro para um determinado domínio;

2.3.24.10 Teste de DKIM, para checar se tem registro para um domínio;

2.3.24.11 Teste de DMARC, para checar se tem registro para um domínio;

2.3.24.12 Teste de portas de Saída utilizadas pelo sistema.

2.3.25 Deve ter a capacidade de controle sobre os serviços executados no sistema, com a ação de: parar, inicializar ou reinicializar. O controle dos serviços devem ser sobre no mínimo os seguintes itens:

2.3.25.1 Serviço de antivírus;

2.3.25.2 Serviço de Controle de bounce;

2.3.25.3 Serviço de Cache do Banco de Dados;

2.3.25.4 Serviço de DKIM;

2.3.25.5 Serviço de DMARC;

2.3.25.6 Serviço de DLP;

2.3.25.7 Serviço de Mailsplit;

2.3.25.8 Serviço do Reputação das Mensagens;

2.3.25.9 Serviço de SMNP.

2.3.26 Deve permitir a instalação de agentes/plug-ins (tanto no appliance de gerenciamento, quanto nos agentes que fazem a filtragem) para monitoramento com sistemas de terceiros, tais como:

2.3.26.1 Zabbix;

2.3.26.2 Cacti;

2.3.26.3 Nagios;

2.4 DA ALTA DISPONIBILIDADE

2.4.1 Suportar Cluster de Alta Disponibilidade na forma de Cluster Ativo-Ativo e Ativo-Passivo e Load Balance através do registro MX e/ou sistemas de balanceamento proprietário, assegurando as funções de filtragem que o serviço de recebimento, processamento e entrega das mensagens não pare por falha na solução

2.4.2 Deve permitir a configuração em Cluster com appliances virtualizados em DataCenters distintos;

2.4.3 Suportar replicação completa dos registros de e-mails e quarentena, para caso seja apresentado algum problema em um dos nodes do cluster, o outro assumir todo o processamento;

2.4.4 O cluster deve poder ser formado por appliances físicos e/ou appliances virtuais, de forma mista.

2.4.5 Administração centralizada de múltiplos pontos de acesso em uma única interface web, independente se estiver em modo cluster de alta disponibilidade ou load balance de forma que o gerenciamento e a replicação de políticas do cluster também seja feita de forma centralizada;

2.4.6 A administração de todo cluster deve ser feita através de um único IP de destino, não sendo permitido a gestão de regras de forma descentralizada.

2.4.7 Possuir capacidade de replicação automática das configurações e balanceamento de carga através um único Virtual IP.

2.5 DO GERENCIAMENTO

2.5.1 O acesso à interface de administração deve possuir diferentes níveis de acesso de forma granular, permitindo que sejam configurados perfis diferentes de administradores, por endereços de e-mail e domínio permitidos;

2.5.2 O sistema deve permitir criar usuário do tipo Auditor que tenha permissão de visualizar através da interface web os e-mails que forem colocados para auditoria, sendo possível definir quais endereços de e- mails ou domínios ele poderá auditar;

2.5.3 O sistema deve possuir ainda no mínimo quatro perfis de administrador pré-definidos:

2.5.3.1 Administrador: Com acesso total às configurações da solução;

2.5.3.2 Administrador: Com acesso total às configurações da solução sem acesso à leitura dos e-mails armazenados tanto na quarentena como mensagens auditadas;

2.5.3.3 Auditor: Com acesso a visualização dos e-mails armazenados para auditoria;

2.5.3.4 Operador: Com acesso à administração da quarentena e gerenciamento da “Black e White List”;

2.5.3.5 Usuário: Possui a capacidade de administrar sua “Black e White List”, individualmente, bem como sua área de quarentena individual;

2.5.4 Permitir a criação de grupos, para posterior aplicação de regras. Os grupos poderão ser criados através das seguintes métricas:

2.5.4.1 Emails;

2.5.4.2 Domínios;

2.5.4.3 IP’s;

2.5.4.4 Range de IP;

2.5.4.5 Expressão Regular;

2.5.4.6 Usuários;

2.5.4.7 Listas de distribuição;

2.5.4.8 Grupos de LDAP.

2.5.4.9 possibilidade de utilizar todos os anteriores como exceção

2.6 DOS ALERTAS E LOGS

2.6.1 Deve enviar notificações por e-mail ao administrador, caso as atualizações não tenham sido realizadas com sucesso;

2.6.2 A solução deve ser capaz de gerar notificações a remetente e/ou destinatário com mensagem de alerta customizável;

2.6.3 Possuir registro de log de TODAS as ações executadas na interface de administração para fins de auditoria. Esse log deve ser de fácil acesso e para obtenção do mesmo, não sendo necessário acionamento da fabricante da solução;

2.6.4 Possuir mecanismo de feedback por email ao administrador sobre recursos e atualizações do sistema;

2.6.5 Deve possuir capacidade de envio dos logs de um ponto de acesso específico ou de todo o cluster para um servidor de syslog. Também deve ser possível selecionar os logs a serem enviados, bastando selecionar conforme opções indicados:

2.6.5.1 Emergency;

2.6.5.2 Alert;

2.6.5.3 Critical;

2.6.5.4 Error;

2.6.5.5 Warning;

2.6.5.6 Notice;

2.6.5.7 Informational;

2.6.5.8 Debug;

2.6.6 Deve ser possível enviar email caso ocorra consumo excessivo de algum recurso do sistema. Os sistemas monitorados para envio do email podem ser:

2.6.6.1 Espeço em disco;

2.6.6.2 Filas de email;

2.6.6.3 Memória;

2.6.6.4 Processador;

2.6.6.5 Serviço de Filtragem;

2.6.6.6 Atualização do sistema de segurança;

2.6.6.7 Antivirus e Antispam;

2.6.6.8 Ponto de acesso indisponível.

2.7 DAS FUNCIONALIDADES PARA O USUÁRIO FINAL

2.7.1 Possuir interface web de administração segura HTTPS para que o usuário final possa administrar suas opções pessoais, sem que estas opções interfiram na filtragem dos demais usuários;

2.7.2 A interface do usuário final deve estar no idioma configurado pelo administrador, sendo no mínimo os seguintes idiomas:

2.7.2.1 Português do Brasil;

2.7.2.2 Inglês;

2.7.3 O usuário final deve poder incluir e remover endereços em sua lista pessoal de bloqueio ou de liberação de e-mails;

2.7.4 O usuário final deve poder visualizar as mensagens bloqueadas e liberá-las, a seu critério, desde que as mesmas sejam consideradas somente como “possível spam” ou “spam;

2.7.5 O usuário final deve poder solicitar liberação de uma mensagem ao administrador, caso a mensagem contenha conteúdo considerado malicioso ou bloqueado por outro critério qualquer ao qual não permita que o usuário final a libere;

2.7.6 O usuário deverá poder selecionar qual o idioma utilizado sua interface, sendo no mínimo os seguintes idiomas:

2.7.6.1 Português do Brasil;

2.7.6.2 Inglês;

2.8 DA QUARENTENA

2.8.1 Permitir ao administrador da solução executar pesquisa nas áreas de quarentena de todos os usuários através de interface web segura (HTTPS), acessando o próprio appliance, sem necessidade de nenhum hardware adicional;

2.8.2 Deve possibilitar a gestão de quarentena pelos administrados de forma que o mesmo possa visualizar a razão de um determinado bloqueio, remetente, destinatário, data, assunto, IP do host destinatário, a mensagem original, tamanho da mensagem original e permitindo no mínimo as ações liberar e/ou excluir;

2.8.3 Caso uma mensagem seja bloqueada ou rejeitada, a solução deverá informar também a razão do bloqueio e quais regra foram ativadas;

2.8.4 A interface deve permitir identificar quais Regras do Modulo de AntiSpam foram ativadas e qual sua pontuação, afim de permitir ao administrador a elaboração de regras granulares;

2.8.5 A solução deve suportar a criação de áreas de quarentena personalizadas para usuários específicos;

2.8.6 Deve permitir também que todas as áreas de quarentenas sejam armazenadas de forma criptografadas no próprio appliance, seja ele virtual ou físico.

2.8.7 Deve permitir que o tempo de armazenamento da quarentena seja individual por cada área de quarentena;

2.8.8 Deve permitir a visualização do resumo de todas as áreas de quarentena e volume de mensagens;

2.8.9 O sistema de quarentena de e-mails deve criptografar automaticamente as mensagens armazenadas, evitando o acesso não autorizado aos arquivos e ao conteúdo dos e-mails armazenados em quarentena, assim aumentando a confiabilidade e segurança da solução;

2.8.10 Possibilitar ao administrador selecionar o período de expiração das mensagens na quarentena, por exemplo: manter as mensagens das últimas 72 horas, dessa forma ao ultrapassar esse limite, o sistema automaticamente começará a apagar os e-mails quarentenados mais antigos;

2.8.11 O tempo de armazenamento da quarentena deve ser individual por área de quarentena, devendo também permitir armazenamento por tempo “indeterminado”;

2.8.12 Possibilitar ao administrador selecionar o roteamento das mensagens em quarentena por tamanho da quarentena, por exemplo limitar uma quarentena a 100GB, sendo que ao ultrapassar o limite deste tamanho, o sistema automaticamente começará a apagar os e-mails quarentenados mais antigos;

2.8.13 O administrador ao criar uma quarentena customizada, deverá ter a capacidade de selecionar quais usuários poderão ter acesso a ela;

2.8.14 Pelo sigilo da informação, permitir que seja selecionada quais quarentenas customizadas somente sejam acessíveis a determinados administradores, permitindo a granularidade de acesso destas quarentenas.

2.9 DOS USUÁRIOS E GRUPOS

2.9.1 Possuir integração com serviço de diretórios LDAP, Microsoft Active Directory e Zimbra para obtenção de informações de usuários cadastrados para validação de destinatário e configuração de políticas, bem como impedir ataques de dicionário (“Directory Harvest Attack”) sem que haja necessidade de modificar os parâmetros “default” do serviço de diretórios;

2.9.2 Permitir criação de conectores para múltiplos serviços de diretório, por exemplo conector para servidor LDAP e outro conector para Microsoft Active Directory;

2.9.3 Possuir a funcionalidade de filtrar individualmente, baseado em políticas definidas por domínio, subdomínio, grupo de usuários e usuário individual, de forma integrada com ferramentas de LDAP, mesmo que a mensagem seja destinada a múltiplos destinatários, em categorias distintas;

2.9.4 Permitir a utilização de mais de um servidor de LDAP, para autenticação dos usuários em outro servidor LDAP, caso ocorra indisponibilidade do servidor primário de LDAP;

2.9.5 Integração nativa com os principais sistemas de colaboração do mercado, entre eles:

2.9.5.1 Microsoft Exchange®;

2.9.5.2 Zimbra Collaboration Suite®;

2.9.5.3 IBM Lotus Domino®;

2.9.6 Possibilitar a customização de regras e políticas por usuários ou grupos;

2.9.7 A solução deverá permitir a configuração do intervalo de sincronismo entre a solução anti-spam e o serviço de diretório;

2.9.8 Permitir atrelar grupos a regras específicas de rotas, por exemplo: Não aplicar determinada regra do módulo de anti-vírus para os e-mails que vierem de um determinado domínio, sendo que esta regra somente será aplicada a um grupo específico de usuários.

2.10 DOS RELATÓRIOS

2.10.1 Deve permitir a geração de relatórios de todos os appliances de um cluster de forma centralizada através de uma única interface web no console de gerenciamento;

2.10.2 Deve ser capaz de gerar relatórios gráficos e agendar o envio dos mesmos a usuários específicos via e- mail;

2.10.3 Permitir a seleção de dados para a formulação de relatórios por data ou por um intervalo de tempo específico;

2.10.4 Deve permitir a configuração de um período para a retenção de dados para a formulação de relatórios;

2.10.5 Capacidade de criar relatórios globais e por domínio contendo no mínimo as seguintes informações:

2.10.5.1 Sumário de mensagens;

7.10.5.2 Quantidade de mensagens processadas;

2.10.5.3 Principais origens de spam por domínio, endereço de e-mail;

2.10.5.4 Principais destinos de spam por domínio, endereço de e-mail;

2.10.5.5 Principais origens de vírus;

2.10.5.6 Principais fontes de ataque;

2.10.5.7 Estatísticas da quarentena;

2.10.5.8 Conexões completadas X bloqueadas;

2.10.5.9 Relatório de tráfego;

2.10.5.10 Principais destinatários de Spam

2.10.5.11 Principais destinatários de e-mail;

2.10.5.12 TOP Attachments;

2.10.5.13 TOP SPF Violations;

2.10.5.14 TOP Ataques por fraude de email / tentativa de spoof;

2.10.6 Permitir filtros de relatórios com definição de origem e destinos específico;

2.10.7 Possuir relatórios estatísticos de conexões, ameaças, quarentena, SPAM;

2.10.8 Deve apresentar estatísticas e monitoramento em tempo real (online) de e-mails com base em gráficos;

2.10.9 Capacidade de remoção automática das mensagens em quarentena de acordo com as configurações definidas pelo administrador do sistema;

2.10.10 Os relatórios no mínimo devem poder ser filtrados por:

2.10.10.1 Período de tempo;

2.10.10.2 Ponto de Filtragem que o email passou;

2.10.10.3 De;

2.10.10.4 Para;

2.10.10.5 Qual a classificação que a mensagem atingiu, dentre eles no mínimo:

2.10.10.5.1 DLP;

2.10.10.5.2 Provável SPAM;

2.10.10.5.3 SPAM;

2.10.10.5.4 Vírus;

7.10.10.5.5 Conteúdo Bloqueado;

2.10.10.5.6 Whitelist;

2.10.10.5.7 Blacklist;

2.10.10.5.8 Tamanho Excedido;

2.10.10.5.9 Phishing.

2.10.10.6 Relatório para um único usuário ou Xxxxxxx.

2.10.11 Para evitar agendamento de múltiplos relatórios, dessa forma consumindo recursos desnecessários do sistema, o appliance deve possuir um sistema de relatório integrado e com isso, em um único relatório agendado agrupa-se no mínimo os seguintes os relatórios:

2.10.11.1 Relatório de Volume de Mensagens por Data;

2.10.11.2 Relatório dos Principais Destinatários de SPAM;

2.10.11.3 Relatório dos Principais Remetentes de SPAM;

2.10.11.4 Relatório de Top E-mail Relays;

2.10.11.5 Relatório de Top Remetentes por Quantidade;

2.10.11.6 Relatório de Top Remetentes por Volume;

2.10.11.7 Relatório de Top Destinatário por Quantidade;

2.10.11.8 Relatório de Top Destinatário por Volume;

2.10.11.9 Relatório de Vírus;

2.10.11.10 Relatório de Estatísticas da Quarentena.

2.11 DO RASTREAMENTO DAS MENSAGENS

2.11.1 Permitir o rastreamento de mensagens, independente de qual equipamento do cluster processou, de forma centralizada e por meio da interface de gerenciamento HTTPS (não será aceito pesquisa via linha de comando);

2.11.2 O rastreamento deve ser possível através de qualquer um dos seguintes campos:

2.11.2.1 ID da mensagem;

2.11.2.2 Email do Remente;

2.11.2.3 Email do Destinatário;

2.11.2.4 Domínio do Remetente;

2.11.2.5 Domínio do Destinatário;

2.11.2.6 Assunto da mensagem;

2.11.2.7 Nome do anexo;

2.11.2.8 Palavra contida no conteúdo do corpo da mensagem;

2.11.2.9 IP de Origem da mensagem;

2.11.2.10 Tamanho da mensagem;

2.11.2.11 Regra de SPAM;

2.11.2.12 Regra de DLP;

2.11.2.13 Se a mensagem foi entregue ou não;

2.11.2.14 Regras personalizadas aplicadas na mensagem;

2.11.2.15 Nome da ameaça encontrada.

2.11.3 A console deve apresentar ainda as seguintes características de rastreamento de mensagens:

2.11.3.1 Rastreamento completo de mensagens aceitas, retidas e rejeitadas, desde o recebimento da mensagem pelo IP cliente até a entrega para o IP destino, usando como filtro o assunto, o remetente, o destinatário, regra de bloqueio, conteúdo do corpo a mensagem, data, status, hora de entrega da mensagem permitindo a concatenação dos filtros através dos operadores lógicos “e” e “ou”;

2.11.3.2 O rastreamento deve ser a partir de uma única interface de gerenciamento independente de qual appliance filtrou a mensagem, não sendo aceito pesquisa via linha de comando;

2.11.3.3 O rastreamento deverá ter a opção de ser efetuado de todos os pontos de filtragem, sem a obrigatoriedade de separação de um único ponto de filtragem por vez;

2.11.3.4 Deve apresentar como resultado as seguintes informações:

2.11.3.4.1 Remetente da mensagem;

2.11.3.4.2 Destinatários da mensagem;

2.11.3.4.3 Servidor de origem;

2.11.3.4.4 Se foi armazenada em quarentena;

2.11.3.4.5 Se continha vírus

2.11.3.4.6 A regra que atuou;

2.11.3.4.7 O servidor de origem;

2.11.3.4.8 O tamanho da mensagem;

2.11.3.4.9 Se foi entregue ou não;

2.11.3.4.10 Qual ponto de filtragem utilizado (qual appliance processou a mensagem);

2.11.3.5 No caso de a mensagem ter sido entregue, deve ser possível a apresentação do log de entrega da mesma e para qual IP entregue;

2.11.3.6 Se o email tiver sido bloqueado por ser considerado spam ou possível spam, deve apresentar os filtros aplicados, bem como a pontuação apresentada por cada filtro e explicação do que representa o filtro aplicado (para facilidade do entendimento do administrador);

2.11.3.7 Deve ser capaz de visualizar a fila de e-mails em tempo real, bem como o sentido do email na fila (se é fila de entrada de email ou saída de email), indicando total de emails na fila de saída, total de emails na fila de entrada e total de emails com erros na entrega;

2.11.3.8 Rastrear emails à partir de uma determinada ameaça.

2.11.3.9 Apresentar na interface gráfica as fontes de ataque e através delas, apresentar quais emails recebidos, originários dessa fonte de ataque;

2.11.3.10 Apresentar em mapa geográfico da localização das fontes de ataque.

2.12 DA PROTEÇÃO CONTRA ATAQUES

2.12.1 A solução deve ser capaz de bloquear ataques de negação de serviço (Denial of Service);

2.12.2 Ser uma solução MTA (Mail Transfer Agent) completa suportando o protocolo SMTP, e com Suporte a envio e recebimento de e-mails criptografados utilizando o protocolo TLS/ SSL, permitindo configurar domínios onde o TLS é mandatório;

2.12.3 A solução deverá possuir a capacidade de executar as seguintes ações:

2.12.3.1 Limitar o número de conexões TCP permitidas através de um valor configurável;

2.12.3.2 Rejeitar a conexão SMTP que se caracterize como "flooding";

2.12.4 Deve ser capaz de efetuar a filtragem do trafego de correio eletrônico bloqueando a entrada de:

2.12.4.1 Vírus;

2.12.4.2 Spyware;

2.12.4.3 Worms;

2.12.4.4 Trojans;

2.12.4.5 Spam;

2.12.4.6 Phishing;

2.12.4.7 e-mail Marketing, ou qualquer outra forma de ameaça virtual;

2.12.5 Deve possuir controle total da comunicação permitindo restringir:

2.12.5.1 IP reverso mal configurado;

2.12.5.2 Domínios inexistentes;

2.12.5.3 Permitir identificar e bloquear e-mails vindos de domínios recentemente cadastrados;

2.12.5.4 Enforce RFC821;

2.12.6 Deve permitir ao administrador criar filtros e assinaturas, bem como realizar atualização automática das mesmas, em frequência de consulta configurada pelo administrador. A frequência de atualização desta consulta deve ser de no mínimo 15 minutos, sem necessidade de interrupção do serviço;

2.12.7 A solução deve ser capaz de filtrar contra vírus as mensagens tanto de entrada quanto de saída de e- mails;

2.12.8 Permitir criação de políticas diferenciadas para tratamento de spam, vírus e filtragem de conteúdo, de acordo com o destinatário da mensagem;

2.12.9 Permitir configurar ações diferenciadas sobre as mensagens suspeitas, incluindo:

2.12.9.1 Aceitar;

2.12.9.2 Colocar em quarentena;

2.12.9.3 Inserir tag personalizada no assunto;

2.12.9.4 Marcar o cabeçalho;

2.12.10 A solução deve ser capaz de tomar as seguintes ações sobre as mensagens:

2.12.10.1 Alterar o assunto da mensagem;

2.12.10.2 Adicionar cabeçalhos para rastreamento;

2.12.10.3 Descartar a mensagem;

2.12.10.4 Colocar em uma determinada área de quarentena definida pelo administrador;

2.12.11 Deve permitir também a criação de regras baseadas no idioma que as mensagens foram escritas, com capacidade de identificar no mínimo, português, e Inglês , ou a aplicação de regras por país;

2.12.12 Possuir a capacidade de criar filtros personalizados usando expressões regulares;

2.12.13 Permitir criação de listas negras e listas brancas, com opção por domínio, subdomínio, endereço de e- mail e endereço IP;

2.12.14 Deve prover um mecanismo que impeça a sua utilização como retransmissor de mensagens originadas externamente (relay);

2.12.15 Capacidade de limitar o número máximo de mensagens enviadas por remetente a cada hora, com opção de bloqueio automático do remetente, caso esse limite seja excedido.

2.12.16 Permite criar regras customizáveis contra spammers, possibilitando um controle avançado em todo conteúdo do e-mail efetuando buscas por Expressões Regulares presentes em todo conteúdo do e-mail (SMTP HEADER, BODY, URL, ANEXOS), sendo possível criar regras compostas utilizando os operadores lógicos “E” e “OU”;

2.12.17 O fabricante da solução deve possuir seu próprio sistema de reputação (RBL), integrado à solução, com a possibilidade do administrador reportar um possível spammer. Esta consulta deve retornar os dados do remetente, com informações referentes à:

2.12.17.1 Infraestrutura de rede;

2.12.17.2 Registro em blacklists mundiais;

2.12.17.3 Configuração de serviço de notificação de envio e autenticidade de mensagens de mensagens como SPF e DKIM.

2.12.18 Capacidade de efetuar consultas externas para análise de endereço IP do remetente quanto a sua reputação, bem como verificação de Spams e phishings recebidos e outros tipos de ameaças;

2.12.19 Deve ser capaz de realizar Reverse DNS LookUp (rDNS), para validação de fontes de email;

2.12.20 Deve possuir suporte ao bloqueio de conexões de e-mails nocivos antes do diálogo SMTP, permitindo a economia de banda, armazenamento e otimização de processamento do appliance, em especial baseado em lista local de bloqueio, RBLs e SPF;

2.12.21 Deve permitir que o administrador do sistema cadastre novas RBL’s para serem utilizadas a nível de conexão SMTP;

2.12.22 Possibilidade de restringir o processamento de mensagens (relay) endereço IP;

2.12.23 Deve ter capacidade de proteção a spoofing de email (tanto Spoofing de emails na entrada – quando o hacker utiliza o domínio do órgão como remetente, como Spoofing de emails na saída – quando tem algum email de saída que não esteja com o domínio do órgão como remetente), já incrementado na solução, bastando o administrador ativar a regra, sem necessidade de customizar uma regra para isso;

2.12.24 Possuir capacidade de criar cotas de envio e recebimento de e-mails em um prazo determinado de tempo, limitando o fluxo e prevenindo ataque do tipo DOS ou distribuição de spam através de um computador infectado na rede interna;

2.12.25 Possuir mecanismo de “Engargalamento de Email” (Spam Throttling) permitindo ao administrador limitar o fluxo de mensagens recebidas de origens com baixa reputação;

2.12.26 Deve ser capaz de limitar o fluxo de mensagens automaticamente, de acordo com o volume de mensagens indevidas recebidas de um determinado IP de origem;

2.12.27 Possuir funcionalidade de verificação de DMARC (Domain-based Message Authentication Reporting & Conformance);

2.12.28 Possuir controle de xxxxxx, penalizando o remetente por um tempo configurável pelo administrador ao detectar:

2.12.28.1 Número excessivo de spams (configurado pelo administrador) oriundos de uma mesma fonte de email;

2.12.28.2 Número excessivo de vírus (configurado pelo administrador) oriundos de uma mesma fonte de email;

2.12.28.3 Número excessivo de ataques de dicionário (configurado pelo administrador) oriundos de uma mesma fonte de email;

2.12.29 Deve possuir apresentação de ameaças detectadas em tempo real. Nesse sistema de detecção de ameaças em tempo real, deve ser possível identificar:

2.12.29.1 Fontes de ataque;

2.12.29.2 Ameaças encontradas;

2.12.29.3 Ameaças Identificadas.

2.13 DA PROTEÇÃO CONTRA SPAM E PHISHING

2.13.1 Possuir filtro de anti-spam para detecção de spams usando no mínimo as seguintes tecnologias:

2.13.1.1 FingerPrint: Filtro por assinatura de spam;

2.13.1.2 Análise Heurística: Análise completa de toda mensagem contra spam, de acordo com as características da mensagem;

2.13.1.3 Análise de Documentos: Análise de documentos anexados na mensagem (PDF, DOC, DOCX e TXT);

2.13.1.4 Análise de Imagens: Filtragem de spam em imagens;

2.13.1.5 Filtro de URL: Filtragem por URL mal-intencionada contidas na no corpo da mensagem, dessa forma combatendo possível e-mail Phishing;

2.13.2 Filtro de URL com Categorização – Permitir ao administrador definir através de categorias, com no mínimo 10 categorias, divididas por assunto, possibilitando ao administrador definir uma pontuação. Categorias mínimas contidas na solução:

2.13.2.1 Conteúdo pornográfico;

2.13.2.2 Abuso infantil;

2.13.2.3 Redes sociais;

2.13.2.4 Racismo e ódio;

2.13.2.5 Pesquisa de empregos;

2.13.2.6 Streaming de áudio;

2.13.2.7 Streaming de vídeo;

2.13.2.8 Esportes;

2.13.2.9 Notícias;

2.13.2.10 Compras On Line;

2.13.3 Deve possuir tecnologia capaz de avaliar um link recebido em um e-mail, mesmo que escondido em um e-mail HTML e assim verificar o caminho para o qual este link está apontando, efetuando a verificação se nesta página apontada pelo link há algum formulário de solicitação de senha, usuário e outras ameaças, efetuando o bloqueio da mensagem sem a necessidade de assinatura, tornando assim a proteção mais proativa no combate a phishing;

2.13.4 Deve possuir tecnologia capaz de avaliar um link "URL" recebido em um e-mail, mesmo que escondido em um e-mail HTML e assim verificar o caminho para o qual este link está apontando, efetuando a verificação se este link encaminha para um sistema que efetua um redirecionamento automático para download de um arquivos (Tipo Zip, EXE, RAR, etc), na tentativa de enganar o usuário , efetuando o bloqueio da mensagem sem a necessidade de assinatura, tornando assim a proteção mais proativa no combate a phishing;

2.13.5 Deve permitir que o administrador cadastre novas RBL’s a serem utilizadas a nível de cálculo de SPAM. O administrador deverá ter a autonomia para selecionar quais RBL’s serão utilizadas a nível de conexão SMTP e quais serão utilizadas a nível de cálculo de SPAM;

2.13.6 Possuir no mínimo as seguintes tecnologias para prevenção e bloqueio de spam:

2.13.6.1 Recurso de Grey List;

2.13.6.2 Recurso de checagem por SPF (Sender Policy Framework) permitindo a criação de regras individuais e customizadas para usuários ou grupos, permitindo criar ações específicas para “fail” e “soft fail”, conforme descrito pelo Comitê Gestor da Internet no Brasil em seu website oficial (XXXX://xxx.xxxxxxxx.xx/xxxxx/xxx);

2.13.6.3 Recurso de checagem por Sender ID;

2.13.6.4 Recurso de checagem por assinatura DKIM;

2.13.6.5 Recurso de checagem de DNS Reverso;

2.13.6.6 Checagem de validade de domínio através de verificação da configuração da zona do DNS do remetente;

2.13.6.7 Análise de reputação de IP;

2.13.6.8 Filtros de URL;

2.13.6.9 Filtro de anti-phishing;

2.13.6.10 Consulta de RBL´s (real-time blackhole list);

2.13.6.11 Filtro bayesiano utilizando tecnologia Bayes Databases;

2.13.7 Classificar a reputação de novas origens de spam com tecnologia de classificação dinâmica. O sistema de reputação deve utilizar dados de redes globais de monitoramento de tráfego web e de e-mail, não restringindo ao fluxo de mensagens do ambiente instalado;

2.13.8 Possuir a possibilidade de criação de regras personalizadas de filtragem baseadas em:

2.13.8.1 Origens das mensagens;

2.13.8.2 Destino das mensagens;

2.13.8.3 Domínios;

2.13.8.4 Endereços de e-mails;

2.13.8.5 Expressões regulares (dicionário de palavras);

2.13.8.6 Fluxo;

2.13.8.7 Quantidade de mensagens;

2.13.8.8 Tamanho de anexo;

2.13.8.9 Número máximo de destinatários em uma única mensagem;

2.13.8.10 Tipo de arquivos em anexo;

2.13.8.11 Extensões de arquivos em anexo, identificados por Mime-Type;

2.13.8.12 Anexos criptografados;

2.13.8.13 Anexos compactados;

2.13.8.14 Níveis de compactação dos arquivos anexos;

2.13.8.15 Quantidade de anexos na mensagem;

2.13.8.16 Conteúdo HTML no corpo da mensagem;

2.13.9 Possuir mecanismo de análise de conteúdo HTML no corpo da mensagem mensagens, permitindo ao administrador desarmar as tags HTML e bloquear as mensagens, possuindo no mínimo a identificação das seguintes Tags:

2.13.9.1 “<form>”;

2.13.9.2 “<script>”;

2.13.9.3 “<iframe>”;

2.13.10 Possibilidade de criar regras para ações a serem tomadas pela ferramenta, quando as mensagens forem consideradas Confiáveis e Spams permitindo ao administrador configurar nesses casos as seguintes ações:

2.13.10.1 Entregar direto o e-mail;

2.13.10.2 Colocar em quarentena;

2.13.10.3 Remover mensagem;

2.13.10.4 Auditar mensagem;

2.13.10.5 Encaminhar a mensagem;

2.13.10.6 Notificar o destinatário;

2.13.10.7 Adicionar header na mensagem;

2.13.10.8 Transformar HTML em texto simples;

2.13.11 Possuir sistema de detecção de ataque de diretórios (DHA – Directory Harvest Attack), capaz de recusar novas conexões SMTP de uma fonte emissora, caso ela tenha enviado, em um período de tempo, mensagens a usuários inválidos/inexistentes no domínio;

2.13.12 Deve permitir regras internas para aumentar ou diminuir a probabilidade de ser SPAM com base em critérios internos da contratante, permitindo definir no mínimo: país de origem, endereço de domínio e IP do remetente;

2.13.13 A solução deve permitir a utilização de quarentena por usuário, possibilitando que cada usuário cadastrado em um controlador de diretório:

2.13.13.1 Microsoft Active Directory;

2.13.13.2 LDAP;

Esteja integrado com a solução e administre suas próprias mensagens categorizadas como spam;

2.13.14 Deve permitir a aplicação de políticas de SPAM diferentes por nome de domínio, destinatário, grupo de destinatários e por destinatário específico, integrado aos sistemas de diretório LDAP e MS Active Directory;

2.13.15 Deve ter a capacidade de rejeitar mensagens para destinatários inválidos durante o dialogo SMTP (tratar Non-Delivery Report Attack);

2.13.16 Possuir proteção contra bounce email attack através “Bounce Address Tag Verification”;

2.13.17 Deve permitir a inclusão de múltiplas listas de remetentes bloqueados, permitindo regras de bloqueio se o IP estiver presente nestas listas;

2.13.18 Deve permitir que mensagens de Falso Negativo sejam reportadas através da interface gráfica para o laboratório do fabricante ou oferecer um caminho para que mensagens de falso negativo sejam reportadas diretamente ao laboratório do fabricante;

2.13.19 Deve possuir mecanismo que permita a adição de Cabeçalho de identificação da classificação das mensagens como SPAM, a fim de integrar com sistemas de correio eletrônicos tais como:

2.13.19.1 Microsoft Exchange;

2.13.19.2 Zimbra Collaboration Suite;

2.13.19.3 Lotus Domino e outros;

2.13.20 Deve possuir mecanismo de análise e detecção de imagens pornográficas e/ou nudez, permitindo ao administrador definir a sensibilidade da detecção e a criação de regras por usuários e/ou grupos de usuários e permitindo a tomada de ações de bloquear ou liberar a mensagem.

2.14 DA PROTEÇÃO CONTRA VÍRUS

2.14.1 Possuir módulo de verificação com suporte a dois ou mais mecanismos diferentes de antivírus, executando simultaneamente;

2.14.2 Deverá ser capaz de filtrar vírus nos dois sentidos de tráfego (entrada e saída de email);

2.14.3 Possuir módulo de detecção “Hora Zero” para a identificação de novas ameaças desconhecidas pelo antivírus, colocando em determinada área da quarentena por período de tempo, até nova verificação pelo antivírus.

2.14.4 Scan de arquivos compactados recursivamente, no mínimo, 5 (cinco) camadas, contemplando no mínimo, os seguintes compactadores: .xxx, .xxx, .xxx, .xxx, .xxx, .xxx, .xxx, .xxx, .tgz e .gzip;

2.14.5 A solução deve possuir um motor antivírus e Antimalware do próprio fabricante da solução, ou um motor Antivírus e AntiMalware de terceiro já integrado a solução sem custo adicional;

2.14.6 Proteção contra Vírus, no mínimo com as tecnologias já licenciadas sem a necessidade de módulo adicional:

2.14.6.1 Dia-zero (zero-day);

2.14.6.2 Vírus outbreak;

2.14.6.3 Hora-zero (Zero-hour);

2.14.6.4 Targeted Attack protection;

2.14.7 Tomar no mínimo as seguintes ações:

2.14.7.1 Alterar o assunto da mensagem;

2.14.7.2 Adicionar cabeçalhos para rastreamento;

2.14.7.3 Descartar a mensagem;

2.14.7.4 Colocar em uma determinada área da quarentena definida pelo administrador;

2.14.7.5 Notificar o remetente e/ou destinatário com uma mensagem customizável, informando o nome do vírus;

2.14.8 Permitir quarentena automática de anexos criptografados;

2.14.9 Permitir criação de rota customizada para permitir entrada de anexos criptografados para entrega a determinados grupos de e-mails.

2.15 DAS NOTIFICAÇÕES DE QUARENTENA INDIVIDUAL DO USUÁRIO

2.15.1 A solução deverá permitir ao administrador agendar o envio do resumo das mensagens na quarentena individual do usuário (Digest) em períodos de tempo pré-configuráveis por horário e dia, possibilitando ações do usuário diretamente através dos comandos definidos neste Digest, dispensando a instalação de agentes e acesso a quarentena individual do usuário.

2.15.2 Grupos diferentes de usuários devem poder receber a notificação em horários diferentes.

2.15.3 O digest deve ser enviado em Língua portuguesa do Brasil, mas com a possibilidade de customização do texto, para todos os usuários ou para um determinado grupo de usuários;

2.15.4 Deve ser possível a customização do digest com as seguintes características alteráveis:

2.15.4.1 Email de origem;

2.15.4.2 Título/Assunto do email;

2.15.4.3 Mensagem do digest, com possibilidade de inclusão de imagens e links, bem como mudança de fonte, alinhamento e cor;

2.15.4.4 Logomarca do digest;

2.15.5 O digest deve permitir ao usuário final tomar no mínimo as ações de:

2.15.5.1 Liberar uma mensagem bloqueada;

2.15.5.2 Bloquear o remetente da mensagem (blacklist), para que as futuras mensagens do mesmo já sejam barradas;

2.15.5.3 Marcar o remetente como confiável (whitelist), para que as futuras mensagens do mesmo não sejam pontuadas como spam;

2.15.5.4 Reportar o bloqueio indevido;

2.15.5.5 Solicitar envio de novo resumo;

2.15.5.6 Acessar sua área de quarentena;

2.15.6 Deve permitir que o administrador escolha qual quarentena a ser incluída no Digest do usuário final, por exemplo incluir no Digest os e-mails quarentenados que foram considerados conteúdos maliciosos (VÍRUS).

2.16 DO DISCLAIMER

2.16.1 Capacidade de incluir “disclaimers” nas mensagens enviadas;

2.16.2 A solução deverá suportar aplicação de “disclaimers” diferenciados para usuários e grupos diferentes através da integração com o serviço de diretório LDAP;

2.16.3 A solução deverá suportar a configuração dos “disclaimers” em formato html e texto.

2.17 DA PREVENÇÃO A ROUBO DE INFORMAÇÕES (DLP) E COMPLIANCE

2.17.1 Deve possuir módulo DLP (Data Loss Prevention), já integrado na solução sem a necessidade de licenciamento adicional ou outro appliance;

2.17.2 O módulo de DLP deve analisar todo conteúdo da mensagem a fim garantir a confiabilidade das mensagens que saem da empresa, permitindo ao administrador configurar diversas ações a fim de restringir, controlar ou auditar as mensagens e informações sensíveis da empresa;

2.17.3 Deve permitir criar regras de compliance “Auditoria/Aderência” através de filtros avançados de análise da mensagem, permitindo identificar através de Dicionários (Conjunto de Palavras e Expressões Regulares) personalizados pelo administrador ou já existentes na ferramenta, dentre eles:

2.17.3.1 Identificação de CPF;

2.17.3.2 Número de cartão de crédito;

2.17.3.3 CNPJ;

2.17.4 Deve permitir a busca a partir dos dicionários de palavras dentro dos arquivos em anexo nos e-mails com suporte a no mínimo aos formatos .doc, .xls, .ppt, .pdf;

2.17.5 As regras de compliance podem ser criadas utilizando os Dicionários definidos nos seguintes campos da mensagem, podendo ser definido o número de ocorrências mínimas para execução da regra:

2.17.5.1 Cabeçalho;

2.17.5.2 URL (contidas no e-mail);

2.17.5.3 Corpo do email;

2.17.5.4 Anexos e documentos no mínimo: .DOC, .DOCX, .XLS, .XLSX, .PDF, .PPT, .PPTX e .TXT;

2.17.6 Permitir ao administrador criar regras de compliance para arquivos criptografados, possibilitando ao administrador configurar a ação a ser tomada quando um anexo criptografado é identificado. A ferramenta deve ter no mínimo três algoritmos de detecção: Mecanismo Heurístico, Myme-Type e Extensão;

2.17.7 Todos os itens do DLP devem permitir configurações através de regras que permitam ao administrador definir, no mínimo, as seguintes ações:

2.17.7.1 Entregar a mensagem;

2.17.7.2 Não entregar a mensagem;

2.17.7.3 Armazenar a mensagem para auditoria;

2.17.7.4 Notificar remetente e destinatário da mensagem;

2.17.7.5 Encaminhar a mensagem para outro destinatário;

2.17.8 Todos os itens do DLP devem permitir configurações que permitam ao administrador criar regras complexas através de operadores lógicos “E” e “OU”;

2.17.9 Deve permitir ao administrador gerar notificação (se assim desejar) ao remetente do email, indicando que o email enviado não condiz com as normas da empresa. Essa notificação poderá ser customizada de acordo com a necessidade do administrador.

2.18 DA CRIPTOGRAFIA DE E-MAIL

2.18.1 Deve possuir módulo de criptografia do próprio fabricante, já integrado na solução sem a necessidade de licenciamento adicional ou outro appliance.

2.18.2 A criptografia deve atuar na saída de e-mails que trabalhe de maneira transparente ao usuário final, sem a necessidade de plugins, agentes ou outro tipo de software e com uma interface para o destinatário das mensagens, customizável pelo administrador;

2.18.3 A console de gerenciamento do módulo de criptografia deve ser a mesma para toda a solução, não exigindo console de administração adicional;

2.18.4 Deve possibilitar ao administrador, definir quais mensagens serão criptografadas com base em no mínimo:

2.18.4.1 Assunto;

2.18.4.2 Destinatário;

2.18.4.3 Email do Remetente;

2.18.4.4 Nome do Anexo;

2.18.5 A criptografia das mensagens deve utilizar sistema de chaves gerada de forma independente;

2.18.6 Deve impossibilitar o uso de Cache de Browser para acesso as mensagens criptografadas;

2.18.7 Deve possibilitar ao administrador a indicação do tempo de expiração da mensagem criptografada;

2.18.8 Deve possibilitar ao administrador indicar se o destinatário poderá responder o email;

2.18.9 Deve possibilitar ao administrador indicar se o destinatário poderá encaminhar o email.

2.19 DO SISTEMA DE PROTEÇÃO CONTRA ATAQUES DIRIGIDOS (TARGETED ATTACK PROTECTION – TAP)

2.19.1 Deverá prover proteção contra ataques dirigidos tais como:

2.19.1.1 Spear-phishing;

2.19.1.2 Ataques Zero-Day;

2.19.1.3 Ameaças avançadas persistentes (APTs);

2.19.2 Deve possuir técnica para construção de modelos estatísticos com Big Data;

2.19.3 Deve possuir no mínimo 3 (três) camadas de proteção sendo elas:

2.19.3.1 Verificação da lista de códigos maliciosos: Verificação de campanhas de e-mails emergentes e conhecimento de novos sites maliciosos;

2.19.3.2 Análise de código: Verificação de comportamento suspeito, scripts escondidos, partes de códigos maliciosos e redirecionamento a outros sites maliciosos;

2.19.3.3 Análise Dinâmica: Utilização de “Sandbox” para simular a máquina de um usuário real e observar as alterações efetuadas no sistema;

2.19.4 Possuir acesso ao Dashboard do módulo de Segurança contra-ataques dirigidos;

2.19.5 O sistema de proteção contra-ataques dirigidos deve executar no mínimo 3 (três) etapas:

2.19.5.1 Detecção - A análise de email deve verificar variáveis em tempo real incluindo as propriedades da mensagem, bem como, o histórico de e-mail do destinatário para identificar anomalias que indiquem uma ameaça potencial;

2.19.5.2 Proteção - Deve assegurar que links para URLs suspeitas são dinamicamente reescritas antes que o e- mail seja entregue ao destinatário. Cada vez que um usuário clica em um destes links esteja ele na empresa ou em um local remoto o serviço verifica se o destino é seguro;

2.19.5.3 Ação - Deve demonstrar aos administradores e gestores de segurança em tempo real e de forma interativa uma visão dos ataques sofridos e das ameaças que posam sofrer, passando para usuários específicos, dispondo de ferramentas para ajudar a remediar danos, tudo baseado em um painel de controle on-line;

2.19.6 Não será aceita solução baseada apenas em reputação de URL.

2.19.7 A solução deve conter engine para detecção de Anomalias, não podendo se limitar a analise com definições baseadas em ataques já conhecidos.

2.19.8 A solução deve ser proativa e ter capacidade de detecção por heurística, utilizando técnicas de análise de grande volume de dados, desta forma definindo um modelo de padrão de mensagens da corporação, levando em conta remetentes, destinatários, volume de mensagens e vários outros fatores, dessa forma modelando os e-mails “Normais” da corporação e barrando “Anomalias”, fazendo essa análise e definição de padrão por caixa postal.

2.19.9 Deve ser possível habilitar ou desabilitar a proteção URL baseada em rotas especificas configuradas no mínimo pelas seguintes condições:

2.19.9.1 Email do Destinatário;

2.19.9.2 Email do Remetente;

2.19.9.3 Domínio de Origem;

2.19.9.4 Domínio de Destino;

2.19.9.5 IP/Rede;

2.19.9.6 Range de IP;

2.19.9.7 Expressão Regular;

2.19.9.8 Usuários;

2.19.9.9 Listas de distribuição;

2.19.9.10 Grupo de LDAP;

2.19.10 A proteção de URL deverá reescrever os links do e-mail e a cada clique o sistema deverá analisar a URL e somente depois de passar por todos os testes, sendo constatado que não é malicioso, deve redirecionar para a URL original. Se após a análise for constatado site malicioso, o sistema deverá exibir mensagem de alerta e o site será bloqueado no navegador;

2.19.11 O sistema deverá ser capaz varrer anexos no mínimo nas extensões PDF, Microsoft Office, arquivos em Flash para payloads maliciosos, Microsoft Office com as seguintes extensões a serem verificadas:

2.19.11.1 .swf;

2.19.11.2 .pdf;

2.19.11.3 .doc;

2.19.11.4 .xls;

2.19.11.5 .xlsx;

2.19.11.6 .ppt;

2.19.11.7 .ppt;

2.19.11.8 .pptx;

2.19.11.9 .rtf;

2.19.12 A solução deverá dispor de Dashboard alertando aos administradores de ataques por e-mail e deverá fornecer detalhes sobre o ataque direcionado, fará triagem para reduzir potenciais danos, reportando ao fabricante criando relatórios detalhados para o departamento de segurança e executivo;

2.19.13 Deverá ser capaz de efetuar a verificação da reputação de anexos e caso a reputação do anexo não conste no banco de dados, a solução deverá ter a opção de enviar automaticamente o anexo para a nuvem do fabricante para análise em tempo real em sistema de Sandbox do próprio fabricante. Este sistema de Sandbox deve conter tecnologia de detecção usando “Analise Comportamental” do arquivo identificando assim malwares e variantes sem a necessidade de assinaturas;

2.19.14 Deve possuir tecnologia SandBox local, isto é, efetuar o SandBox sem enviar o arquivo ao fabricante ou a terceiros, efetuando toda a análise de anexos dos emails localmente, atendendo dessa forma a legislação vigente brasileira (Lei Geral de Proteção de Dados Pessoais).

2.19.15 A proteção URL deverá acompanhar o destinatário na URL reescrita. Quando uma mensagem for dirigida a vários destinatários, o envelope será dividido de modo que existam apenas um receptor associado com uma URL reescrita para permitir que administradores possam controlar quais usuários clicaram na URL reescrita e os usuários que ignoraram através do Dashboard;

2.19.16 A proteção URL deverá reescrever links para os protocolos HTTP, HTTPS e FPT, URL's que comecem com “www” independente do protocolo;

2.19.17 A solução deverá permitir que o administrador configure o sistema de proteção URL reescrevendo todas as mensagens que contiverem URL e enviado ao sandbox para testes garantindo um alto nível de segurança;

2.19.18 A solução deverá prover lista de exceções de URL para que não sejam reescritas;

2.19.19 O Dashboard deverá exibir o número de cliques em cada ameaça;

2.19.20 O Dashboard deverá exibir qual usuário clicou na URL detectada como ameaça;

2.19.21 O Dashboard deverá exibir informações atualizadas sobre as ameaças detectadas, deverá exibir a classificação da mensagem e deverá exibir status atualizado e detalhado sobre as ameaça no mínimo com as seguintes informações:

2.19.21.1 Clicado – Número de vezes que uma URL reescrita foi clicada por um usuário, inclusive se a mensagem for encaminhada para outro usuário e também for clicada.

2.19.21.2 Bloqueado - Número de vezes que o modulo de Proteção URL impediu o usuário de acessar o site malicioso.

2.19.21.3 Permitida – Número de vezes que o modulo de proteção URL permitiu ao usuário acessar o site original da URL reescrita e que não foi detectada como maliciosa.

2.19.22 O Dashboard deverá exibir timeline das ameaças, exibindo quando foi recebida, identificada e quando foi clicada ou liberada;

2.19.23 No Dashboard deverá ser possível filtrar uma URL em um campo de busca para analisar todas as ocorrências com aquela URL, bem como verificar o status atual dela e preview da página web;

2.19.24 O Dashboard deverá possuir ferramenta para bloqueio ou liberação de URL pelo administrador da ferramenta;

2.19.25 No Dashboard deverá ser possível filtrar um IP em um campo de busca para analisar todas as ocorrências com aquele IP, bem como verificar o status atual dele e preview da página web;

2.19.26 O Dashboard deverá disponibilizar sistema de coleta (report) de amostra do IP para a engenharia do fabricante analisar;

2.19.27 O Dashboard deverá possuir ferramenta para bloqueio ou liberação do IP pelo administrador da ferramenta;

2.19.28 No Dashboard deverá ser possível analisar um arquivo, sendo enviado pelo administrador como amostra e retornar todas as ocorrências do arquivo enviado;

2.19.29 O Dashboard deverá possuir ferramenta para bloqueio ou liberação do arquivo pelo administrador da ferramenta;

2.19.30 A ferramenta de segurança contra ataques dirigidos, deve possuir o sistema colaborativo, ao qual o administrador poderá configurar que o usuário final possa indicar liberação e bloqueio de URL’s, mesmo analisados pelo sistema e dessa forma reportando falsos positivos e falsos negativos. Deve prover também um Dashboard onde o Administrador poderá verificar todos reportes enviados pelos usuários, ficando a cargo do administrador decidir pelo bloqueio ou a liberação de tal URL e/ou Arquivo.

2.19.31 Deve possuir módulo de CDR “Content Disarm and Reconstruction”, que quando ativado irá remover conteúdos possivelmente perigoso, em no mínimo para os seguintes tipos:

2.19.31.1 JavaScript;

2.19.31.2 Links;

2.19.31.3 Executáveis;

2.19.31.4 VB Script;,

2.19.31.5 De dentro de documentos, em no mínimo para os seguintes tipos:

2.19.31.5.1 PDF;

2.19.31.5.2 DOC;

2.19.31.5.3 DOCX;

2.19.31.5.4 PPT;

2.19.31.5.5 PPTX;

2.19.31.5.6 XLS;

2.19.31.5.7 XLSX;

2.19.32 Deve possuir capacidade de ignorar reescrita de algumas URL’s e não envio de arquivos para análise no SandBox do fabricante;

2.19.33 O SandBox do fabricante deve ter a capacidade de analisar arquivos do tipo:

2.19.33.1 .swf;

2.19.33.2 .pdf;

2.19.33.3 .doc;

2.19.33.4 .xls;

2.19.33.5 .xlsx;

2.19.33.6 .ppt;

2.19.33.7 .ppt;

2.19.33.8 .pptx;

2.19.33.9 .rtf;

2.19.34 Deve ter a opção de não fazer reescrita de URL’s em casos de mensagens criptografadas, no mínimo com os sistemas de criptografia:

2.19.34.1 PGP;

2.19.34.2 S/MIME;

2.19.34.3 DKIM;

2.19.35 Deve ter a opção de não fazer reescrita de URL’s em casos de mensagens oriundas de determinados países, por exemplo: Mensagens oriundas da China, Austrália e Belize;

2.19.36 Deve poder desativar a reescrita de URL’s se a mensagem atingir uma pontuação de mínima de SPAM definida pelo administrador;

2.19.37 Possibilidade do administrador de incluir URL’s, arquivos e IP’s em uma lista de bloqueio (Blacklist) no sistema de TAP;

2.19.38 Possibilidade do administrador de incluir URL’s, arquivos e IP’s em uma lista segura (Whitelist) no sistema de TAP.

2.20. DO SISTEMA DE PROTEÇÃO A FRAUDES DE E-MAIL:

2.20.1. A solução deverá ter a capacidade de detectar domínios recém adquiridos (tempo de considerado como recém adquirido deverá ser configurável pelo administrador) e indicar o que deve ser feito neste caso:

2.20.1.1 Pontuar;

2.20.1.2 Ignorar;

2.20.1.3 Bloquear.

2.20.2. Deve possuir capacidade de detecção de Spoofing de emails externos, isto é, ter a capacidade de comparar o domínio do cabeçalho do email (Header do Email/Envelope SMTP), com o domínio apresentado como remetente para o usuário final (Cabeçalho From) e indicar o que deve ser feito se forem diferentes:

2.20.2.1 Pontuar;

2.20.2.2 Ignorar;

2.20.2.3 Bloquear.

2.20.3. O sistema deve possuir a opção de configurar regras para detectar emails que estejam utilizando ataques do tipo Look-A-Like Domain, isto é, detectar emails com domínios similares aos domínios utilizados pelo órgão.

2.20.4. Deve possuir sistema de detecção de emails oriundos de servidores de emails gratuitos (free emails), tais como Google, Yahoo, Hotmail, etc.

2.20.5. Nativamente deve possuir sistema de detecção de emails externos (emails de entrada) que tentem utilizar o(s) domínio(s) da própria empresa como remetente, sem necessidade de criação de regra específica para este tipo de fraude.

2.21 DO TREINAMENTO

2.21.1. A capacitação deverá ser fornecida em turma de no mínimo 05 (cinco) colaboradores da área de tecnologia da CONTRATANTE;

2.21.2 O treinamento deverá ser realizado presencialmente, em infraestrutura disponibilizada pela CONTRATANTE e deverá possuir carga horária mínima de 24 (vinte e quatro) horas;

2.21.3. A capacitação deverá consistir em treinamento oficial em acordo com as políticas do fabricante da solução fornecida;

2.21.4. Deverá ser ministrado por instrutor certificado na solução;

2.21.5 .Os softwares, materiais, apostilas, profissionais, instrutores e todos os requisitos necessários à realização adequada do treinamento são de responsabilidade exclusiva da CONTRATADA.

2.21.5.1. Uma cópia do material do treinamento deverá ser enviada com antecedência mínima de 15 (quinze) dias da data de início do treinamento à CONTRATANTE, para análise e aprovação.

2.21.5.2. O material não aprovado pelo Contratante deverá ser refeito pela CONTRATADA e novamente aprovado.

2.21.6. O treinamento deverá ser ministrado em português e composto de aulas teóricas e práticas (Hands On).

2.21.7. O treinamento deverá abordar todas as funcionalidades da solução de gateway de segurança de e-mail ofertada, bem como a instalação, configuração, administração, operação, otimização, automatização de tarefas, metodologia de diagnóstico e resolução de problemas (troubleshooting), geração de relatórios, cópia de segurança (backup) e restauração, controle de acesso, auditoria e gerenciamento de logs;

2.21.8. Todas as despesas com passagens, hospedagens e alimentação dos seus instrutores no período do treinamento ficarão a cargo da CONTRATADA.

2.21.9. Após a realização da capacitação, a empresa deverá fornecer certificado de conclusão para cada participante;

2.21.10 O cronograma para realização dos eventos será definido pela CONTRATANTE em conjunto com a CONTRATADA;

2.21.10.1. O treinamento deverá ser realizado no prazo máximo até 30 (trinta) dias corridos, após a assinatura do contrato.

2.21.11. Ao final do treinamento, deverá ser realizada junto aos participantes uma avaliação do curso por meio de formulário da CONTRATADA, conforme modelo do Xxxxx XX.

2.21.11.1. Caso o curso seja avaliado como insatisfatório pelos participantes da turma, treinamento deverá ser refeito, sem ônus adicional à CONTRATANTE, respeitando as condições elencadas neste Termo de Referência.

2.21.11.2. O cálculo para avaliação insatisfatória dar-se-á da seguinte forma: A média da avaliação do curso entre os participantes for ruim ou regular.

2.21.11.3.Os critérios da avaliação são medidos como segue:Ruim(1); Regular(2);Bom(3);Ótimo(4 ou 5).

2.21.12. A CONTRATADA deverá assegurar-se que os participantes do treinamento assinem ou confirmem diariamente lista de presença. A lista deverá ser entregue à CONTRATANTE;

2.22 DA IMPLANTAÇÃO

2.22.1. Entende-se como fase em que se dará a instalação e configuração dos produtos, ou seja, efetiva implementação do projeto especificado;

2.22.2. A implantação consiste em entregar a solução em plenas condições de uso (configurada e integrada com a solução de correio eletrônico utilizada pela CONTRATANTE);

2.22.3. Todas as customizações presentes na solução atual da CONTRATANTE devem ser migradas para a nova solução;

2.22.4. Também devem ser migradas as regras presentes de forma nativa na solução atual que forem consideradas importantes pela CONTRATANTE.

2.22.5. A instalação em alta disponibilidade e testes dos produtos devem estar inclusos no custo do produto;

2.22.5.1 A alta disponibilidade é caracterizada pela instalação de 2 (dois) ou mais nós de processamento, configurados em cluster;

2.22.5.2. Caberá à contratada enviar de forma prévia documento completo informando as regras de firewall necessárias para a implantação da solução, bem como documentação clara e inequívoca acerca dos dados que serão trafegados por meio destas regras; Havendo liberações para rede externa da contratante que não do próprio fluxo de e-mails, deve ser fornecido um documento onde a contratada detalha e responsabiliza-se unica e exclusivamente pela segurança dos dados trafegados.2

2.22.6. A implementação deverá ser realizada de tal forma que as interrupções no ambiente de produção sejam as mínimas possíveis e estritamente necessárias, e, ainda, não causem transtornos aos usuários finais do órgão;

2.22.7. A CONTRATADA deverá executar uma série de testes funcionais básicos para verificar o perfeito funcionamento do ambiente. Estes testes deverão ser realizados nos componentes de hardware e software envolvidos no projeto;

2.22.7.1. A CONTRATADA deverá realizar Testes de falhas, redundância, backup e restore;

2.22.8 A CONTRATADA deverá prestar apoio na parametrização das ferramentas de monitoramento do ambiente, tais como Nagios e Zabbix;

2.22.9. Durante a execução dos serviços, pelo menos um representante do CONTRATANTE participará e fará composição na equipe designada para as atividades.

2.22.10. Ao final do processo de implantação deve ser gerado um documento detalhando os passos realizados para instalação e configuração da solução;

2.23 DO SUPORTE TÉCNICO

2.23.1. O prazo de suporte técnico da solução ofertada deverá ser de, no mínimo, 12 (doze) meses, contados a partir da data do aceite definitivo;

2.23.2. A CONTRATADA deve garantir para a CONTRATANTE o fornecimento de acesso irrestrito (24 horas x 7 dias da semana) à área de suporte do fabricante, especialmente ao endereço eletrônico (web site), a toda a documentação técnica pertinente (guias de instalação/configuração atualizados, FAQ’s, bases de conhecimento e bases de soluções, com pesquisa efetuada através de ferramentas de busca).

2.23.3. As respostas do suporte técnico contratado deverão ser efetuadas na língua portuguesa (português do Brasil), tanto por email, quanto por contato telefônico.

2.23.4 O suporte técnico deverá ser prestado em caso de falhas, necessidade de configuração de funcionalidades, dúvidas e/ou esclarecimentos de qualquer um dos produtos, módulos e programas referentes aos appliances que compõem a solução.

2.23.5. A abertura de chamados pelo CONTRATANTE será efetuada por correio eletrônico, por sistema de controle de chamados, com email de resposta do chamado aberto apresentando o número do ticket aberto, para acompanhamento.

2.23.6.A CONTRATADA deverá fornecer os níveis de atendimento conforme abaixo indicado:

2.23.6.1. Os chamados de severidade ALTA (Quando há indisponibilidade de uso da solução) deverão ser atendidos em até 1 (uma) hora após a abertura e deverão ser solucionados em até 24 (vinte e quatro) horas, contados a partir da abertura do chamado;

2.23.6.2. Os chamados de severidade MÉDIA (Quando há falha, simultânea ou não, de uma ou mais funcionalidades que não cause indisponibilidade, mas apresente problemas de funcionamento e/ou performance da solução) deverão ser atendidos em até 4 (quatro) horas após a abertura e deverão ser solucionados em até 48 (quarenta e oito) horas, contados a partir da abertura do chamado;

2.23.6.3 Os chamados de severidade BAIXA (Nível de severidade aplicado para instalação, configuração, atualização de versões e implementações de novas funcionalidades) deverão ser atendidos em até 8 (oito) horas após a abertura e deverão ser solucionados em até 72 (setenta e duas) horas, contados a partir da abertura do chamado;

2.23.6.4. Os chamados de severidade INFORMATIVO (Nível informacional ou dúvidas) deverão ser atendidos em até 16 (dezesseis) horas após a abertura;

2.23.7 A CONTRATADA deverá possuir técnico especializado na solução, com no mínimo 1 (um) técnico certificado pelo fabricante e com certificação dentro da validade.

2.24 DAS ATUALIZAÇÕES

2.24.1. Automaticamente e sem custos adicionais, deverá ser possível o acesso ao conteúdo mais recente dos produtos, funcionalidades adicionais e correções de produtos disponibilizadas pelo fabricante;

2.24.2. Deve ser possível submeter pedidos para atualização de produtos;

2.24.3. As atualizações de versões e o serviço de suporte técnico da solução deverão ser Garantidos pela Contratada, por um período de 12 (doze) meses, após a emissão de Termo de Recebimento Definitivo;

2.24.3.1. Para que as atualizações de versões estejam disponíveis durante toda a vigência do contrato, a contratada deverá estar credenciada e autorizada pelo fabricante.

2.24.3.1.1 A Contratante reserva o direito de, a qualquer momento, solicitar tais comprovações que se fizerem necessárias.

2.24.4. A contratada deverá, sem ônus adicional para o Contratante, fornecer as atualizações (“patches”) de segurança e de versão para os appliances que compõem a solução.

2.24.5. A solução deverá continuar a filtragem das mensagens em ambos os sentidos (inbound e outbound) mesmo após o término do licenciamento ou suporte.

2.25 DOS TESTES E HOMOLOGAÇÃO

2.25.1. Além da análise das informações fornecidas em documentação técnica pertinente, poderá ser realizado teste de homologação (Prova de Conceito) da solução nas instalações do contratante a fim de validar o atendimento aos requisitos básicos.

2.25.2. O teste de homologação poderá ser solicitado à licitante classificada em primeiro lugar que tiver os documentos previstos no Termo de Referência do Edital aprovados pela área técnica, podendo também ser solicitada aos demais licitantes.

2.25.3. O teste de homologação será conduzido pela contratante no local de suas instalações e tem como objetivo aferir a adequação do objeto às especificações constantes no Item 7 do Termo de referência.

2.25.4 A CONTRATADA convocado a realizar o Teste de Homologação terá o prazo de até 10 (dez) dias úteis, contados da data da convocação, para entregar uma amostra completa da solução ofertada contendo equipamentos (quando couber) acompanhado dos softwares e licenças necessárias ao seu funcionamento pelo período de 30 (trinta) dias corridos.

2.25.5 O Teste de Homologação deverá ser realizado sem custo para a CONTRATANTE pelo período de 30 (trinta) dias corridos, contados da data da entrega.

2.25.6 Xxxxx xxxxxxxxx xx xxxxx xx 00 (xxxxxx) dias corridos a instalação, a configuração e a demonstração de que os produtos atendem às especificações constantes no Item 7 do Termo de referência.

3. CLÁUSULA TERCEIRA - FORMA, PRAZO E LOCAL DA PRESTAÇÃO DO SERVIÇO

3.1. O prazo de entrega, referente ao item 1.1, é de, no máximo, 10 (dez) dias corridos, contados a partir da assinatura do contrato, devendo as licenças fornecidas constar em site oficial do fabricante.

3.2. O prazo de implantação, referente ao item 1.2, é de 20 (vinte) dias úteis a partir da assinatura do contrato.

3.3. O prazo para a realização do treinamento, referente ao item 1.3, é de 60 (sessenta) dias a partir da assinatura do contrato.

10.4. Caso a solução ofertada seja composta por equipamentos, os mesmos deverão ser de primeira qualidade, de primeiro uso, transportados e acondicionados de maneira que garanta sua integridade, acompanhados de manual do usuário em português, na forma, quantidade e prazos previstos no Instrumento Contratual e no Termo de Referência, que integram o Edital;

3.5. Caso a solução ofertada seja composta por softwares, os mesmos deverão ser entregues em formato eletrônico (CD ou DVD) ou podem ser disponibilizados através de portal web do fabricante do software, desde que sejam providos mecanismos de controle de acesso e integridade apropriados;

3.5. Os bens e serviços deverão ser entregues no local indicado pela CONTRATANTE.

3.5.1. O horário de entrega de bens será das 08:00h às 12:00h e das 13:00h às 17:00h em dias úteis, conforme horário de Brasília. Não serão recebidos produtos fora deste horário, salvo prévio acordo;

.6. Os pedidos de prorrogação de prazo de entrega só serão examinados quando formulados à CONTRATANTE até o prazo limite de entrega;

3.7. Os serviços 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 corrigidos/refeitos/substituídos no prazo fixado pelo Fiscal do contrato, às custas da CONTRATADA, sem prejuízo da aplicação de penalidades.

3.8. O Termo de Recebimento Definitivo será emitido pela Fiscalização Contratual com o término da implementação da solução;

3.9. Para o recebimento definitivo é condição indispensável, mas não única, o devido reconhecimento e emissão da licença de uso em favor da CONTRATANTE pelo fabricante, de acordo com suas regras e práticas de licenciamento. A licença deverá estar registrada no site do fabricante em nome da CONTRATANTE

3.10. Caso a licença entregue não corresponda às especificações deste Termo de Referência, a Contratada deverá providenciar sua substituição, sem quaisquer ônus adicionais para o Contratante, no prazo máximo de 10 (dez) dias, contados a partir da respectiva notificação pela Fiscalização Contratual, sem prejuízo da incidência das sanções administrativas cabíveis.

3.11. Para o item 1.3, o Termo de Recebimento Definitivo será emitido pela Fiscalização Contratual após obtida avaliação satisfatória pelos participantes da turma e entrega do certificado de participação.

3.12. O recebimento definitivo do objeto não exclui a responsabilidade da contratada por vícios e desconformidades com as especificações técnicas exigidas no Edital de Licitação e Termo de Referência, ainda que verificados posteriormente.

4. CLÁUSULA QUARTA - DO PREÇO

4.1. QUANTITATIVO E VALOR ESTIMADO:

LOTE

ITEM

DESCRIÇÃO

MÉTRICA

QTD

VALOR UNITÁRIO 12 MESES

VALOR TOTAL 12 MESES

1.1

Serviços de solução integrada Anti-Spam e Antivírus de e-mail, contemplando atualização de base de assinaturas, atualização de software e suporte técnico do fabricante, pelo período de 12 meses.

Caixas Postais

17.000

R$ 17,32

R$ 294.440,00

1.2

Serviço de implantação em alta disponibilidade de solução de gateway de segurança de e-mail

Serviço de implantação

R$ 7.960,00

1.3

Treinamento em solução de gateway de segurança de e-mail.

Aluno

R$ 1.341,33

R$ 6.706,65

Valor total da Contratação

R$ 309.106,65

4.1.1 O valor total geral para a presente contratação é de R$ 309.106,65 (trezentos e nove mil cento e seis reais e sessenta e cinco centavos).

5. CLÁUSULA QUINTA - DO PAGAMENTO

5.1 Os pagamentos serão realizados conforme abaixo:

5.1.1 Para o item 1.1, o pagamento será feito em única parcela, após a entrega e emissão do Termo de Recebimento Definitivo para o item;

5.1.2 Para o item 1.2, o pagamento será feito em única parcela, após a entrega e emissão do Termo de Recebimento Definitivo para o item;

5.1.3 Para o item 1.3, o pagamento será feito em única parcela, após a entrega e emissão do Termo de Recebimento Definitivo para o item;

5.2 Cada pagamento será efetuado em 30 (trinta) dias após a entrega da Nota Fiscal/Fatura correspondente

5.3. Na ocorrência de erros na(s) Nota(s) Fiscal(is) /Xxxxxx(s) ou situação que impeça a liquidação da despesa, aquela(s) será(ão) devolvidas(s) e o pagamento ficará pendente até que as medidas saneadoras sejam providenciadas pela CONTRATADA.

5.4. Na hipótese acima mencionada, a contagem do prazo para pagamento será iniciada após a correção dos erros identificados e reapresentação da(s) Nota(s) /Xxxxxx(s), não acarretando qualquer ônus para a CONTRATANTE.

5.5. O pagamento será efetuado em favor da CONTRATADA através de ordem bancária, devendo para isso ficar explicitado o nome da instituição financeira recebedora, agência, localidade, número da operação, quando for o caso, e número da conta corrente na qual

deverá ser depositado o crédito, que ocorrerá após a entrega dos equipamentos e mediante a aceitação e atesto na(s) Nota(s) Fiscal(is) /Fatura(s).

5.5.1 Os pagamentos somente serão efetivados por meio de crédito em conta corrente da CONTRATADA, preferencialmente na Caixa Econômica Federal - CEF, que é a Instituição Bancária contratada pelo Estado de Goiás para centralizar sua movimentação financeira, nos termos do art. 4º da Lei Estadual nº 18.364, de 10 de janeiro de 2014.

5.6. A CONTRATANTE reserva-se o direito de suspender o pagamento caso os serviços sejam entregues em desacordo com o Termo de Referência.

6. CLÁUSULA SEXTA - DO REAJUSTAMENTO E DA ATUALIZAÇÃO MONETÁRIA

6.1 Será concedido reajuste dos preços dos serviços continuados com prazo de vigência igual ou superior a 12 (doze) meses, nos termos do Art. 40, inciso XI, da Lei Federal nº 8.666/1993, mediante requisição da CONTRATADA e desde que observado o interregno mínimo de 01 (um) ano. O interregno mínimo de 01 (um) ano será contato:

6.1.1 Para o primeiro reajuste: a partir da data da apresentação das propostas constante do instrumento convocatório.

6.1.2 Para os reajustes subsequentes ao primeiro: a partir da data dos efeitos financeiros do último reajuste.

6.2 O reajuste dos preços será feito pela aplicação do IPCA (Índice Nacional de Preços ao Consumidor Amplo), ou outro índice que venha a substituí-lo, observado os preços praticados no mercado.

6.3 Os novos valores contratuais decorrentes do reajuste terão suas vigências iniciadas após a assinatura do Termo de Apostilamento, respeitado o interregno mínimo estabelecido no item 6.1.

7. CLÁUSULA SÉTIMA - DA DOTAÇÃO ORÇAMENTÁRIA

7.1. As despesas decorrentes do presente contrato, cujo valor total estimado é de R$ 309.106,65 (trezentos e nove mil cento e seis reais e sessenta e cinco centavos), correrão à conta da Dotação Orçamentária 2020.31.01.04.126.1019.2074.03, Fonte 100, constante do vigente Orçamento Geral do Estado.

8. CLÁUSULA OITAVA - DA GESTÃO DO CONTRATO

88.2. A Gestão de todo o procedimento de contratação, inclusive o acompanhamento, fiscalização ou execução administrativa do contrato, será feita por servidor especialmente designado para tal finalidade, mediante edição de portaria pela Contratante, conforme disposto no Art. 67 da Lei Federal n.º 8.666/93, e art. 51 e 52 da Lei Estadual 17.928/2012.

9. CLÁUSULA NONA - DAS OBRIGAÇÕES

9.1. DA CONTRATADA

9.1 Deverá nomear e apresentar preposto para representá-la durante o período de vigência do contrato;

9.2 Deverá executar fielmente o objeto contratado, de acordo com as normas legais;

9.3 Dar integral cumprimento a sua proposta, a qual passa a integrar este instrumento, independentemente de transcrição;

9.4 Disponibilizar solução computacional de apoio à execução dos serviços conforme requisitos estabelecidos neste Termo de Referência;

9.5 Cumprir o prazo máximo de entrega, contados a partir da assinatura do instrumento contratual;

9.6 Responder por qualquer prejuízo causado à Administração ou a terceiros por seus empregados ou prepostos, no cumprimento e execução dos serviços, reparando os danos eventualmente causados;

9.7 Assumir inteira responsabilidade pelo fornecimento e entrega dos serviços contratados, não podendo transferi-los a outrem, no todo ou em parte, sem prévia e expressa anuência da CONTRATANTE;

9.8 Atender prontamente quaisquer orientações e exigências do Gestor e Fiscais do Contrato, inerentes à execução do objeto contratual;

9.9 Executar fielmente os serviços contratados de acordo com as exigências do Contrato Administrativo, do Termo de Referência, do Edital e dos e seus Anexos;

9.10 Responsabilizar-se e reparar quaisquer danos diretamente causados ao CONTRATANTE ou a terceiros por culpa ou dolo de seus representantes legais, prepostos ou empregados, em decorrência da relação contratual, não excluindo ou reduzindo a responsabilidade da fiscalização ou o acompanhamento da execução dos serviços pelo CONTRATANTE. O valor do dano, após processo apurativo de responsabilidade, no qual será garantido o contraditório e a ampla defesa, poderá ser descontado do primeiro pagamento subsequente à finalização do processo;

9.11 Propiciar todos os meios e facilidades necessárias à fiscalização pelo CONTRATANTE, cujo representante terá poderes para sustar os serviços, total ou parcialmente, em qualquer tempo, sempre que considerar a medida necessária;

9.12 Quando especificada, manter, durante a execução do Contrato, equipe técnica composta por profissionais devidamente habilitados, treinados e qualificados para fornecimento dos serviços contratados;

9.13 Xxxxxxxx, sempre que solicitado, amostra para realização de Prova de Conceito para fins de comprovação de atendimento das especificações técnicas;

9.14 Acatar, no prazo estabelecido na notificação feita pelo Gestor do Contrato, as instruções, sugestões, observações e decisões que emanem do CONTRATANTE, corrigindo as deficiências apontadas quanto ao cumprimento das cláusulas contratuais, devendo, ainda, observar as normas de segurança estabelecidas pelo CONTRATANTE;

9.15 Manter, durante toda a execução do Contrato, as condições de habilitação e qualificação exigidas na licitação;

9.16 Obedecer a todas as normas, padrões, processos e procedimentos do CONTRATANTE definidos pela Subsecretaria de Tecnologia da Informação;

9.17 Prestar todos os esclarecimentos técnicos e administrativos que lhe forem solicitados pelo CONTRATANTE, relacionados à prestação dos serviços;

8.18 Não divulgar nem permitir a divulgação, sob qualquer hipótese, das informações a que venha a ter acesso em decorrência dos serviços realizados, sob pena de responsabilidade civil e/ou criminal;

9.19 Zelar pelo patrimônio do CONTRATANTE e usar de forma racional os materiais disponíveis para a execução do Contrato;

9.20 Responsabilizar-se pela solicitação de acesso aos funcionários aos sistemas e serviços do CONTRATANTE, necessários à prestação dos serviços, bem como pelos seus respectivos descredenciamentos quando necessários;

9.21 Assumir, plena e exclusivamente, todos os riscos provenientes da execução do objeto contratual, não assumindo o CONTRATANTE, em hipótese alguma, nenhuma responsabilidade subsidiariamente;

9.22 Propiciar a transferência de conhecimento aos servidores do CONTRATANTE durante toda a execução contratual;

9.23 Sempre que houver atualização tecnológica ou metodológica em que os técnicos envolvidos necessitem do novo conhecimento, o CONTRATANTE notificará a CONTRATADA da necessidade de capacitação de sua equipe ou de sua substituição por outra já capacitada;

9.24 Comunicar por escrito qualquer anormalidade, prestando ao CONTRATANTE os esclarecimentos julgados necessários;

9.25 Observar as obrigações elencadas e outras firmadas em Contrato ou existentes em normas internas do CONTRATANTE, caso contrário, ficará sujeita às penalidades e sanções administrativas descritas neste Termo de Referência;

9.26 Refazer os trabalhos impugnados pelo gestor do contrato, ficando por sua conta exclusiva as despesas decorrentes dessas providências.

9.27 Garantir que a execução dos serviços prestados ao CONTRATANTE não sejam interrompidos e não tenham redução de qualidade ou disponibilidade por falta de recursos materiais ou humanos.

9.28 Adotar todas as providências e obrigações estabelecidas na legislação específica de acidentes do trabalho, quando em ocorrência da espécie forem vítimas os seus técnicos e empregados no desempenho dos serviços ou em contato com eles, ainda que verificadas nas dependências da CONTRATANTE;

9.29 Assumir a responsabilidade por todos os encargos previdenciários e obrigações sociais previstos na legislação social trabalhista em vigor, obrigando-se a saldá-las na época própria, vez que os seus empregados não manterão nenhum vínculo empregatício com a CONTRATANTE;

9.30 A inadimplência da CONTRATADA, com referência aos encargos estabelecidos nas condições anteriores, não transfere a responsabilidade por seu pagamento à CONTRATANTE, nem poderá onerar o objeto da licitação, razão pela qual a CONTRATADA renuncia desde já a qualquer vínculo de solidariedade, ativa ou passiva, para com a CONTRATANTE;

9.31 Aceitar, durante a vigência do Contrato, nas mesmas condições contratuais,os acréscimos ou supressão do objeto, até o limite de 25% (vinte e cinco por cento) do valor inicial atualizado, durante a sua vigência ;

9.32 Utilizar as melhores práticas, capacidade técnica, materiais, equipamentos, recursos humanos e supervisão técnica e administrativa, para garantir a qualidade do serviço e o atendimento às especificações contidas no Contrato e seus anexos;

9.33 Responsabilizar-se integralmente pela sua equipe técnica, primando pela qualidade, desempenho, eficiência e produtividade, visando à execução dos trabalhos durante todo o Contrato, dentro dos prazos estipulados, sob pena de ser considerada infração passível de aplicação de penalidades previstas, caso os prazos e condições não sejam cumpridos;

9.34 Cumprir os Níveis de Serviço exigidos e demais condições estabelecidas no Contrato, Edital e seus Anexos;

9.35 Apresentar novas soluções dentro dos prazos e condições estabelecidas pela CONTRATADA, sem prejuízo de aplicação de penalidades previstas, caso sejam detectados erros ou impropriedades na solução apresentada;

9.2. DA CONTRATANTE

9.2.1. Nomear Gestor do Contrato e Fiscais Técnico do contrato para acompanhar e fiscalizar a execução dos contratos;

9.2.2. Receber o objeto fornecido pela CONTRATADA que esteja em conformidade com a proposta aceita, conforme inspeções realizadas;

9.9.3. Efetuar conferência minuciosa dos serviços entregues, aprovando-os se for o caso;

9.2.4. Rejeitar os serviços que não atendam aos requisitos constantes das especificações contidas no Termo de Referência;

9.2.5. Acompanhar e fiscalizar a execução do contrato por meio de servidores designados;

9.2.6. O Gestor do Contrato do CONTRATANTE atestará as notas fiscais para fins de pagamento, comprovada a prestação correta dos serviços, com base na informação prestada pelos Fiscais Técnicos;

9.2.7. Notificar a CONTRATADA, por meio de ofício, e-mail ou sistema de controle de ocorrências, sobre imperfeições, falhas ou irregularidades constatadas na execução do serviço, para que sejam adotadas as medidas corretivas cabíveis;

9.2.8. Comunicar à CONTRATADA todas e quaisquer ocorrências relacionadas com o fornecimento dos serviços contratados;

9.2.9. Definir produtividade ou capacidade mínima de fornecimento das Soluções de Tecnologia da Informação e Comunicação por parte da CONTRATADA, com base em informações de mercado, quando aplicável;

9.2.10. Prestar à CONTRATADA, em tempo hábil, as informações eventualmente necessárias à execução do serviço;

9.2.11. Emitir, por intermédio da solução computacional de apoio à execução dos serviços, as correspondentes Ordens de Serviço (OS), contendo todas as informações necessárias para a prestação do serviço, objeto do presente Termo de Referência;

9.2.12. Acompanhar, controlar e avaliar a prestação de serviço, por intermédio do gestor e fiscal do contrato, especialmente quanto aos aspectos quantitativos e qualitativos, de acordo com os padrões de qualidade definidos;

9.2.13. Permitir, sob supervisão, que os funcionários da empresa CONTRATADA, desde que devidamente identificados e incluídos na relação de técnicos autorizados, tenham acesso às dependências do CONTRATANTE, onde o serviço será prestado, respeitando as normas que disciplinam a segurança da informação e o patrimônio;

9.2.14. Aplicar à CONTRATADA as sanções administrativas regulamentares e contratuais cabíveis;

9.2.15 Liquidar o empenho e efetuar o pagamento à CONTRATADA, dentro dos prazos preestabelecidos em Contrato;

9.2.16. Efetuar o pagamento devido pela execução dos serviços, no prazo estabelecido no presente Termo de Referência, desde que cumpridas todas as formalidades e exigências previstas.

10. CLÁUSULA DÉCIMA - DO ACRÉSCIMO E DA SUPRESSÃO DE SERVIÇOS

10.1. Este contrato poderá ser alterado, com as devidas justificativas, conforme disposto no art. 65 da Lei Federal nº 8.666/93.

10.2. A CONTRATADA ficará obrigada a aceitar, nas mesmas condições contratuais acréscimos ou supressões que se fizerem necessárias no quantitativo do objeto contratado até o limite de 25% do valor inicial atualizado do contrato, conforme disposto no §1º do art. 65, da Lei Federal nº 8.666/93.

11. CLÁUSULA DÉCIMA PRIMEIRA - DAS SANÇÕES CONTRATUAIS E OS CRITÉRIOS DE MENSURAÇÃO E MULTAS

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

11.1.1 Inexecutar total ou parcialmente qualquer das obrigações assumidas em decorrência da contratação;

11.1.2 Ensejar o retardamento da execução do objeto;

11.1.3 Falhar ou fraudar na execução do contrato;

11.1.4 Comportar-se de modo inidôneo;

11.1.5 Cometer fraude fiscal.

11.2 Pela inexecução total ou parcial do objeto deste contrato, a Administração pode aplicar à CONTRATADA as seguintes sanções:

11.2.1 Advertência por escrito, quando do não cumprimento de quaisquer das obrigações contratuais consideradas faltas leves, assim entendidas aquelas que não acarretam prejuízos significativos para o serviço contratado.

11.2.2 Multa de:

11.2.2.1 0,1% (um décimo por cento) até 0,3% (três décimos por cento) ao dia, até o trigésimo dia de atraso, sobre o valor da parte do serviço não realizado;

11.2.2.2 0,1% (um décimo por cento) até 0,7% (sete décimos por cento) sobre o valor da parte do serviço não realizado, por dia subsequente ao trigésimo;

11.2.2.3 0,1% (um décimo por cento) até 10% (dez por cento) sobre o valor da nota de empenho ou do contrato, em caso de inexecução total da obrigação;

11.2.2.4 0,2% a 3,2% por dia sobre o valor mensal do contrato, conforme detalhamento constante das tabelas abaixo; e

11.2.2.5 0,07% (sete centésimos por cento) do valor do contrato por dia de atraso na apresentação da garantia (seja para reforço ou por ocasião de prorrogação), observado o máximo de 2% (dois por cento). O atraso superior a 25 (vinte e cinco) dias autorizará a Administração CONTRATANTE a promover a rescisão do contrato.

11.2.2.6 As penalidades de multa decorrentes de fatos diversos serão consideradas independentes entre si.

16.2.3 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é 2 (dois) anos.

11.2.4 Sanção de impedimento de licitar e contratar com órgãos e entidades do Estado de Goiás, com o consequente descredenciamento no CADFOR pelo prazo de até 5 (cinco) anos.

11.2.5 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 o CONTRATANTE pelos prejuízos causados.

11.3 As sanções previstas nos subitens 11.2.1, 11.2.3, 11.2.4 e 11.2.5 poderão ser aplicadas à CONTRATADA juntamente com as de multa, descontando-a dos pagamentos a serem efetuados

11.4 Para efeito de aplicação de multas, às infrações são atribuídos graus, de acordo com as tabelas abaixo:

GRAU	CORRESPONDÊNCIA
1	0,2% ao dia sobre o valor mensal do contrato
2	0,4% ao dia sobre o valor mensal do contrato

3	0,8% ao dia sobre o valor mensal do contrato
4	1,6% ao dia sobre o valor mensal do contrato
5	3,2% ao dia sobre o valor mensal do contrato

INFRAÇÃO
ITEM	DESCRIÇÃO	GRAU
1	Permitir situação que crie a possibilidade de causar dano físico, lesão corporal ou consequências letais, por ocorrência.	05
2	Suspender ou interromper, salvo motivo de força maior ou caso fortuito, os serviços contratuais por dia e por unidade de atendimento.	04
3	Manter prestador de serviço sem qualificação para executar os serviços contratados, por empregado e por dia.	03
4	Recusar-se a executar serviço determinado pela fiscalização, por serviço e por dia.	02
Para os itens a seguir, deixar de:
5	Cumprir determinação formal ou instrução complementar do órgão fiscalizador, por ocorrência.	02
6	Substituir empregado que se conduza de modo inconveniente ou não atenda às necessidades do serviço, por funcionário e por dia.	01
7	Cumprir quaisquer dos itens do Edital e seus Anexos não previstos nesta tabela de multas, após reincidência formalmente notificada pelo órgão fiscalizador, por item e por ocorrência.	03
8	Indicar e manter durante a execução do contrato os prepostos previstos no edital/contrato.	01

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

16.5.1 Tenham sofrido condenação definitiva por praticar, por meio dolosos, fraude fiscal no recolhimento de quaisquer tributos;

16.5.2 Tenham praticado atos ilícitos visando a frustrar os objetivos da licitação;

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

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

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

16.8 As penalidades serão obrigatoriamente registradas no CADFOR.

12. CLÁUSULA DÉCIMA SEGUNDA - DA RESCISÃO

12.1. O presente contrato poderá ser rescindido, a qualquer tempo, nas seguintes condições:

12.1.1. Por determinação unilateral e por escrito da Administração conforme disposto no artigo 79, da Lei nº 8.666/93;

12.1.2. Amigavelmente, por acordo entre as partes, reduzidas a termo no bojo dos autos, desde que haja conveniência para a Administração;

12.1.3. Judicial, nos termos da legislação; e

12.1.4. Por inexecução total ou parcial do contrato, conforme o disposto, no que couber, nos artigos 77 e 78 da Lei Federal nº 8.666/93.

13. CLÁUSULA DÉCIMA TERCEIRA - DA VIGÊNCIA

13.1 O período de vigência do contrato será de 12 (vinte e quatro) meses a partir da data de sua assinatura, eficácia a partir da publicação no Diário Oficial do Estado de Goiás,

13.2. O Contrato poderá ser prorrogado por igual e sucessivo período mediante termo aditivo, nos termos da Lei nº 8.666/93.

13.3 A CONTRATADA deverá sujeitar-se aos acréscimos e supressões contratuais estabelecidos na forma do Art. 65 da Lei n. 8.666/93.

14. CLÁUSULA DÉCIMA QUARTA - DA VIGÊNCIA

14.1. O prazo de vigência do contrato será de 12 (doze) meses, contados a partir de sua assinatura, a eficácia a partir da publicação no Diário Oficial do Estado, e poderá ser prorrogado por iguais e sucessivos períodos, limitados a 60 (sessenta meses).

15. CLÁUSULA DÉCIMA QUINTA - DA LEGISLAÇÃO APLICÁVEL

14.1. A execução deste contrato, bem como os casos nele omissos, regular-se-ão pelas cláusulas contratuais e pelos preceitos de direito público, aplicando-lhes, supletivamente, os princípios da Teoria Geral dos Contratos e as disposições de direito privado, na forma dos artigos 54/55 da Lei Federal nº 8.666/93, e Lei Estadual n.º 17.928, de 27 de dezembro de 2012.

1) Qualquer disputa ou controvérsia relativa à interpretação ou execução deste ajuste, ou de qualquer forma oriunda ou associada a ele, no tocante a direitos patrimoniais disponíveis, e que não seja dirimida amigavelmente entre as partes (precedida da realização de tentativa de conciliação ou mediação), deverá ser resolvida de forma definitiva por arbitragem, nos termos das normas de regência da CÂMARA DE CONCILIAÇÃO, MEDIAÇÃO E ARBITRAGEM DA ADMINISTRAÇÃO ESTADUAL (CCMA).

2) A CÂMARA DE CONCILIAÇÃO, MEDIAÇÃO E ARBITRAGEM DA ADMINISTRAÇÃO ESTADUAL (CCMA) será composta por Procuradores do Estado, Procuradores da Assembleia Legislativa e por advogados regularmente inscritos na OAB/GO, podendo funcionar em Comissões compostas sempre em número ímpar maior ou igual a 3 (três) integrantes (árbitros), cujo sorteio se dará na forma do art. 14 da Lei Complementar Estadual nº 114, de 24 de julho de 2018, sem prejuízo da aplicação das normas de seu Regimento Interno, onde cabível.

3) A sede da arbitragem e da prolação da sentença será preferencialmente a cidade de Goiânia.

4) O idioma da Arbitragem será a Língua Portuguesa.

5) A arbitragem será exclusivamente de direito, aplicando-se as normas integrantes do ordenamento jurídico

* * * ANEXO AO CONTRATO Nº 39/2020-SEDI * * *

ao mérito do litígio.

6) Aplicar-se-á ao processo arbitral o rito previsto nas normas de regência (incluso o seu Regimento Interno) da CÂMARA DE CONCILIAÇÃO, MEDIAÇÃO E ARBITRAGEM DA ADMINISTRAÇÃO ESTADUAL (CCMA), na Lei nº 9.307, de 23 de setembro de 1996, na Lei nº 13.140, de 26 de junho de 2015, na Lei Complementar Estadual nº 144, de 24 de julho de 2018 e na Lei Estadual nº 13.800, de 18 de janeiro de 2001, constituindo a sentença título executivo vinculante entre as partes.

7) A sentença arbitral será de acesso público, a ser disponibilizado no sítio eletrônico oficial da Procuradoria-Geral do Estado, ressalvadas as hipóteses de sigilo previstas em lei.

8) As partes elegem o Foro da Comarca de Goiânia para quaisquer medidas judiciais necessárias, incluindo a execução da sentença arbitral. A eventual propositura de medidas judiciais pelas partes deverá ser imediatamente comunicada à CÂMARA DE CONCILIAÇÃO, MEDIAÇÃO E ARBITRAGEM DA ADMINISTRAÇÃO ESTADUAL (CCMA), e não implica e nem deverá ser interpretada como renúncia à arbitragem, nem afetará a existência, validade e eficácia da presente cláusula arbitral.

GOIANIA, 23 de setembro de 2020.

Documento assinado eletronicamente por XXXXXXX XX XXXX XXXXXXX, Usuário Externo, em 28/09/2020, às 09:01, conforme art. 2º, § 2º, III, "b", da Lei 17.039/2010 e art. 3ºB, I, do Decreto nº 8.808/2016.

Documento assinado eletronicamente por XXXXXX XXXXX XXXXXXX, Secretário (a) de Estado, em 30/09/2020, às 16:54, conforme art. 2º, § 2º, III, "b", da Lei 17.039/2010 e art. 3ºB, I, do Decreto nº 8.808/2016.

Documento assinado eletronicamente por XXXXXX XXXXXX XX XXXXXXXX, Procurador (a) do Estado, em 06/10/2020, às 11:13, conforme art. 2º, § 2º, III, "b", da Lei 17.039/2010 e art. 3ºB, I, do Decreto nº 8.808/2016.

A autenticidade do documento pode ser conferida no site xxxx://xxx.xx.xxx.xx/xxx/xxxxxxxxxxx_xxxxxxx.xxx? acao=documento_conferir&id_orgao_acesso_externo=1 informando o código verificador 000015491754 e o código CRC DB550735.

GERÊNCIA DE COMPRAS GOVERNAMENTAIS

Rua 82, nº 400, Palácio Xxxxx Xxxxxxxx Xxxxxxxx, 1º andar, ala oeste, Xxxxx Xxxxxxx, XXX 00.000-000, Xxxxxxx - XX.

Referência: Processo nº 202014304000995 SEI 000015491754

Document Metadata

Table of Contents

ESTADO DE GOIÁS

Document Metadata