DIRETORIA DE ADMINISTRAÇÃO - DAD COORDENAÇÃO GERAL DE ADMINISTRAÇÃO E FINANÇAS CGADM COORDENAÇÃO DE INFRA-ESTRUTURA COINF SERVIÇO DE LICITAÇÃO SELIC

DIRETORIA DE ADMINISTRAÇÃO - DAD COORDENAÇÃO GERAL DE ADMINISTRAÇÃO E FINANÇAS CGADM COORDENAÇÃO DE INFRA-ESTRUTURA COINF SERVIÇO DE LICITAÇÃO SELIC Brasília, 02 de dezembro de 2008. Aos interessados, Ref.: Processo n. º 077117/2008-5 Ass.: Contratação de empresa especializada para a aquisição da Solução de Segurança de Rede e Informação no ambiente computacional do CNPq, incluindo a configuração, testes, implantação, suporte e assistência técnica durante o período de garantia dos produtos componentes da Solução. PREGRÃO ELETRÔNICO N 22/2008. Informamos a V.Sª, que a Pregoeira, designada pela Ordem Interna n 002/2008, tomou conhecimento recurso interposto pela empresa VERTAX REDES E TELECOMUNICAÇÕES LTDA e as contra-razões apresentadas pela empresa NCT INFORMÁTICA LTDA. Transcrevemos abaixo o teor do recurso e das cotra-razões, bem como a decisão do Pregoeiro: A - DOS FATOS E FUNDAMENTOS ENSEJADORES DO RECURSO Argumentos da interessada: RECURSO em face da decisão que declarou a empresa NCT INFORMÁTICA LTDA como vencedora do certame em epígrafe, e o faz pelas razões de fato e de direito a seguir declinadas, para requerer, nos termos 2 do artigo 109, da Lei de Licitações, o recebimento do presente recurso no efeito suspensivo, e o acolhimento de suas razões, com a conseqüente convocação das demais licitantes na sua ordem de classificação e invalidação dos atos subseqüentes à decisão ora vergastada. I DOS FATOS 1

A ora Recorrente participou do certame epigrafado, e acompanhou o desenrolar de todo o procedimento. Após declaração da empresa NCT INFORMÁTICA, como vencedora, esta apresentou os documentos que comprovariam sua habilitação e qualificação, inclusive técnica, para ser contratada e prover o objeto almejado. Ocorre que os documentos apresentados não se prestaram para comprovar o atendimento aos itens exigidos pelo Edital. Ao contrário, em muitos casos fizeram prova justamente em contrário, demonstrando que a solução ofertada desatende diversas exigências. Mas, antes mesmo de adentrar tal mérito, e apontar os itens claramente desatendidos, cumpre revelar item de alta relevância, qual seja, a apresentação de um mesmo documento em versões diferentes. Por exemplo, ao cuidar do Anti-vírus e Anti-Spam, a suposta vencedora apresentou um documento que comprovaria o atendimento a todas as exigências, inclusive a de n 2.10, que assim exigiu: Deverá efetuar a identificação de usuários inválidos e prevenção contra Ataques de Varredura de Diretórios (DHAP) através de integração com servidores LDAP, OpenLDAP e Microsoft Active Directory O documento apresentado pela NCT INFORMÁTICA LTDA, mais especificamente em sua página 187, não fez a prova exigida, o que motivou o CNPq a manifestar-se do seguinte modo: A funcionalidade descrita no manual é referenciada a LDAP profile, ou seja, políticas baseadas em grupos e/ou usuários; não é uma funcionalidade de prevenção de varredura, uma vez que, para que a mensagem chegue a este estágio, ela deve obrigatoriamente estar dentro do appliance. Para funcionalidade de DHAP espera-se que o sistema identifique no diálogo SMTP os usuários inválidos. Diante disso, a NCT INFORMÁTICA LTDA afirmou que a página 187 do documento comprovaria as funcionalidades demandadas, e o fez assim: Na página 187 do mesmo documento (Fortimail V3.0 MR4 Administration Guide.pdf) há uma explicação detalhada do recurso de verificação de endereços de destinat[arios (Verify Recipient Address) que mostra o seguinte: Select a method of confirming that the recipient To: address in the message header corresponds to an email user account that actually exists on the protected email server. If the recipient address is invalid, the FortiMail unit will not quarantine email messages for the non-existent account, thereby conserving quarantine hard disk space e ainda Use LDAP Server: Query an LDAP server to verify that the recipient address is an email user account that actually exists. Also select the LDAP profile that will be used to query the LDAP server. Logo, o LDAP profile aqui utilizado, refere-se ao diretório LDAP (Open LDAP, MS AD, etc) no qual será feita a pesquisa dos endereços válidos e não ao que foi erroneamente informado de políticas baseadas em grupos e/ou usuários. 2

Junto a esta explicação, a NCT INFORMÁTICA LTDA apresentou nova versão do documento já mencionado. Na nova versão, a página 187 é diferente da página 187 da primeira versão. Confira-se o conteúdo das referidas páginas 187 dos dois documentos: PRIMEIRA VERSÃO Action The action taken when this rule is matched. For more information about actions, see Creating and editing access control rules on page 187. Modify Select edit to modify the rule. Select delete to delete the rule. Select move to change the position of the rule in the list. The FortiMail unit matches the rules in sequence, from the top of the list down. Create New Create a new email access rule. See Creating and editing access control rules on page 187. Creating and editing access control rules Go to Mail Settings > Access > Receive and select Create New to add a new access control rule. To edit an existing rule, select the Edit icon of the rule you want to modify. No pattern can be left blank in an access control rule. To have the FortiMail unit ignore a pattern, enter an asterisk (*) in the pattern field. For example, if you enter an asterisk (*) in the Recipient Pattern field and do not select Regular Expression, the asterisk matches all recipient addresses. This eliminates the recipient pattern as an item used to determine if the rule matches an email message. When using wildcards, the asterisk (*) matches all patterns in the Sender Pattern, Recipient Pattern, and Reverse DNS Pattern. If Regular Expression is enabled, the dotstar (.*) character sequence matches all patterns in these fields. The IP address 0.0.0.0/0 matches all addresses in the Sender IP/Netmask field. Caution: Exercise caution with access control rules. Reject, discard, and accept actions can have serious consequences if rules do not funct Informática Ltdaion as anticipated. The behavior of access control rules should be checked in a test environment before use. SEGUNDA VERSÃO Verify Recipient Address Select a method of confirming that the recipient To: address in the message header corresponds to an email user account that actually exists on the protected email server. If the recipient address is invalid, the FortiMail unit will not quarantine email messages for the non-existent account, thereby conserving quarantine hard disk space. Disable: Do not verify that the recipient address is an email user account that actually 3

exists. Use SMTP Server: Query the SMTP server to verify that the recipient address is an email user account that actually exists. Use LDAP Server: Query an LDAP server to verify that the recipient address is an email user account that actually exists. Also select the LDAP profile that will be used to query the LDAP server. For more information on configuring LDAP profiles, see LDAP Profile on page 320. This option can cause a performance impact that may be noticeable during peak traffic times. For a lesser performance impact, you can alternatively periodically automatically remove quarantined email messages for invalid email user accounts, rather than actively preventing them during each email message. For more information, see Automatic Removal of Invalid Quarantine Accounts on page 189. Note: Spam often contains invalid recipient addresses. If you have enabled spam quarantining, but have not prevented or scheduled the periodic removal of quarantined email messages for invalid email accounts, the FortiMail hard disk may be rapidly consumed during peak traffic times, resulting in refused SMTP connections when the hard disk becomes full. To prevent this, enable either this option or the periodic removal of invalid quarantine accounts. Note: This option does not operate upon the recipient address that appears in the envelope of the SMTP session, which is governed by access control rules. For more information on access control rules, see Access on page 198. Transparent Mode Options This server is on (transparent mode only)select the network interface (port) to which the protected SMTP server is connected. Note: Selecting the wrong network interface will result in the FortiMail sending email traffic to the wrong network interface. Ora, os documentos são inegavelmente diferentes, e no momento de responder à objeção do CNPq a empresa declarada vencedora não poderia ter juntado novo documento. Deveria ter se atido aos documentos já antes apresentados, demonstrando que a análise do CNPq fora feita de modo equivocado. Contudo, em lugar de comprovar que a análise do documento feita pelo CNPq estivesse errada, a NCT INFORMÁTICA LTDA simplesmente juntou documento novo, e apontou neste documento novo os locais onde se comprovaria o atendimento das funcionalidades exigidas. Este grave fato já bastaria para a desclassificação da suposta vencedora. Mas muitos outros motivos há para tanto, nomeadamente no que se refere ao atendimento das exigências, mesmo após a apresentação irregular do novo documento. Diversos requisitos de ordem técnica não são atendidos pela solução ofertada pela empresa NCT INFORMÁTICA LTDA, consoante se verá. SUBITEM 5.2, DO ITEM 5 VIRTUAL PRIVATE NETWORK (VPN): 4

Neste ponto em particular, o Edital exigiu: Deverá possuir alta disponibilidade (HA) transparente do tipo: ativo/ativo, ativo/passivo, ou seja, sem perda de conexões em caso de falha de um dos nós. Ao promover a primeira análise, o CNPq atestou que a solução não atende à exigência, e assim o fez: NÃO ATENDE. Segundo informações constantes no doc. FortiGate v3.0 MR5 HÁ Overview.pdf pág. 52, as sessões nos túneis VPN SSL que estiverem rodando antes do failover serão paradas e terão que ser reiniciadas. A suposta vencedora rebateu o veredicto do CNPq, e assim afirmou: As páginas 52 e 53 do mesmo documento citado pelo CNPq (Fortigate v3.0 MR5 HA Overview.pdf), na seção IPSec VPN na SSL Sessions, detalha o funcionamento de failover para VPN IPSec e VPN SSL. Na VPN IPSec é suportado o failover de todas as sessões e na VPN SSL, apesar de não ocorrer o failover das sessões é feito o failover de cookie o que fará com que o cliente restabeleça a sessão de VPN SSL sem necessidade de nova autenticação. É importante ressaltar que o comportamento será o mesmo para ambos os modos de operação do cluster ativo/ativo e ativo/passivo. Diante de tais argumentos, o CNPq houve por bem entender que os requisitos estariam atendidos, conforme seguinte decisão: Documentação e esclarecimentos apresentados atendem às especificações, considerando que o modo de operação VPN IPSec suporta Session failover sem perda de conexões, e o modo VPN SSL suporta o recurso cookie failover para restabelecimento das sessões, não havendo perda de conexão do usuário (cliente) através da manutenção de sua autenticação. A especificação discriminada neste item não determina para qual modo de operação, em específico, deverá haver alta disponibilidade, sendo portanto aceitos, os recursos apresentados. Ocorre que tal avaliação está completamente equivocada. Em primeiro lugar, não há alta disponibilidade para os túneis SSL. Embora esses túneis não tenham que ser novamente autenticados, através da utilização de cookies que por suas características nativas se tratam de recursos questionáveis, em caso de queda do appliance, a conexão será perdida, contrariando terminantemente a exigência clara...sem perda de conexões em caso de falha de um dos nós. O trecho a seguir, transcrito da página 52 do documento FortiGate v3.0 MR5 HA Overview.pdf, indicado pela empresa NCT INFORMÁTICA LTDA como comprovação de atendimento dos requisitos, acaba ratificando a incapacidade da solução ofertada em atender ao quesito. Ressalta-se ainda o alerta feito pelo próprio fabricante: as transferências de arquivo em andamento (até a perda da conexão), por exemplo, deverão ser reiniciadas : Session failover is not supported for SSL VPN tunnels. However, cookie failover is supported for the communication between the SSL VPN client and the FortiGate unit. This 5

means that after the failover you can re-establish the SSL VPN session between the SSL VPN client and the FortiGate unit without having to authenticate again. However, all sessions inside the SSL VPN tunnel that were running before the failover are stopped and have to be restarted. For example, file transfers that were in progress would have to be restarted. As well, any communication sessions with resources behind the FortiGate unit would have to be restarted. Resta evidente que a solução não atende os requisitos exigidos. Ademais, a solução ofertada pela empresa NCT INFORMÁTICA LTDA compreende uma solução conjunta, onde Firewall e VPN co-existem num mesmo equipamento. Desse modo, além de não atender o subitem 5.2, a oferta contraria a exigência do subitem 1.5, do item 1 - Firewall, transcrito a seguir: Deverá possuir alta disponibilidade (HA), trabalhando no esquema de redundância do tipo ativo-ativo com divisão de carga, e todas as licenças de software habilitadas para tal, sem perda de conexões Novamente, a exigência é de extrema clareza, e dá conta que... todas as licenças de softwares habilitadas para tal (ou seja, incluindo VPN), sem perda de conexões e incorre na ratificação do não cumprimento de quesito técnico determinado pelo próprio CNPQ, de modo inquestionável. O acatamento, pelo CNPq, dos argumentos da empresa NCT INFORMÁTICA LTDA causa estranheza, como se verá. Nesta análise final, o CNPq asseverou que...e o modo VPN SSL suporta o recurso cookie failover para restabelecimento das sessões.... Portanto, conclui-se que, a princípio, a argumentação confirma a sua primeira análise quando, acertadamente, sentenciou que a solução não atende os requisitos, posto que...as sessões nos túneis VPN SSL que estiverem rodando antes do failover serão paradas e terão que ser reiniciadas. Contudo, prosseguindo na análise, o CNPq entendeu que ocorreria o restabelecimento das sessões...não havendo perda de conexão do usuário (cliente) através da manutenção de sua autenticação. O entendimento é, de todo, equivocado, e por dois motivos: (1) em óbvia dedução, se a sessão terá que ser restabelecida é porque ela (a conexão) foi perdida, logo, a solução não atende o requisitado, a saber, que não haja perda da conexão; (2) a manutenção de sua autenticação significa que, após a perda a conexão, quando restabelecida a sessão, o usuário não necessitará se autenticar novamente, mas indica a perda da conexão, e a exigência é clara, e não admite a perda de conexão. Não se cuida de permitir a perda de conexão, desde não fosse necessária nova autenticação. Se assim o fosse, o Edital teria dito sem necessidade de nova autenticação, e não sem a perda de conexão. Não se pode tentar interpretar o evidente. A exigência é claríssima, e não é menos claro que não foi atendida pela suposta vencedora. Mais adiante, a análise do CNPq incorre em nova inconsistência, pois que fechou os 6

olhos para uma exigência claríssima do Ato Convocatório, contida no subitem 5.2. O CNPq alegou uma inexistente lacuna na exigência, ao assim verberar: A especificação discriminada neste item não determina para qual modo de operação, em específico, deverá haver alta disponibilidade, sendo portanto aceitos, os recursos apresentados. Contudo, e diametralmente oposto ao que asseverado pelo CNPq, o Edital é inequívoco ao exigir que deverá possuir alta disponibilidade (HA) transparente do tipo: ativo/ativo, ativo/passivo.... O recurso deve ser aplicado de modo transparente, válido para qualquer modalidade de VPN exigida e configurada em uso, ou seja, IPSec ou SSL. Ora, diante de tal exigência expressa, como seria possível afirmar que a especificação não determina para qual modo de operação deverá haver alta disponibilidade? Seria negar o óbvio! Ademais, seria absolutamente inaceitável que tantas e tamanhas exigências, tão específicas e explícitas para SSL, ao tivessem qualquer propósito. Não estariam tão minuciosamente explicitadas caso não fossem fundamentais para atendimento às necessidades do CNPq. Fundamental o suficiente para que valesse a exigência de alta disponibilidade (HA) também para o SSL. A seguir, transcrição dos subitens exigidos para VPN SSL. 5.5. Deverá permitir o acesso de, no mínimo, 200 (duzentos) usuários de VPN SSL simultâneos 5.8. Deverá possuir suporte a VPNs IPSec site-to-site, VPNs IPSec client-to-site e VPN SSL 5.9. Realizar criptografia de VPN SSL de, no mínimo, 128 bits 5.10. Possibilitar o acesso via VPN SSL à aplicações cliente-servidor e Web 5.13 Deverá possibilitar a utilização de VPN SSL sobre os sistemas operacionais Windows e Linux, e navegadores Internet Explorer (versão 6.0 e superior) e Mozila Firefox (versão 2.0 e superior) 5.14. Deverá possuir capacidade de realizar VPNs SSL por meio de protocolo HTTPS, utilizando certificados digitais 5.15. A VPN SSL deverá possibilitar o acesso a toda infra-estrutura de rede do CNPq de acordo com a política de segurança, através de um plug-in ActiveX e/ou Java 5.16. Deverá permitir o acesso, via VPN SSL, a páginas de URLs dinâmicas que contenham recursos em JavaScript ou Flash 5.18 Deverá permitir execução de aplicações cliente servidor, via VPN SSL, em portas definidas e customizadas pelo administrador, incluindo serviços de VoIP Sendo ainda mais contundente, apenas um único subitem trata exclusivamente de VPN IPSec, transcrito a seguir: 7

5.4. Deverá suportar, no mínimo, 1.000 (um mil) túneis VPNs IPSec site-to-site ou clientto-site, simultâneos Resta claro e incontestável, portanto, que a alta disponibilidade (HA) aplica-se ao SSL. Diante disso, impõe-se a desclassificação da empresa NCT INFORMÁTICA LTDA, por desatendimento do item 5.2 do Edital. SUBITEM 5.11, DO ITEM 5 VIRTUAL PRIVATE NETWORK (VPN) O Edital, em seu subitem 5.11, exigiu de forma categórica que a VPN: Deverá possibilitar o acesso remoto ao serviço de emulação de terminal (VT100, SSH, Telnet) e Terminal Services. Ao promover a primeira análise, o CNPQ entendeu que não restou comprovado o atendimento de tal exigência, afirmando: Não foi encontrada especificação de emulação de terminal VT100 neste documento/página - Fortigate V3.0 MR7 Administration Guide.pdf Debatendo-se em face de tal diagnóstico, a empresa afirmou que: Em relação ao item acima, ressaltamos que os serviços entre parêntesis, neste caso VT100, SSh e Telnet, são apontados como exemplos, sendo que o item a ser atendido é a possibilitar o acesso remoto via VPN ao serviço de emulação de terminal e serviço de terminal services. Como informamos no documento apresentado, atendemos a este item através do documento Fortigate V3.0 MR7 Administreation Guide.pdf em sua página 399, com o serviços Telnet e SSH para emulação de terminal e serviço RDP (Remote Desktop Protocol) para Terminal Services. Informamos também que, VT100 não é um emulador de acesso terminal, como também são xterm, ANSI, VT220 dtterm e outros. O usuário remoto, uma vez fazendo sua conexão via Telnet (TCP porta 23) ou SSH (TCP porta 22) irá utilizar VT100, xterm ou qualquer outro padrão suportado pelo servidor onde foi feita a conexão para acesso via terminal. Ocorre que em nenhum momento, em qualquer documento oficial publicado durante o processo licitatório, há qualquer consideração de parte do CNPq que possa estribar a inovadora interpretação da empresa NCT INFORMÁTICA LTDA. Jamais se disse que os itens entre parênteses consubstanciariam meros exemplos, e que o objetivo seria possibilitar o acesso remoto via VPN ao serviço de emulação de terminal e serviço de terminal services. Ademais, ainda que pudesse prosperar tal entendimento, resta evidente que todos aqueles itens constantes do exemplo deveriam ser atendidos, e ainda outros. O exemplo é sempre o mínimo necessário. Admita-se uma comparação, para melhor compreensão. Se o objeto da licitação fossem canos, e na descrição de suas aplicações o Edital dissesse: deve suportar líquidos (água, álcool, gasolina, etc.). Os termos entre parênteses seriam exemplos, pois o cano deveria suportar os trânsito de diversas espécies de líquidos. O proponente até poderia discutir, 8

visto o rol exemplificativo, se seria indispensável que suportasse líquidos gasosos (refrigerantes, etc.). Mas jamais poderia discutir a exigência de suportar álcool, por exemplo, pois expressamente contido na exigência. Ou seja, ainda que pudesse ser considerado como exemplo qualquer dos itens contidos no Edital, o exemplo é sempre o mínimo exigível, sem impedimento de exigências suplementares. Daí o conceito de rol exaustivo e rol exemplificativo: naquele, os elementos estão todos listados; neste, apenas alguns exemplos, podendo adicionar-se outros, mas jamais desconsiderar os já contidos. A prevalecer o entendimento da empresa NCT INFORMÁTICA LTDA, diversas outras exigências do Edital passariam a ser meros exemplos. O subitem 1.15, do item 1 Firewall, transcrito a seguir, presta-se perfeitamente à analogia: 1.15. Deverá possuir métodos de autenticação de usuários para qualquer aplicação que se execute sob os protocolos TCP (HTTP, HTTPS, FTP e Telnet). Poder-se-ia entender que HTTP, HTTPS, FTP e Telnet, que são protocolos TCP, seriam meros exemplos? Os licitantes poderiam optar entre atender apenas alguns desses protocolos? Evidente que não. Todas as exigências, inclusive entre parênteses, devem ser atendidas, sob pena de desclassificação da proponente. Segundo normas internacionais, regulamentadas e citadas pelo IEEE em RFC s (ex. 1290 e 1402), o VT-100 é utilizado na emulação de terminais, assim como o xterm, citado pela empresa NCT INFORMÁTICA LTDA. Por isso, deve estar sempre explícito que o VT100 é suportado pela aplicação que o utilizará, uma vez que problemas de compatibilidade poderão impossibilitar o serviço desejado. Trata-se, portanto, de um emulador não suportado pela solução ofertada e não comprovado pela empresa NCT INFORMÁTICA LTDA, levando à sua desclassificação do certame, o que desde já se requer. Como se observou, a suposta vencedora deixou de atender a requisitos expressos contidos no Edital, e mesmo assim o CNPq entendeu que poderia superar tais vícios. Mas não pode, pois o Edital, uma vez lançado e não impugnado, vincula as partes, inclusive a própria Administração, que dele não se pode desviar. II - DO DIREITO Dispõe o artigo 41 da Lei 8.666/93, que a Administração não pode contrariar nenhum dos termos do Edital, in verbis: Art. 41 A Administração não pode descumprir as normas e condições do edital, ao qual se acha estritamente vinculada. Nos estritos termos da Lei das Licitações, a propostas da empresa declarada vencedora deveria ter sido desconsiderada tão logo o Pregoeiro tivesse recebido e analisado os documentos que não se prestaram a comprovar a adequação da solução apresentada: 9

Art. 48. Serão desclassificadas: I - as propostas que não atendam às exigências do ato convocatório da licitação; E nem se diga que as exigências se mostrariam exageradas, por dúplice motivo: a uma, porque a exigência encontra espeque legal e fático, eis que estreitamente relacionada com as necessidades do ente licitante; a duas, porque a oportunidade de discussão acerca de tal exigência já ficou ultrapassada. Faz-se voz corrente a defesa da maior participação possível nos certames públicos, mas tal movimento encontra intransponível obstáculo em outros e mais relevantes princípios, sobretudo se guardado o verdadeiro intuito das licitações: contratar o melhor, pelo menor preço possível. E fica evidenciado que em nada beneficia a Administração a contratação de objeto que não reúna os requisitos mínimos estampados no Ato Convocatório. Lecionou ADILSON DALARI, citado em decisão do egrégio STJ (vide REsp 17232/SP), que "o exame do disposto no art. 37, XXI, da Constituição Federal, em sua parte final, referente a exigências de qualificação técnica e econômica indispensáveis à garantia do cumprimento das obrigações revela que o propósito aí objetivado é oferecer iguais oportunidades de contratação com o Poder Público, não a todo e qualquer interessado, indiscriminadamente, mas, sim, apenas a quem possa evidenciar que efetivamente dispõe de condições para executar aquilo a que se propõe". As exigências técnicas desatendidas pela suposta vencedora foram acatadas por todos os licitantes, eis que nenhum deles ousou impugnar o Edital no particular. É verdade que a todo cidadão, e em especial àquelas pessoas que pretendam contratar com a Administração Pública, é dado impugnar o Ato Convocatório, mas desde que o faça dentro dos prazos legais. E a suposta vencedora não impugnou as exigências mencionadas, restando preclusa tal oportunidade. Em face disso, a suposta vencedora, como as demais participantes, aceitou as exigências editalícias, que se consolidaram como lei entre as partes licitantes (Administração e proponentes). E do mesmo modo, a Administração não poderia, ainda que sob o mais nobre e relevante fundamento, relevar qualquer exigência constante do Edital, nomeadamente aquelas que visam a funcionalidade do objeto licitado. Assim discorreu o eminente Professor Marçal Justen Filho, autoridade no assunto: Se, na oportunidade da edição do ato convocatório, a Administração reputou relevante certa exigência, não pode voltar atrás posteriormente. Não se admite que, na ocasião do julgamento, seja alterada a natureza da exigência (e, portanto, do vício). Não se pode ignorar uma exigência que fora veiculada como referida ao interesse público. (...) Era do conhecimento de todos que a exigência deveria ser cumprida. Quem não o fez, deverá arcar com a conseqüência de sua omissão. Irrefutável que houve desatendimento ao Edital, e que este desatendimento acarreta a desclassificação daqueles que, como a suposta vencedora, não cumpriram o estabelecido no Edital. Nada pode socorrer o ato vergastado, eis que violador de regra editalícia. Bem adverte o 10

já citado Professor Marçal Justen Filho, ao cuidar dos critérios de julgamento da habilitação: 12) Critérios de Julgamento de Habilitação O exame dos documentos da fase de habilitação deve ser minucioso e detalhado. Não se admite exame meramente formal, que se satisfaça com a constatação de que os documentos referidos no edital foram apresentados. A comissão deverá verificar a regularidade formal dos documentos, investigando inclusive sua autenticidade. O próprio conteúdo do documento deve ser verificado. As demonstrações financeiras terão de ser analisadas para comprovar se foram elaboradas segundo os princípios contábeis geralmente aceitos e se comprovam idoneidade financeira. As declarações e documentos sobre capacitação técnica devem ser investigados em profundidade. Em que pese isso, o CNPq não investigou de modo minucioso a documentação apresentada, tendo inclusive permitido a apresentação de versões diversas de um mesmo documento. E mais. Quando verificou o desatendimento a exigências do Edital, sucumbiu a falaciosas argumentações, que nada fizeram para infirmar o diagnóstico inicial de inadequação da solução proposta. III DOS PEDIDOS Em face do brevemente exposto, a Recorrente vem requer se digne Vossa Excelência de receber o presente recurso no efeito suspensivo, nos estritos termos do 2 do artigo 109, da Lei de Licitações, e de reconsiderar a decisão que declarou a empresa NCT INFORMÁTICA LTDA como vencedora do presente Pregão, desclassificando-a em razão de sua solução não atender aos já apontados requisitos do Edital. No remoto caso de desprovimento dos pedidos acima, requer, nos termos do 4, do artigo 109 da Lei 8.666/93, alçar o presente recurso devidamente informado, à autoridade superior, para que dele conheça e o proveja. 11

B - DOS FATOS E DO DIREITO ENSEJADORES DA CONTRA-RAZÕES AO RECURSO INTERPOSTO Argumentos da interessada:... Contra-Razões Em face do Recurso Administrativo interposto por VERTAX REDES E COMUNICAÇÕES LTDA., o que faz com base nas razões de fato e de direito a seguir expostas. 1. SÍNTESE 1. Trata-se de pregão eletrônico, instituído pelo CNPq, que teve como vencedora a recorrida NCT Informática. Diante do resultado da licitação, a recorrente Vertax apresentou sua inconformidade, pautando suas razões de recurso nos seguintes argumentos principais: a. Suposta impossibilidade de comprovação de atendimento a requisitos técnicos do edital de licitação pela documentação apresentada junto com a proposta comercial da recorrida, o que a teria levado a apresentar nova documentação, inovando de forma impossível no procedimento, em desrespeito à lei, o que conduziria à desclassificação de sua proposta; b. Descumprimento ao subitem 5.2 do termo de referência do edital (especificação da VPN): a documentação apresentada não teria o condão de comprovar haja alta disponibilidade para os túneis SSL, além de descumprir a exigência de que não haja perda de conexões na ferramenta; c. Descumprimento ao subitem 5.11 do termo de referência do edital (especificação da VPN): o produto apresentado pela NCT supostamente não atenderia ao emulador VT100. 2. Diante dessas constatações, fazendo remissão à obrigatoriedade dos itens editalícios, pede a desclassificação da proposta da NCT, com a convocação da segunda colocada para negociação. 3. Mas os argumentos não se sustentam. Para comprovar isso, as razões a seguir serão divididas em duas partes. Na primeira, sob a ótica da Lei de Licitações e Contratos Administrativos, será visto que a NCT, em nenhum momento, inovou ou juntou documentação em violação ao procedimento. 4. Na segunda vertente, enfocando mais propriamente os aspectos técnicos da solução, será demonstrado o perfeito atendimento a todos os requisitos técnicos estipulados no edital de licitação. 12

2. MÉRITO 2.1. Da juntada de documentos 5. O primeiro tópico destas contra-razões toca a preliminar argüida pela Vertax, que, supostamente, teria encontrado equívoco formal na apresentação da proposta e dos posteriores esclarecimentos pela NCT Informática. Aponta, para referendar sua tese, que as páginas 187 dos dois documentos FortiMail v3.0 MR4 Administration Guide.pdf (usada, nos esclarecimentos prestados pela NCT, para comprovar o atendimento ao subitem 2.10 do termo de referência) são discrepantes. 6. Entretanto, não atentou a recorrente para o fato de os dois documentos terem sido produzidos em momento diferente e, o que é mais importante, não trazerem qualquer contradição entre si. É a mesma comprovação, atinente ao mesmo produto, apenas organizada de forma distinta, o que, certamente, como se verá, não constitui ilícito. 7. O primeiro documento, apresentado originalmente pela NCT, é o FortiMail v3.0 MR4 Administration Guide.pdf, datado de 24 de julho de 2008. Neste documento, a comprovação de atendimento ao subitem 2.10 do termo de referência está nas páginas 29, 174 e 176, que tratam da funcionalidade Verify Recipient Address. Estas páginas, como pode ser analisado pela documentação já acostada ao processo, comprovam, inequivocamente, que a funcionalidade requerida pelo edital é suportada pelo equipamento ofertado pela NCT. 8. Quando do pedido de esclarecimentos da NCT, foi apresentado o mesmo FortiMail v3.0 MR4 Administration Guide.pdf. Ocorre que o documento, então, já estava em sua nova versão, datada de 4 de setembro de 2008, comprovando o atendimento da funcionalidade na sua já citada página 187. 9. A datação dos dois documentos pode ser encontrada na página 2 de cada um, além das referências constantes dos rodapés das páginas de cada manual. O que é relevante para o deslinde da questão é que não há contradição de informações nos dois documentos. Ambos referem-se ao mesmo produto e contêm as mesmas especificações, apenas organizadas, para fins de sistematização da redação, de forma distinta. As explicações que estavam espraiadas no texto em três páginas distintas na antiga versão (p. 29, 174 e 176) foram condensadas numa única (p. 187) na nova versão. 10. Mas, reitere-se, é a mesma informação. Caso seja consultada a versão antiga do FortiMail v3.0 MR4 Administration Guide.pdf, encontrar-se-á, nas aludidas páginas (29, 174 e 176), a comprovação de atendimento à funcionalidade exigida, sem qualquer controvérsia. 11. Para seus esclarecimentos, a NCT apenas juntou a nova versão do manual porque era aquele disponibilizado pelo fabricante no momento tratado. Não haveria porque, dada a similaridade dos conteúdos, voltar-se à versão antiga para tanto, uma vez que o produto e as funções permaneceram iguais. 12. Entretanto, se realmente alguma dúvida houvesse quanto ao conteúdo da proposta da NCT, nada impediria a realização de diligências e até mesmo a juntada de novos documentos. 13. É que se, por um lado, fosse admitido, apenas por hipótese, que o que havia sido apresentado na proposta comercial, em termos de documentos, não podia indicar certeza de que a proposta estava conforme ao Edital, também não permitiria, por outro lado, que se tomassem atitudes como a desclassificação da proposta da licitante vencedora, que é o que pretende a recorrente. 13

14. É que, no caso, tem lugar o poder (que melhor poderia ser entendido na acepção de poder-dever 1 ) de realização de diligências nas licitações, disciplinado pelo art. 43, 3º 2, da Lei nº 8.666/93. 15. Ou seja, dubiedades que impeçam um processo de tomada de decisões perfeitamente claro devem ser resolvidas com acesso às diligências em questão, as quais, por imposição legal, apenas devem abster-se de uma única medida: suprir falhas da proposta (como falta de documentos obrigatórios) a posteriori, o que seria ofensa ao devido processo legal e à isonomia. 16. O caso não trata da falta de documentos obrigatórios, mas de dúvidas em relação aos mesmos. Assim, a diligência para solução de omissões ou esclarecimento de dúvidas não estava limitada por qualquer ângulo, podendo, de forma ampliada, requerer a produção de novos documentos (sem que fosse caracterizada a ilicitude disciplinada em lei), solicitar a prestação de esclarecimentos escritos, analisar dados que tivesse à disposição etc. 17. Dizer o contrário, como fez a Vertax (para quem a NCT apenas poderia explicar os documentos já apresentados, sem produzir mais nenhuma prova) é fechar os olhos para essa tranqüila interpretação da lei. 18. É o que afirma Marçal Justen Filho, para quem a questão apresentase da seguinte forma: Se os documentos apresentados pelo particular ou as informações neles contidas envolverem pontos obscuros apurados de ofício pela Comissão ou por provocação de interessados, a realização de diligências será obrigatória. Ou seja, não é possível decidir a questão (seja para desclassificar o licitante, seja para reputar superada a questão) mediante uma escolha de mera vontade. Portanto, a realização da diligência será obrigatória se houver dúvidas relevantes. 3 19. A opinião doutrinária põe de manifesto que a decisão de desclassificação, por sua seriedade, não pode ser envolta num ambiente de dúvidas. Mais à frente, o mesmo doutrinador manifesta-se a respeito do conteúdo das diligências, ensinando o seguinte: 1 Na lição de Celso Antônio Bandeira de Mello: É que a Administração exerce função: a função administrativa. Existe função quando alguém está investido no dever de satisfazer dadas finalidades em prol do interesse de outrem, necessitando, para tanto, manejar os poderes requeridos para supri-las. Logo, tais poderes são instrumentais ao alcance das sobreditas finalidades. Sem eles, o sujeito investido na função não teria como desincumbir-se do dever posto a seu cargo. Donde, quem os titulariza maneja, na verdade, deveres-poderes, no interesse alheio. (MELLO, C. A. B. de. Curso de Direito Administrativo. 16 ed. São Paulo: Malheiros, 2003, p. 62). 2 Art. 43. (...) 3º. É facultada à Comissão ou autoridade superior, em qualquer fase da licitação, a promoção de diligência destinada a esclarecer ou a complementar a instrução do processo, vedada a inclusão posterior de documento ou informação que deveria constar originariamente da proposta. 3 JUSTEN FILHO, M. Comentários à Lei de Licitações e Contratos Administrativos. 10 ed. São Paulo: Dialética, 2004, p. 417. Grifo nosso. 14

Qual a extensão da diligência? A Lei determina a vedação à apresentação de documentos que deveriam ter constado dos envelopes. Isso não equivale, no entanto, a proibir a juntada de qualquer documento. Se o particular apresentou um documento e se reputa existir dúvida quanto a seu conteúdo, é possível que a diligência se traduza numa convocação ao particular para explicar e, se for o caso, COMPROVAR DOCUMENTALMENTE O CONTEÚDO DA DOCUMENTAÇÃO ANTERIOR. 4 20. Ora, se alguma dúvida existia quanto à aptidão da proposta da recorrida, foi totalmente correta a diligência realizada pelo CNPq, não havendo, também, qualquer irregularidade na apresentação de documentos que se dispusessem a esclarecer o conteúdo daqueles ofertados com a proposta comercial, no momento próprio. 21. Assim, seja porque o conteúdo dos dois documentos apresentados é o mesmo, seja porque não seria irregular a apresentação de novos documentos comprobatórios de atendimento aos itens técnicos do edital, impõe-se o desprovimento do recurso, na forma do pedido final. 2.2. Do atendimento aos requisitos técnicos do edital 2.2.1. Do atendimento ao subitem 5.2 do termo de referência 22. Segundo argüido pela Vertax, o equipamento não teria o condão de atender ao subitem 5.2 do termo de referência, o que, entretanto, é um entendimento equivocado. 23. Reafirma-se o que o próprio CNPq já reconheceu ao analisar os esclarecimentos prestados pela NCT: o subitem técnico analisado não especifica a modalidade de VPN quanto à alta disponibilidade. 24. Isso é evidente porque todos os demais subitens do edital, quando pretendem especificar a qual dos dispositivos fazem referência, são expressos quanto ao requerimento ser em relação a VPN IPSec ou VPN SSL. É o que se passa, por exemplo, com os subitens 5.5, 5.9, 5.10, entre outros, todos do mesmo termo de referência do edital de licitação. 25. Fica evidente a questão, apenas para prestar um exemplo concreto, em relação ao subitem 5.6, que tem o seguinte texto: Deverá possuir algoritmos de criptografia para túneis VPN: AES, DES, 3DES. Ora, estes algoritmos de criptografia, à exceção do DES, só são possíveis em VPN IPSec, que não foi expressamente citada no subitem. 26. Se a argumentação da recorrente quanto a subentender que ambas as modalidades de VPN (IPSec e SSL) deveriam atender ao requisito técnico ainda quando não expresso qual delas será exigida, também este subitem 5.6, entre outros, deveria ser atendido por ambas (IPSec e SSL), o que não é possível tecnicamente, conduzindo ao insucesso da licitação. 27. Por isso é que, conforme já reconheceu o CNPq, a especificação discriminada neste item não determina para qual modo de operação, em específico, deverá haver alta disponibilidade, sendo portanto aceitos, os recursos apresentados. 28. E é por isso, também, que não se pode exigir a alta disponibilidade nas duas modalidades de VPN, estando completamente apta a atender ao edital a 4 Idem, ibidem. Grifo e destaque nossos. 15

solução que mantenha a alta disponibilidade (sem perda de conexões) em VPN IPSec ou VPN SSL. 29. Por isso, também, é que a capacidade de suportar alta disponibilidade pelo equipamento ofertado pela NCT mostra-se incontroversa, não cabendo qualquer questionamento quanto a esse ponto. 30. O que nos causa estranheza, sendo a Vertax uma empresa técnica especializada no mercado, é considerar, argumentando do jeito que fez em seu recurso, que também esse subitem deveria ser atendido por ambas as modalidades de VPN, já que não foi especificado o IPSec. Isso acarretaria o total fracasso do processo licitatório visto que nenhum licitante conseguiria atender a tal requisito técnico. 31. Quanto à argumentação de que, por se tratar o equipamento ofertado de um UTM (Unified Threat Management), aplicar-se-ia o subitem 1.5 também para as funções de VPN, não há procedência. 32. Isso porque, apesar de o equipamento UTM executar com vantagens diversas funções que outras empresas só conseguem com equipamentos individuais e específicos, cada uma destas características possui módulos e funções independentes. Se assim não o fosse, como teria tal solução angariado um número tão grande de certificações (ICSA Labs: Antivirus, Firewall, IPSec, SSL-TLS, IPS e Antispam), sendo a Fortinet a única empresa a possuir seis certificações? 33. Ou seja, fica claro que tal solução é performática para receber certificações específicas do ICSA Labs, concorrendo com fabricantes como CheckPoint e Juniper e seus equipamentos específicos de VPN SSL. 34. Logo, trata-se de uma questão de bom senso quanto ao conhecimento das características de funcionamento e especificação de cada recurso e a identificação dos mesmos no que foi solicitado em cada subitem, não dedução, como dito erroneamente pela empresa Vertax. 2.2.2. Do atendimento ao subitem 5.11 do termo de referência 35. Primeiramente, um pouco de história. Segundo a Wikipedia em português, O VT100 foi o primeiro terminal da DEC (Digital Equipment Corporation) a incorporar um microprocessador-padrão, o Intel 8080. Foi também um dos primeiros terminais a utilizar sequências de escape ANSI e tornou-se um paradigma de fato para emuladores de terminal. 36. Em sua versão em Inglês (http://en.wikipedia.org/wiki/vt100) este é o relato: VT100 is a video terminal which was made by Digital Equipment Corporation (DEC). It became the de facto standard used by terminal emulators. It was introduced in August 1978, following its predecessor, the VT52, and communicated with its host system over serial lines using the ASCII character set and control sequences (a.k.a. escape sequences) standardized by ANSI. The VT100 was also the first Digital mass-market terminal to incorporate "graphic renditions" (blinking, bolding, reverse video, and underlining) as well as a selectable 80 or 132 column display. 16

All setup of the VT100 was accomplished using interactive displays presented on the screen; the setup data was stored in non-volatile memory within the terminal. The VT100 also introduced an additional character set that allowed the drawing of on-screen forms. The control sequences used by the VT100 family are based on the ANSI X3.64 standard, later ECMA-48 and ISO/IEC 6429. These are sometimes referred to as ANSI escape codes. The VT100 was not the first terminal to be based on X3.64 The Heath Company had a microprocessor-based video terminal that implemented a subset of the standard proposed by ANSI in X3.64 [1]. The VT100 was also the first of Digital's terminals to be based upon an industry-standard microprocessor (in this case, the Intel 8080). Options could be added to the terminal to support an external printer and additional graphic renditions and memory (the "AVO" 'Advanced' Video Option without this option, the VT100 could not display a full 24 lines of text when in 132 column mode). The VT101 and VT102 were cost-reduced non-expandable follow-on products, with the VT102 including the AVO and serial printer port options of the VT100. The VT100 became a platform on which Digital constructed related products. The VT105 contained a simple graphics subsystem mostly-compatible with the earlier VT55. The VT125 added an implementation of the byte-efficient Remote Graphic Instruction Set (ReGIS.) The VT103 added a built-in LSI-11 processor while the VT278 added a built-in PDP-8 processor, allowing the terminal to run Digital's WPS-8 word processing software. The VT180 (codenamed "Robin") added a single-board microcomputer using a Zilog Z80 to run CP/M. In 1983, the VT100 was replaced by the more-powerful VT200 series terminals such as the VT220. 17

In August 1995 the terminal business of Digital was sold to Boundless Technologies. 37. O tipo de terminais VT100 via Telnet e/ou SSH é amplamente suportado pela solução ofertada, como poderá ser comprovado no processo de homologação, não havendo as incompatibilidades citadas pela empresa Vertax, uma vez que, obviamente, o tipo de terminal a ser utilizado deverá ser especificado pela aplicação de emulação de terminal (Telnet, SSH, HyperTerminal, TeraTerm etc.). 38. A título de exemplo, analisando-se o Telnet, aplicação simples e que pode ser acessada de qualquer máquina Windows, mostra-se o seguinte: Bem-vindo ao Cliente MS Telnet O caractere de escape é 'CTRL+ç' Microsoft Telnet> set term? Os tipos de terminal compatíveis sao apenas vt100, vt52, ansi e vtnt. Microsoft Telnet> 39. Como dito, uma vez utilizado o comando set term vt100, estaremos instruindo o Telnet a utilizar o tipo de terminal vt100. 40. Novamente, causa-nos estranheza que a Vertax, sendo uma empresa com especialidade técnica nas tecnologias aqui em discussão, apresente referências falsas a RFCs que apenas citam o tipo de terminal vt100 para acesso aos hosts listados nestas RFCs, que também aparecem noutros hosts que utilizam VT200, tn3270 etc. 41. Seria interessante que a Vertax, se possível, apresentasse uma RFC que especificasse o padrão para VT100, ou algum outro documento que comprove a argumentação de que deve estar sempre explícito que o VT100 é suportado pela aplicação que o utilizará, uma vez que problemas de compatibilidade poderão impossibilitar o serviço desejado. 42. Ora, soa muito vago e enganoso tratando-se de empresa como a Vertax a referência ao VT100 como emulador. Citamos: Trata-se, portanto, de um emulador não suportado pela solução ofertada (...). 43. Como é sabido pela Vertax, VT100 é um tipo de terminal, e não emulador, o qual, conforme demonstrado acima, e poderá ser constatado nos testes específicos, é absolutamente atendido pela solução ofertada pela NCT. 3. pedido final 44. Diante do que se expôs, protesta-se pelo desprovimento integral do recurso interposto por VERTAX REDES E COMUNICAÇÕES LTDA, impondo-se a manutenção da vitória no certame da ora recorrida. 18

A EM RESUMO A VERTAX REDES E COMUNICAÇÕES LTDA REQUER:...requer se digne Vossa Excelência de receber o presente recurso no efeito suspensivo, nos estritos termos do 2 do artigo 109, da Lei de Licitações, e de reconsiderar a decisão que declarou a empresa NCT INFORMÁTICA LTDA como vencedora do presente Pregão, desclassificando-a em razão de sua solução não atender aos já apontados requisitos do Edital. No remoto caso de desprovimento dos pedidos acima, requer, nos termos do 4, do artigo 109 da Lei 8.666/93, alçar o presente recurso devidamente informado, à autoridade superior, para que dele conheça e o proveja. B EM RESUMO A NCT INFORMÁTICA LTDA REQUER:...protesta-se pelo desprovimento integral do recurso interposto por VERTAX REDES E COMUNICAÇÕES LTDA, impondo-se a manutenção da vitória no certame da ora recorrida. 1. DA ANÁLISE DO RECURSO INTERPOSTO E DAS CONTRA-RAZÕES APRESENTADAS - COMENTÁRIOS DA PREGOEIRA: Inicialmente deve ficar consignado que a documentação técnica apresentada para a contratação de empresa especializada para a aquisição da Solução de Segurança de Rede e Informação no ambiente computacional do CNPq, incluindo a configuração, testes, implantação, suporte e assistência técnica durante o período de garantia dos produtos componentes da Solução, foram analisados pela área técnica deste Conselho, que informaram que a documentação apresentada pela empresa NCT INFORMÁTICA LTDA, atendem aos requisitos do edital para sua qualificação técnica. Entendemos, assim que as documentações apresentadas comprovam a aptidão da licitante para o desempenho de atividades pertinentes e compatíveis em características técnicas com o objeto da licitação razão pela qual não prospera a alegação da recorrente. CONCLUSÃO 19

a) Diante da exposição acima, o Pregoeiro e sua equipe, assim como a Administração Superior deste Conselho, como é de praxe, buscam selecionar a(s) proposta(s) mais vantajosas, assegurando oportunidade igual a todos os interessados e possibilitando o comparecimento ao certame do maior número possível de concorrentes, em estreita observância aos princípios que norteiam a licitação. b) Assim, a Pregoeira e sua equipe de apoio, diante das razões e documentação apresentada pela equipe técnica deste Conselho, conforme documentação anexa a este, decidem denegar provimento ao recurso interposto pela empresa VERTAX REDES E COMUNICAÇÕES LTDA, manter a classificação da empresa NCT INFORMÁTICA LTDA no Pregão Eletrônico nº 22/2008, e submeter sua decisão à deliberação da Autoridade Superior. ROSITA ASSIS ROSA Pregoeira Oficial Equipe de Apoio Ana Conceição Muniz da Silva Anderson Malta da Silva Joana Batista Rodrigues Neto Equipe Técnica Geraldo Sorte Guido Saenen 20