Línguas
Páginas
Legal
Ministério do Planejamento, Desenvolvimento e Orçamento
Gestão Secretaria de Gestão Central de Compras
Secretaria de Tecnologia da Informação e Comunicação
RESPOSTA ÀS SUGESTÕES DA AUDIÊNCIA PÚBLICA Nº 001/2017
OBJETO: Contratação de empresa especializada no fornecimento de soluções de segurança de redes compostas de firewall corporativo e multifuncional para prover segurança e proteção da rede dos órgãos e dos servidores de rede, contemplando gerência unificada com garantia de funcionamento pelo período de 60 (sessenta) meses, incluídos todos os softwares e suas licenças de uso, gerenciamento centralizado, serviços de implantação, garantia de atualização contínua, suporte técnico e repasse de conhecimento de toda a solução a fim de atender às necessidades dos órgãos contratantes.
CONTRIBUIÇÕES:
Item 1.1.20. A solução ofertada, e demais equipamentos necessários a execução do Teste de Conformidade, deverão ser instalados, configurados, operados e acessados pela Equipe Técnica da
Licitante Convocada, sempre acompanhada e supervisionada pelo grupo técnico de apoio ao pregoeiro.
1.1.20.1. A não observância desse item poderá acarretar no reinício do Teste de Conformidade, ou mesmo
na reprovação da solução ofertada.
Manifestação: Uma vez que o local do ambiente de teste será provido pelo licitante convocado,
entendemos que o mesmo poderá terá acesso ao equipamentos, fora do horário dos testes, antes das 09h
e após as 18h. Está correto nosso entendimento? Caso contrário, quais mecanismo estão previstos para
que a licitante não tenho acesso aos equipamento fora do horário oficial dos testes?
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 1.3.2. A solução ofertada deverá então ser atualizada para a versão mais atual de firmware, software,
listas de assinaturas e afins disponíveis pelos canais oficiais de suporte técnico do fabricante da solução.
Caso a versão atual tenha menos de 3 meses de liberação de uso para o mercado, será admitida a
utilização da versão imediatamente anterior.
Manifestação: No item 1.3.2 é tratada a questão da versão do software que será utilizado na solução
durante os testes, porém não identificamos formas de validar estes softwares. Sugerimos que sejam
inseridos meios de verificação destes softwares (verificação e comparação de hash, por exemplo)
visando garantir que os softwares utilizados estão em conformidade com os oficiais do fabricante.
Resposta: Sugestão acatada.
Item 1.3.5 Antes da execução dos testes, será realizada uma aferição do gerador de tráfego da seguinte
forma: as portas estarão em loops, no qual serão gerados os tráfegos, com os respectivos percentuais
solicitados, bem como as ameaças. A documentação do processo deverá ter como insumos arquivos do tipo
pcap ou similares.
Manifestação: No item 1.3.5 sugerimos que sejam previstas também algumas formas de capturar
amostras do tráfego gerado (captura de pacotes) para aferição do conteúdo previsto na especificação. É
muito simples realizar uma captura de pacotes durante a geração do tráfego solicitado para identificar os
protocolos, endereços, arquivos transferidos, etc.
Resposta: A equipe técnica, durante os testes, irá proceder de acordo com as necessidades de se
manter a lisura dos testes.
Item 1.3.6. A aferição durante os testes deve ser feita minimamente com os dados obtidos pelo gerador de
tráfego e pela gerência do firewall, sendo correlacionadas as duas informações. No caso do firewall, poderá
ser utilizado: a interface gráfica ou através da CLI.
Manifestação: No item 1.3.6 sugerimos que todas as aferições sejam realizadas somente através da
solução em avaliação (firewalls e gerência centralizada). As informações obtidas através dos geradores
de tráfego devem servir apenas para validar e complementar as informações obtidas nos equipamentos
de firewall e gerência.
Resposta: Não acatada. Apesar de a avaliação ser executada nas soluções de firewall e gerência
centralizada, faz-se necessário a verificação de todo o escopo do teste. A equipe técnica, durante
os testes, irá proceder de acordo com as necessidades de se manter a lisura dos testes
Item 1.4.3.2. A Rede Interna deverá possuir clientes, que deverão acessar a DMZ e a Rede Externa, a qual
deverá ser acessada por meio de NAT N-1. A quantidade de clientes varia de acordo com o porte do lote.
1.4.3.2.1. Lote 1, pelo menos 50 clientes.
1.4.3.2.2. Lote 2, pelo menos 125 clientes.
1.4.3.2.3. Lote 3, pelo menos 500 clientes.
1.4.3.2.4. Lote 4, pelo menos 1.500 clientes.
1.4.3.2.5. Lote 5, pelo menos 2.500 clientes.
Manifestação: Em relação ao item 1.4.3.2.1, 1.4.3.2.2, 1.4.3.2.3, 1.4.3.2.4 e 1.4.3.2.5, não ficou claro
como será comprovado o número de usuários e a nossa sugestão é o detalhamento de como será
realizado os testes de quantidade de clientes para cada teste.
Resposta: Não acatada. A solução de testes deverá fornecer meios de comprovar o quantitativo
solicitado e a equipe técnica, durante os testes, procederá de acordo com as necessidades de se
manter a lisura dos testes.
Item 1.4.5.1. Serão gerados ataques distintos de, no mínimo, 2.000 (duas mil) assinaturas de IPS/IDS
Manifestação: Entendemos que o valor de 2000 assinaturas é muito baixo. Os principais fabricantes
possuem mais do que 5 mil assinaturas e a ferramenta de geração de trafego é capaz de gerar 8000
ataques. Em produção os clientes irão querer usar a tecnologia com todas as assinaturas habilitadas,
portanto sugerimos que seja exigido, no mínimo, 5 mil assinaturas habilitadas.
Resposta: Não acatada. As especificações técnicas refletem a realidade dos ambientes de produção
habituais dos órgãos participes.
Item 1.4.5.4. Serão geradas um mínimo de 300 (trezentas) aplicações. Destas aplicações, 200 (duzentas)
serão conhecidas e pelo menos um mínimo de 100 (cem) serão aleatórias, as quais serão definidas no
momento do teste e fornecidas através de arquivos de captura reais em ambientes da APF, devendo ser
testadas e categorizadas.
Manifestação: Sugerimos que antes da publicação o edital, o órgão convide as empresas de geração de
tráfego para gerar/carregar no gerador o tráfego das 300 aplicações com garantia de não haja erros
irrecuperáveis de TCP dentro da própria captura tornado o teste inexequível.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 1.4.15. A amostra deverá ser então submetida a uma taxa de transferência de 85% do throughput do
lote, no padrão de tráfego do item 1.4.10, sendo testado, por 30 minutos e não poderá apresentar prejuízo
em sua performance.
Manifestação: O item 1.4.15 trata apenas de prejuízos de performance e não fala sobre as taxas de
detecção da solução. Sugerimos que seja explicitado que, durante os testes de maior throughput (85%
ou 80% do lote), as mesmas funcionalidades do item 1.4.4 deverão estar habilitadas simultaneamente,
seguindo as melhores práticas de segurança do fabricante da solução testada.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 1.4.17.1.1 Mensuração de novas sessões por segundo: a amostra deverá comprovar no mínimo 20%
de novas sessões por segundo do tamanho do lote, utilizando a distribuição de tráfego descrita no item
1.4.10 por no mínimo 5 (cinco) minutos. Para tal aferição, todas as assinaturas de IDS/IPS, antivírus e
antimalware, filtro de conteúdo web e controle de aplicação deverão ser habilitadas.
Manifestação: No item 1.4.17.1.1 Mensuração de novas sessões por segundo: a amostra deverá
comprovar no mínimo 20% de novas sessões por segundo do tamanho do lote, utilizando a distribuição
de tráfego descrita no item 1.4.10 por no mínimo 5 (cinco) minutos. Para tal aferição, todas as
assinaturas de IDS/IPS, antivírus e antimalware, filtro de conteúdo web e controle de aplicação deverão
ser habilitadas. Pedimos a revisão deste item uma vez que a distribuição de tráfego descrita no item
1.4.10 inclui pacotes stateless como UDP e VPN;
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 1.4.18 Durante a realização dos testes, será avaliada a solução de gerencia centralizada, que deve
permanecer acessível, possibilitando a modificação e aplicação de políticas de segurança, bem como a
visualização dos logs de acesso e de detecção de ameaças e aplicações.
Manifestação: Sugerimos que no item 1.4.18 o acesso a gerência centralizada deva ocorrer através da
interface gráfica da solução.
Resposta: Não acatada. Não se justifica tecnicamente tal solicitação. O que se procura atingir é a
lisura dos testes, independente do modo de acesso da gerencia centralizada.
Item 1.4.19 A licitante deve disponibilizar em até 5 dias úteis contados da data da finalização dos testes, o
relatório com todas as informações e resultados apurados durante os testes.
Manifestação: Sugerimos que o relatório seja entregue no mesmo dia da realização do teste de bancada,
logo após o seu término, para evitar que haja manipulações no relatório.
Resposta: Não acatada. A equipe técnica, durante os testes, procederá de acordo com as
necessidades de se manter a lisura dos testes.
Item 2.1.6 Todas as funcionalidades adquiridas de hardware e software devem operar conforme disposto
neste Termo de Referência durante o prazo de garantia dos equipamentos, ou seja, o fornecedor deve
garantir a atualização completa das funcionalidades no prazo referido, não sendo permitida a cobrança de
quaisquer valores adicionais pelo uso dos hardwares e softwares para esse período. As demais
funcionalidades deverão permanecer ativas, mesmo que não sejam atualizadas após o fim do prazo da
garantia.
Manifestação: O item exige que, mesmo após o término do prazo de garantia e suporte da solução, “as
demais funcionalidades deverão permanecer ativas”, entretanto, não faz especificação de quais
funcionalidades deverão manter-se funcionais após tal prazo. Solicitamos a alteração do texto a fim de
tornar-se mais clara essa demanda.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 2.1.6.2 Somente a funcionalidade de filtro de conteúdo web poderá ser desativada ao final do prazo de
garantia do equipamento, em razão de sua natureza técnica de acesso on-line as suas bases de dados.
Manifestação: Somente as funcionalidades de filtro de conteúdo web e anti-malware poderão ser
desativadas ao final do prazo de garantia do equipamento, em razão de sua natureza técnica de acesso
on-line as suas bases de dados.
Resposta: Não acatada. É de interesse da APF que a funcionalidade de anti-malware continue
funcionando ao final do prazo da garantia, mesmo que funcione com uma base local com
assinaturas armazenadas do último acesso as bases de dados antes do final desse prazo.
Item 2.1.10 O equipamento deve ser fornecido com todas as suas portas de comunicação,
interfaces e afins habilitadas, operacionais e sem custos adicionais, mesmo que para futuras utilizações do
órgão ou entidade CONTRANTE.
2.1.10.1 A contratada deve entregar a quantidade de transceivers equivalente ao dobro da quantidade
mínima de portas exigidas em cada lote conforme os itens 3.15.1.4, 3.22.1.4 e 3.29.1.4.
3.15.1.4 Possuir no mínimo 6 (seis) portas 10/100/1000 BASE-T, podendo 1 (uma) delas ser utilizada para
a gerência e 4 (quatro) portas 1 GE SFP, com os respectivos transceivers 1000 BASE-SX e padrão IEEE
802.3z.
3.22.1.4 Possuir no mínimo 6 (seis) portas 10/100/1000 BASE-T, podendo 1 (uma) delas ser utilizada para
gerência, 4 (quatro) portas 1GE SFP, com os respectivos transceivers 1000BASE-SX e padrão IEEE
802.3z, e 2 (duas) portas 10GE SFP+ ou XFP, com os respectivos transceivers 10GBASE-SR e padrão
IEEE 802.3ae.
3.29.1.4 Possuir no mínimo 6 (seis) portas 10/100/1000 BASE-T, podendo 01 (uma) delas ser utilizada
para gerência, 6 (seis) portas 1GE SFP, com os respectivos transceivers 1000BASE-SX e padrão IEEE
802.3z, e 4 (quatro) portas de 10GE SFP+ ou XFP, com os respectivos transceivers 10 GBASE-SR e
padrão IEEE 802.3ae.
Manifestação: Há uma incoerência nos itens 2.1.10, 2.1.10.1 e os itens 3.15.1.4, 3.22.1.4 e 3.29.1.4. No
item 2.1.10 exige-se que todas as interfaces do equipamento fornecido estejam habilitadas. Portanto, se
essas interfaces fornecidas no equipamento exigirem transceivers, a exigência do item 2.1.10 por si só já
elimina a necessidade das exigências de transceivers nos itens 3.15.1.4, 3.22.1.4 e 3.29.1.4, pois da
forma como está, gerou dúvidas. E ainda, quanto ao item 2.1.10.1, não entendemos por quê dobrar a
quantidade de transceivers. Favor esclarecer.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 2.1.10.1 A contratada deve entregar a quantidade de transceivers equivalente ao dobro da quantidade
mínima de portas exigidas em cada lote conforme os itens 3.15.1.4, 3.22.1.4 e 3.29.1.4. No caso de
interfaces fixas ao equipamento, a CONTRATADA deverá garantir o fornecimento de apenas 1 mini Gbic
para cada interface.
Manifestação: No caso em que a quantidade mínima de portas é atendida através de fornecimento de
transceivers, a contratada deverá entregar a quantidade de transceivers equivalente ao dobro da
quantidade mínima de portas exigidas em cada lote conforme os itens 3.15.1.4, 3.22.1.4 e 3.29.1.4,
tendo como exceção, apenas quando se tratar de interfaces fixas do equipamento.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.11.2 O equipamento do lote 5 da solução ofertada, pode ser baseado em appliance ou chassi e
deverá ter atestada, pelo fabricante, a compatibilidade entre os módulos e o chassi e deverá suportar
agregação de enlaces multi-chassi (MC-LAG), segundo padrão IEEE 802.1ax.
Manifestação: O equipamento do lote 5 da solução ofertada, pode ser baseada em appliance ou chassi,
deverá ter atestada, pelo fabricante, a compatibilidade entre os módulos e o chassi e deverá suportar
agregação de enlaces multi-chassi segundo padrões IEEE 802.1ax, e IEEE 802.1aq ou IEEE 802.3ad”.
Resposta: Não acatada. Não se justifica tecnicamente tal solicitação. A equipe técnica procurou
definir as especificações técnicas e condições de prestação do serviço de modo a manter um nível
elevado de competitividade entre os fornecedores.
Item 2.1.13 Deve suportar topologias de cluster redundante de alta disponibilidade (failover) no mínimo
aos pares, nos modos ativo-ativo e ativo-passivo, com sincronização, em tempo real, de configuração e de
estados das sessões. No caso de falha de um dos equipamentos do cluster, não deverá haver perda das
configurações e nem das sessões já estabelecidas e a transição entre os equipamentos deverá acontecer de
forma transparente para o usuário.
Manifestação: Deve suportar topologias de cluster redundante de alta disponibilidade (failover) no
mínimo aos pares, no modo ativo-passivo, com sincronização, em tempo real, de configuração e de
estados das sessões. No caso de falha de um dos equipamentos do cluster, não deverá haver perda das
configurações e nem das sessões já estabelecidas e a transição entre os equipamentos deverá acontecer
de forma transparente para o usuário.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.15 Possuir controle de acesso por endereço IP de origem e destino, por aplicação
(independentemente da porta ou protocolo utilizados pela aplicação), por sub-rede e por períodos do dia,
permitindo a aplicação de regras por horários e por dias da semana.
Manifestação: Possuir controle de acesso por endereço IP de origem e destino, por aplicação
(independentemente da porta ou protocolo utilizados pela aplicação) e por sub-rede.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.18 Permitir a criação de no mínimo 25 VLANs padrão 802.1q para os firewalls especificados nos
lotes 1, no mínimo 50 VLANs padrão 802.1q para os firewalls do lote 2 e no mínimo 500 VLANs padrão
802.1q para os firewalls especificados nos lotes 3, 4 e 5.
Manifestação: Entendemos que os equipamentos do tipo Firewalls não tem como função primária de
criação de VLANS, sendo que recomendamos a utilização de switches layer 3 para esse fim. Tendo
isso em vista, entendemos que a ofertando equipamentos com suporte até de 80 VLANs em todos os
modelos atendemos o Edital. Está correto o nosso entendimento?
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades
dos órgãos participantes.
Item 2.1.18 Permitir a criac ao de no minimo 25 VLANs padrao 802.1q para os firewalls especificados nos
lotes 1, no minimo 50 VLANs padrao 802.1q para os firewalls do lote 2 e no minimo 500 VLANs padrao
802.1q para os firewalls especificados nos lotes 3, 4 e 5.
Manifestação: Em Relação ao item 2.1.18, a quantidade de VLANs requerida é muito alta diante das
especificações do lote 3 que denotam um equipamento de médio porte. A implementação de
equipamentos desta natureza, seguramente não demanda esta quantidade de 500 VLANs. Este
entendimento é corroborado ao observarmos os tópicos 3.15.1.2, relacionado ao throuhgputs do
equipamento, que quando configurados com todas as funcionalidades ativas demonstram que há uma
discrepância quanto da quantidade de VLANs exigidas para os equipamentos do lote 3, de modo que
asseguramos que uma redução para 400 VLANs para tipo 3, as necessidades das instituições usuárias
serão supridas, além de assegurar uma oferta mais vantajosa por parte dos proponentes.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.18 Permitir a criação de no mínimo 25 VLANs padrão 802.1q para os firewalls especificados nos
lotes 1, no mínimo 50 VLANs padrão 802.1q para os firewalls do lote 2 e no mínimo 500 VLANs padrão
802.1q para os firewalls especificados nos lotes 3, 4 e 5.
Manifestação: Desde a primeira Consulta Pública, o quantitativo de VLANs para cada lote foi
questionado em termos de métricas utilizadas para atingir tais valores. Gostaríamos, assim, solicitar o
quantitativo proposto para o Lote 3 seja alterado para, no mínimo, 250 VLANs, visto que esse valor já é
hiper-dimensionado, com base na realidade objetiva de uso de soluções de firewall deste porte em redes
corporativas (dispositivos que costumam trabalhar com quantidades elevadas de VLANs costumam ser
switches e não firewalls). A especificação de um valor elevado e irreal de VLANs reduzirá a
competitividade e a economicidade do projeto para a Administração Pública (forçando o aumento de
preço), sem a contrapartida de benefícios reais para o uso da solução. Ante ao exposto, solicitamos a
alteração da quantidade de número de VLANs para o Lote 3 para 250.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.21 Suportar agregação de links, segundo padrão IEEE 802.3ad, nos equipamentos firewall
descritos nos lotes 3, 4 e 5.
Manifestação: 2.1.21 Suportar agregação de links, segundo padrão IEEE 802.3ad de forma estática e/ou
dinâmica, nos equipamentos firewall descritos nos lotes 3, 4 e 5.
Justificativa: O método de agregação de links utilizado pelo padrão IEEE 802.3ad se refere à forma de
configuração em estático e dinâmico, além da forma de como o tráfego é distribuído pelos enlaces. Na
configuração estática, as portas do switch das duas pontas do enlace precisam ser configuradas, já na
configuração dinâmica, as portas configuradas negociam para formar o LAG. O segundo método causa
em muitas vezes problemas para estabelecimento da comunicação, além de ocasionar um “delay” no
processo. Dito isso, entendemos que o requerimento de criação dinâmica de agregação de links não é
muito comum em um cenário real de Firewall e que serão aceitas soluções que suportam o protocolo
802.3ad com agregação de links de forma estática, que é o recomendado e praticado no mercado para
equipamentos desse porte.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.24.3 Deve prover identificação de forma transparente aos usuários autenticados por single sign-
on, no mínimo, por meio dos serviços Microsoft Active Directory e RADIUS;
Manifestação: Deve prover identificação de forma transparente aos usuários autenticados por single
sign-on, no mínimo, por meio dos serviços Microsoft Active Directory ou RADIUS;
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.28.1 Suportar, no mínimo, os protocolos de roteamento dinâmico RIP v2, OSPF v2 e v3 e BGP,
bem como as funcionalidades de roteamento estático e roteamento policy-based, inclusive IPv6;
Manifestação: No item 2.1.28.1 - Suportar, no mínimo, os protocolos de roteamento dinâmico RIP v2,
OSPF v2 e v3 e BGP, bem como as funcionalidades de roteamento estático e roteamento policy-based,
inclusive IPv6, verifica-se que de acordo com a RFC 2080, a versão do protocolo de roteamento
dinâmico RIP suportado para IPv6 é o RIPng e não o RIPv2. Desta forma, sugerimos a modificação do
item para suporte ao protocolo de roteamento dinâmico RIPng;
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 2.1.47.1 Deverão ser providas interface gráfica (GUI) e linha de comando - (CLI) ou via SSH -,
capazes de atender todas as funcionalidades gerenciais previstas nos subitens do item 2.1.47.
Manifestação: Sugestão: 2.1.47.1 Deverão ser providas interface gráfica (GUI) ou linha
de comando - (CLI) ou via SSH, capazes de atender todas as funcionalidades gerenciais previstas nos
subitens do item 2.1.47.
1- Conforme texto original, todas as funcionalidades gerenciais previstas nos sub-itens 2.1.47.1 a
2.1.47.15 deverão necessariamente ser gerenciados via linha de comando (CLI) ou via SSH (também
linha de comando), além da interface gráfica GUI (local ou centralizado). A nossa arquitetura atende à
todos as exigências descritas nos sub-itens 2.1.47.1 a 2.1.47.15 via interface gráfica GUI (local ou
centralizado), contudo não conseguimos atender via linha de comando (CLI) a todos os sub-itens
2.1.47.1 a 2.1.47.15. Por isso, solicitamos gentilmente tal mudança a fim de evitar duplas interpretações.
Resposta: Sugestão acatada.
Item 2.1.47.1 Deverão ser providas interface gráfica (GUI) e linha de comando - (CLI) ou via SSH -,
capazes de atender todas as funcionalidades gerenciais previstas nos subitens do item 2.1.47.
Manifestação: Deverão ser providas interface gráfica (GUI) para todas as funcionalidades gerenciais
previstas nos subitens do item 2.1.47 e linha de comando - (CLI) ou via SSH para configurações
pontuais e troubleshooting.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 2.1.47.8 Deve contabilizar a utilização ("hit counts") ou o volume de dados trafegados correspondente
a cada regra de filtragem individualmente.
Manifestação: Sugestão de remoção.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.47.9 Deve possibilitar a especificação de política por tempo, ou seja, permitir a definição de
regras para um determinado horário ou período (dia, mês, ano, dia da semana e hora).
Manifestação: Sugestão de remoção.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.47.15 Deverá suportar gerência remota (via rede local ou WAN) ou por meio de sistemas
centralizados externos, além da gerência local, tanto por meio de interface gráfica quanto por meio de linha
de comando ou via SSH, sendo que:
2.1.47.15.1 A comunicação entre a estação ou sistema de gerência e o firewall ou cluster local deverá ser
criptografada e autenticada;
2.1.47.15.2 As funcionalidades gerenciadas devem ser, no mínimo, as mesmas previstas no item 2.1.47;
Manifestação: Sugestão: 2.1.47.15 Deverá suportar gerência remota (via rede local ou WAN) ou por
meio de sistemas centralizados externos, sendo que:
2.1.47.15.1 A comunicação entre a estação ou sistema de gerência e o firewall ou cluster local deverá
ser criptografada e autenticada;
1- Conforme texto original, o termo “além da gerência local” pode inferir que o TR exige gerência
remota e gerência local simultaneamente. A arquitetura da nossa solução trabalha com módulos de
gerência e gateway independentes entre si, garantindo assim a segregação destas funções. A fim de
evitar duplos entendimentos frente ao nosso atendimento ao TR, pedimos a remoção do texto “além da
gerência local”, pois não será possível trabalhar com gerência local e centralizada simultaneamente.
2- Outra mudança importante dentro do mesmo item 2.1.47.15 é a remoção do termo “quanto por meio
de linha de comando ou via SSH”. Conforme primeira solicitação de mudança, a nossa arquitetura
atende à todos as exigências descritas nos sub-itens 2.1.47.1 a 2.1.47.15 via interce gráfica GUI (local
ou centralizado), contudo não conseguimos atender via linha de comando (CLI) a todos os sub-itens
2.1.47.1 a 2.1.47.15.
3- Por último, mas não menos importante, o item 2.1.47.15.2 As funcionalidades gerenciadas devem
ser, no mínimo, as mesmas previstas no item 2.1.47, precisa ser removido na íntegra, visto que ele exige
novamente que todas as funcionalidades descritas nos sub-itens 2.1.47.1 a 2.1.47.15 sejam
necessariamente atendidos via COMAND LINE INTERFACE (CLI). A nossa arquitetura atende à
todos as exigências descritas nos sub-itens 2.1.47.1 a 2.1.47.15 via interce gráfica GUI (local ou
centralizado), contudo não conseguimos atender via linha de comando (CLI) a todos os sub-itens
2.1.47.1 a 2.1.47.15.
Resposta: Sugestão acatada.
Item 2.1.51 As funcionalidades de VPN não podem possuir qualquer restrição de licenciamento, inclusive
em relação ao número de clientes, aos softwares instalados nos clientes, IPs e máquinas, limitado a capacidade de throughput do equipamento para VPN.
Manifestação: Entendemos que, caso a VPN possua recurso licenciado de NAC para checagem de
conformidade do dispositivo remoto, o fornecimento desta licença não será obrigatório uma vez que o
TR não especifica essa funcionalidade. Está correto nosso entendimento?
Resposta: O entendimento está incorreto. Caso a solução dependa de licenciamento de funções
especificas de NAC para atender requisitos de VPN disposto no edital, será obrigatório o
fornecimento da licença requerida sem ônus para a CONTRATANTE.
Item 2.1.51 As funcionalidades de VPN nao podem possuir qualquer restricao de licenciamento, inclusive
em relacao ao numero de clientes, aos softwares instalados nos clientes, IPs e maquinas, limitado a
capacidade de throughput do equipamento para VPN.
Manifestação: Em relação ao item 2.1.51, é requerida a não restrição de licenciamento em relação ao
número de clientes, sugerimos que seja definido um número mínimo para os lotes 1, 2 e 3 sendo 5
VPNs para o Lote 1, 15 VPNs para o lote 2 e 2000 VPNs para o lote 3. A razão da nossa proposta é a
real necessidade de propormos um equipamento equivalente em performance técnica e competitividade
financeira diante de soluções concorrentes
Resposta: Não acatada. Tecnicamente implica em equipamentos com capacidade reduzida, o que
é incompatível com a perspectiva de uso da solução (60 meses) pelos órgãos.
Item 2.1.51 As funcionalidades de VPN não podem possuir qualquer restrição de licenciamento, inclusive
em relação ao número de clientes, aos softwares instalados nos clientes, IPs e máquinas, limitado a
capacidade de throughput do equipamento para VPN.
Manifestação: As funcionalidades de VPN não podem possuir qualquer restrição de Licenciamento para
atender as funcionalidades previstas nos itens a seguir, inclusive em relação ao número de clientes, aos
softwares instalados nos clientes, IPs e máquinas, limitado a capacidade de throughput do equipamento
para VPN.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.1.57 Deve suportar a customização da interface Web para acesso a VPN pelos administradores do
sistema, incluindo quais aplicativos, servidores e sistemas estarão acessíveis via portal;
Manifestação: Em caso de VPN Clientless, deve suportar a customização da interface Web para acesso
a VPN pelos administradores do sistema, incluindo quais aplicativos, servidores e sistemas estarão
acessíveis via portal. A funcionalidade contradiz com o item 2.1.56 que deixa opcional o recurso de
VPN do tipo Clientless.
Resposta: Não acatada. O item 2.1.56 se refere a utilização por parte do usuário geral, enquanto
que o item 2.1.57 se refere as funcionalidades geridas pelo administrador.
Item 2.1.70 Possuir gerenciamento gráfico das funcionalidades de VPN e monitoramento de seus eventos
de forma integrada tanto ao gerenciamento local do equipamento ou do cluster quanto ao centralizado da
solução. Deve também permitir o gerenciamento dos processos associados por meio de CLI (command-line
interface) ou via SSH;
Manifestação: Sugestão: 2.1.70 Possuir gerenciamento gráfico das funcionalidades de VPN e
monitoramento de seus eventos de forma integrada tanto ao gerenciamento local do equipamento ou do
cluster quanto ao centralizado da solução.
1- Estávamos atendendo ao item antes da modificação, contudo, após a última alteração de texto ao item
2.1.70, o texto “Deve também permitir o gerenciamento dos processos associados por meio de CLI
(command-line interface) ou por acesso via SSH” foi inserido de forma que causa duplo entendimento
de que TODOS os recursos de gerenciamento e monitoramento devam ser atendidos tanto via gerência
gráfica (GUI), quanto via linha de comandos (CLI) ou SSH. A nossa arquitetura atende à todas as
exigências de gerenciamento e monitoramento descritos no Termo de Referência via gerência gráfica
(GUI), contudo nem todas as exigências de gerenciamento e monitoração dos processos associados às
funcionalidades de VPN estão sendo atendidos por nós via linha de comando (CLI) ou SSH. Sendo
assim, gentilmente e a fim de evitar contra-tempos devido a duplos entendimentos durante o processo
de homologação, solicitamos a remoção do texto incluído.
Resposta: Sugestão acatada.
Item 2.3.2 Possuir, no mínimo, um conjunto de 2.000 (duas mil) assinaturas de detecção e prevenção de
ataques, devendo também detectar ataques baseados em anomalias;
Manifestação: No item 2.3.2 - Possuir, no mínimo, um conjunto de 2.000 (duas mil) assinaturas de
detecção e prevenção de ataques, devendo também detectar ataques baseados em anomalias, para
garantir um maior nível de segurança da rede protegida, sugerimos a modificação do item para "um
conjunto de 5.000 (cinco mil) assinaturas de detecção e prevenção de ataques";
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.3.2 Possuir, no mínimo, um conjunto de 2.000 (duas mil) assinaturas de detecção e prevenção de
ataques, devendo também detectar ataques baseados em anomalias.
Manifestação: Entendemos que o valor de 2000 assinaturas é muito baixo. Os principais fabricantes
possuem mais do que 5 mil assinaturas e a ferramenta de geração de trafego é capaz de gerar 8000
ataques. Em produção os clientes irão querer usar a tecnologia com todas as assinaturas habilitadas,
portanto sugerimos que seja exigido, no mínimo, 5 mil assinaturas habilitadas.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.4.1 Possuir módulo de proteção contra antivírus, anti-malware e anti-bot no mesmo equipamento do
firewall;
Manifestação: Possuir módulo de proteção anti-malware e anti-bot no mesmo equipamento do firewall;
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.4.4 Deve possuir serviço de atualização automática e manual de assinaturas com o fabricante.
Manifestação: Entendemos que se a atualização automática é melhor maneira de manter todo o
ambiente atualizado com a última versão disponibilizada pelo fabricante, sendo que se somente for de
forma automática podemos atender ao Edital. Está correto o nosso entendimento?
Resposta: O entendimento está incorreto. A funcionalidade de atualização manual é requisito
fundamental no contexto definido.
Item 2.4.5 Suportar funcionamento mínimo da engine de antivírus e anti-malwares mesmo que a
comunicação com o site do fabricante esteja fora de operação;
Manifestação: Suportar funcionamento mínimo de engine anti-malwares mesmo que a comunicação
com o site do fabricante esteja fora de operação;
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.4.6 Possuir gerenciamento gráfico centralizado das funcionalidades de antivírus e anti-malware
integrado tanto com gerenciamento local do equipamento ou cluster quanto ao gerenciamento centralizado
da solução. Deve também permitir o gerenciamento dos processos associados por meio de CLI (command-
line interface) ou via acesso SSH;
Manifestação: Sugestão: 2.4.6 Possuir gerenciamento gráfico centralizado das funcionalidades de
antivírus e anti-malware integrado tanto com gerenciamento local do equipamento ou cluster quanto ao
gerenciamento centralizado da solução.
1- Estávamos atendendo ao item antes da modificação, contudo, após a última alteração de texto ao item
2.4.6, o texto “Deve também permitir o gerenciamento dos processos associados por meio de CLI
(command-line interface) ou por acesso via SSH” foi inserido de forma que causa duplo entendimento
de que TODOS os recursos de gerenciamento e monitoramento devam ser atendidos tanto via gerência
gráfica (GUI), quanto via linha de comandos (CLI) ou SSH. A nossa arquitetura atende à todas as
exigências de gerenciamento e monitoramento descritos no Termo de Referência via gerência gráfica
(GUI), contudo nem todas as exigências de gerenciamento e monitoração dos processos associados às
funcionalidades de ANTIVÍRUS e ANTI-MALWARE INTEGRADO estão sendo atendidos por nós via
linha de comando (CLI) ou SSH. Sendo assim, gentilmente e a fim de evitar contra-tempos devido a
duplos entendimentos durante o processo de homologação, solicitamos a remoção do texto incluído.
Resposta: Sugestão acatada.
Item 2.4.6 Possuir gerenciamento gráfico centralizado das funcionalidades de antivírus e anti-malware
integrado tanto com gerenciamento local do equipamento ou cluster quanto ao gerenciamento centralizado
da solução. Deve também permitir o gerenciamento dos processos associados por meio de CLI (command-
line interface) ou via acesso SSH;
Manifestação: Possuir gerenciamento gráfico centralizado das funcionalidades anti-malware integrado
tanto com gerenciamento local do equipamento ou cluster quanto ao gerenciamento centralizado da
solução. Deve também permitir o gerenciamento dos processos associados por meio de CLI (command-
line interface) ou via acesso SSH;
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 2.5.8 Permitir a criação de quotas de utilização por horário, ou por categorias, ou por aplicações;
Manifestação: Sugestão de remoção.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 2.6.1 Possuir módulo de filtro de aplicações e de conteúdo desenvolvido e mantido pelo próprio
fabricante, no mesmo equipamento do firewall;
Manifestação: Entendemos que tal exigência reduzirá a competitividade sem a contrapartida de
benefícios para o projeto. Entendemos, também, que o item em questão invalida um modelo de negócio
que utiliza o conceito de “Best of Breed”, ou seja, o fabricante utiliza em seus produtos elementos de
outros fabricantes visando prover a melhor solução aos seus clientes. Por exemplo: faz mais sentido
utilizar uma engine de antivírus de um dos melhores fabricantes do mercado, do que produzir uma
engine própria que não necessariamente terá a mesma qualidade. Ressaltamos que o uso de
elementos/módulos/componentes de outros fabricantes em produtos é uma prática relativamente comum
no mercado de tecnologia, tento em vista que a criação de conhecimento e tecnologia não é
necessariamente exclusiva, ou seja, o próprio sistema de patentes prevê a possibilidade de inovações
baseadas em conceitos já existes. O item 2.1.1 já prevê que o sistema operacional e o hardware devem
ser do mesmo fabricante, ou seja, o core do sistema já está protegido. Levando em consideração de que
no conceito de “Best of Breed” de nossa oferta, as funcionalidades são fornecidas e suportadas pelo
fabricante, não há qualquer tipo de prejuízo à Administração Pública no contexto em questão. Dessa
forma, sugerimos que o item seja alterado para que o módulo de filtro de aplicações e de conteúdo seja
fornecido e suportado pelo mesmo fabricante. Esta alteração protege a Administração Pública sem ferir
o princípio da competitividade.
Resposta: Não acatada. Não se justifica tecnicamente tal solicitação. A equipe técnica procurou
definir as especificações técnicas e condições de prestação do serviço de modo a manter um nível
elevado de competitividade entre os fornecedores.
Item 2.6.6 Garantir que as atualizações regulares do produto sejam realizadas sem interromper a execução
dos serviços de controle de aplicações;
Manifestação: No item 2.6.6 - Garantir que as atualizações regulares do produto sejam realizadas sem
interromper a execução dos serviços de controle de aplicações. Embora não tenhamos relatos de nossos
clientes reportando que houve interrupção de tráfego ou queda de sessão em momentos de atualização
da base de controle de aplicação, não há como garantir que isso não possa acontecer, uma vez que uma
atualização de base de assinaturas acarreta em uma reinicialização do serviço de controle de aplicação.
Acreditamos que o mesmo aconteça para os demais fabricantes. Desta forma, sugerimos que este item
seja por completo removido ou sua escrita alterada;
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 2.7.6 Toda a documentacao didatica necessaria aos cursos de treinamento devera ser disponibilizada
em papel impresso e midia digital.
Manifestação: Em relação ao item 2.7.6, sugerimos a seguinte alteração “Toda a treinamento e
documentacao didatica necessaria aos cursos de treinamento devera ser disponibilizada em papel
impresso e midia digital do matéria de administração que contemplam todos os assuntos do
treinamento”, pois o material de treinamento é exclusivo para os centro de treinamentos.
Resposta: Não acatada. A reprodução do material não tem intuito de uso comercial.
Item 3.1 LOTE 1–item 1:Firewall multifuncional Tipo 1
3.8 LOTE 2–item 1:Firewall multifuncional Tipo 2
3.15 LOTE 3–item 1:Firewall multifuncional Tipo 3
3.22 LOTE 4–item 1:Firewall multifuncional Tipo 4
3.29 LOTE 5–item 1:Firewall multifuncional Tipo 5
Manifestação: 3.1 LOTE 1–item 1:Firewall multifuncional Tipo 1
Novas conexões por segundo: 18,000
Conexões simultâneas: 450,000
3.8 LOTE 2–item 1:Firewall multifuncional Tipo2
Novas conexões por segundo: 55,000
Conexões simultâneas: 3,800,000
3.15 LOTE 3–item 1:Firewall multifuncional Tipo3
Novas conexões por segundo: 180,000
Conexões simultâneas: 5,800,000
3.22 LOTE 4–item 1:Firewall multifuncional Tipo 4
Novas conexões por segundo: 280,000
Conexões simultâneas: 7,800,000
3.29 LOTE 5–item 1:Firewall multifuncional Tipo 5
Novas conexões por segundo: 400,000
Conexões simultâneas: 12,000,000
Há várias soluções no mercado que, apesar de apresentarem um número grande de throughput (Gbps),
possui valores muito baixos em outros parâmetros importantes, são eles: Novas Conexões por segundo
(CPS): Para entender a importância deste parâmetro, basta lembrar que há várias verificações efetuadas
pelo Firewall antes que o tráfego possa passar através do “backplane” dele. Dentre elas, algumas
merecem especial destaque: Análise de Fluxo: o pacote que chegou à interface de entrada é parte de um
fluxo (conexão) existente ou é justamente o primeiro pacote e, portanto, uma nova conexão precisará ser
criada? Isto é particularmente importante para protocolos de aplicação que usam o TCP como
transporte, como as tarefas associadas ao “Three-way Handshake”. O pacote que chegou é permitido
pela ACL de entrada? Existe regra de NAT que permita a passagem do tráfego? Existe rota para
encaminhar o pacote? Existe regra de inspeção avançada para este fluxo? Só após estas verificações o
tráfego poderá usar o “backplane”. A limitação do valor de CPS geralmente impede que o elemento
chegue a usar o throughput (Gbps). Pacotes por Segundo (pps) – Esta é a principal métrica para
Roteadores e, considerando que os Stateful Firewalls, na maioria dos casos, atuam como elementos L3,
este parâmetro também não pode ser desprezado.
Na visão de um Firewall Stateful, uma mesma conexão pode envolver muitos pacotes trafegados.
Em algumas situações, o desempenho de algumas soluções são questionadas quando implementadas em
redes que trafegam muitos “pacotes pequenos”. Na realidade, o que acontece é o seguinte: os números
de “Marketing” eram calculados com pacotes grandes (maiores que 1500 bytes) e o resultado expresso
em Gbps. Os números do ambiente real seguiam um perfil IMIX (~450 bytes). Como a expectativa de
desempenho estava associada a Gbps, dificilmente um equipamento apenas com grande backplane, na
prática, apresenta boa performance real. Conexões Simultâneas: corresponde ao número instantâneo
máximo de entradas na tabela de conexões. Este atributo está de certa forma relacionado com o número
de CPS. Por quanto tempo o Firewall consegue absorver novas conexões (sem descartá-las) até o limite
de conexões simultâneas?
Em nossa visão, as novas conexões por segundo+ conexões simultâneas são os dois principais
parâmetros de Firewall, já que é um equipamento Statefull (diferente de um switch, que é em teoria é
stateless), e pode ser a qualquer momento alvo de um ataque de Negação de Serviço, por exemplo.
Quanto maior a sua capacidade de tratar novas conexões, maior será a resiliência do Firewall.
Throughput (Gigabits/segundo): um parâmetro associado à capacidade de encaminhamento.
Apesar de ser uma métrica muito importante para encaminhamento L2, no caso dos Stateful Firewalls
este parâmetro acaba se tornando secundário. Diante do que já foi exposto, o valor de Gbps deveria ser
uma consequência do número de Pacotes por Segundo (pps) suportado pelo equipamento e do
conhecimento das características de tamanho de pacote do ambiente em que o Firewall será instalado.
Como os parâmetros relacionados com pacotes por segundo já foram muito bem
Resposta: Não acatada. Não se justifica tecnicamente tal solicitação. A equipe técnica procurou
definir as especificações técnicas e condições de prestação do serviço de modo a manter um nível
elevado de competitividade entre os fornecedores.
Item 3.1.1.2 Possuir, no mínimo, o throughput de 1 Gbps para todas as funcionalidades dos itens 2.1, 2.2,
2.3, 2.4, 2.5 e 2.6, ativadas simultaneamente e com inspeção integral de todos os pacotes de dados,
independentemente de seu tamanho ou direção de fluxo, levando-se em consideração o perfil de tráfego
descrito no ANEXO E.
3.8.1.2 Possuir, no mínimo, o throughput de 1 Gbps para todas as funcionalidades dos itens 2.1, 2.2,
2.3, 2.4, 2.5 e 2.6, ativadas simultaneamente e com inspeção integral de todos os pacotes de dados,
independentemente de seu tamanho ou direção de fluxo, levando-se em consideração o perfil de tráfego
descrito no ANEXO E. 3.15.1.2 Possuir, no mínimo, o throughput de 1 Gbps para todas as funcionalidades dos itens 2.1, 2.2,
2.3, 2.4, 2.5 e 2.6, ativadas simultaneamente e com inspeção integral de todos os pacotes de dados,
independentemente de seu tamanho ou direção de fluxo, levando-se em consideração o perfil de tráfego
descrito no ANEXO E.
3.22.1.2 Possuir, no mínimo, o throughput de 5 Gbps para todas as funcionalidades dos itens 2.1, 2.2,
2.3, 2.4, 2.5 e 2.6, ativadas simultaneamente e com inspeção integral de todos os pacotes de dados,
independentemente de seu tamanho ou direção de fluxo, levando-se em consideração o perfil de tráfego
descrito no ANEXO E.
3.29.1.2 Possuir, no mínimo, o throughput de 10 Gbps para todas as funcionalidades dos itens 2.1,
2.2, 2.3, 2.4, 2.5 e 2.6, ativadas simultaneamente e com inspeção integral de todos os pacotes de dados,
independentemente de seu tamanho ou direção de fluxo, levando-se em consideração o perfil de tráfego
descrito no ANEXO E.
Manifestação: Nos itens 3.1.1.2, 3.8.1.2, 3.15.1.2, 3.22.1.2, 3.29.1.2 não está claro quanto às
funcionalidades que devem ser ativadas no teste de bancada. Para que o edital fique claro, informar se
as funcionalidades de IPS, Firewall, VPN/SSL, VPN IPSEC, Filtro de Conteúdo WEB, Filtro de URLs,
Controle de Aplicação, antivírus e anti-malware, etc. Sem deixar isto muito claro, não será possível
realizar a avaliação da solução.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 3.1.1.7 Quantidade de novas sessoes por segundo 5.000.
Manifestação: O modelo que gostaríamos de ofertar neste lote faz 4 mil sessões novas por segundo
aferido com pacote HTTP e payload de 4 kbytes. Gostaríamos de solicitar a alteração de 5 mil para 4
mil novas sessões por segundo CONSIDERANDO AS CONDIÇÕES DO TESTE DE BANCADA.
Entendemos que esta mudança não tratará prejuízos técnicos ao processo, pois estima-se que as
instituições que farão uso deste LOTE possuem um número de sessões novas por segundo abaixo de 1
mil, sendo 5 mil um valor encontrado em órgãos como ministérios de maior porte e universidades
federais.
Resposta: Não acatada. Tecnicamente implica em equipamentos com capacidade reduzida, o que
é incompatível com a perspectiva de uso da solução (60 meses) pelos órgãos.
Item 3.7.1.2 Possuir capacidade mínima de 100GB para armazenamento de logs e eventos.
3.14.1.2 Possuir capacidade mínima de 250 Gb para armazenamento de logs e eventos.
3.21.1.2 Possuir capacidade mínima de 1TB para armazenamento de logs e eventos.
3.28.1.2 Possuir capacidade mínima de 2 TB para armazenamento de logs e eventos.
3.35.1.2 Possuir capacidade mínima de 4 TB para armazenamento de logs e eventos.
Manifestação: A solução de gerência externa é disponibilizada por meio de Software e este poderá ser
instalado em ambiente Windows (i.e Windows 7, 8, Server). A máquina que irá hospedar a solução de
gerência centralizada, bem como a capacidade de storage exigida neste item, deverão ser
disponibilizados pelo CONTRATANTE, conforme aponta o item 2.2.1.3? Nosso entendimento está
correto?
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 3.8.1.6 Quantidade de novas sessoes por segundo 12.000.
Manifestação: O modelo que gostaríamos de ofertar neste lote faz 8 mil sessões novas por segundo
aferido com pacote HTTP e payload de 4 kbytes. Gostaríamos de solicitar a alteração de 12 mil para 8
mil novas sessões por segundo CONSIDERANDO AS CONDIÇÕES DO TESTE DE BANCADA.
Entendemos que esta mudança não tratará prejuízos técnicos ao processo, pois estima-se que as
instituições que farão uso deste LOTE possuem um número de sessões novas por segundo abaixo de 2
mil, sendo 12 mil um valor raramente encontrado em órgãos como ministérios e universidades federais.
Resposta: Não acatada. Tecnicamente implica em equipamentos com capacidade reduzida, o que
é incompatível com a perspectiva de uso da solução (60 meses) pelos órgãos.
Item 3.8.1.6 Quantidade de novas sessões por segundo 12.000.
Manifestação: Em relação ao item 3.8.1.6, Propomos a alteração do item 3.8.1.6, que trata da
quantidade de novas sessões por segundo, originalmente exigido na ordem de 13000, para uma
quantidade de 6000. A razão da nossa proposta é a real necessidade de propormos um equipamento
equivalente em performance técnica e competitividade financeira diante de soluções concorrentes.
Asseguramos que tal redução é compatível não impacta no throughput do equipamento no item 3.8.1.2.
Resposta: Não acatada. Tecnicamente implica em equipamentos com capacidade reduzida, o que
é incompatível com a perspectiva de uso da solução (60 meses) pelos órgãos.
Item 3.15.1.5 Possuir a capacidade mínima de 1 (um) disco rígido de 24 GB para armazenamento de logs.
Manifestação: Entendemos que, tento em vista que a previsão do uso de uma solução de gerenciamento
centralizado, que inclui a centralização de logs, a demanda pela a capacidade de armazenamento do
dispositivo do Firewall pode ser reduzida uma vez que estes logs serão enviados, em tempo real, para a
solução de gerenciamento centralizado. Sugerimos, portanto, visando proteger o princípio da
competitividade, que essa capacidade seja reduzida para 4GB, que é um valor suficiente para realizar o
cache local dos dados. Uma alternativa seria permitir que, caso a solução de gestão histórica dos logs
poder ser entregue sem ônus para a Administração, que nesse caso específico, a capacidade poderá ser
reduzida para 4GB.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.15.1.6 Quantidade de sessoes simultâneas 500.000.
Manifestação: O modelo que gostaríamos de ofertar neste lote, faz exatamente 500 mil sessões
simultâneas. CONSIDERANDO AS CONDIÇÕES DO TESTE DE BANCADA gostaríamos de
solicitar a redução para 450 mil sessões simultâneas.
Resposta: Não acatada. Tecnicamente implica em equipamentos com capacidade reduzida, o que
é incompatível com a perspectiva de uso da solução (60 meses) pelos órgãos.
Item 3.15.1.6 Suporte para no mínimo 3 (três) instancias virtuais.
Manifestação: Em relação ao item 3.15.1.6, é requerido o suporte mínimo de três instâncias virtuais,
sendo essa solicitação não tem coerência com o throughput solicitado no item 3.15.1.2, acarretando em
problemas de performances nas instâncias virtuais criadas, dessa forma solicitamos que seja solicitada
uma quantidade mínima de zonas suportadas com possibilidade de criação políticas distintas para cada
uma, sem haver a necessidade de compartilhamento de recursos e aumento de custos com o
licenciamento de instâncias virtuais. Asseguramos que tal alteração não impacta na oferta
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.15.1.6 Suporte para no mínimo 3 (três) instâncias virtuais.
Manifestação: Sugestão de remoção.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.15.1.6 Suporte para no mínimo 3 (três) instâncias virtuais.
Manifestação: Tendo em vista que é um recurso pouquíssimo utilizado nessa capacidade, sistemas
virtuais são mais apropriados em operadoras de Telecom, que não é o caso deste projeto; entendemos,
portanto, que a exigência desta funcionalidade fere o princípio da competitividade sem a contrapartida
de benefícios reais para o projeto. Os quantitativos expostos neste Termo de Referência, na seção que
especifica cada Lote, vão de encontro às especificações técnicas propostas. O Lote 3 exige 1Gbps de
throughput com os componentes de segurança e controle de conteúdo e ameaça habilitados; uma vez
que faça uso de instancias virtuais neste Firewall, os recursos do mesmo serão compartilhados entre
contextos criados podendo, assim, causar uma impossibilidade técnica dos equipamentos em atender as
demandas propostas pelo órgão. Gostaríamos de entender a real necessidade de suporte mínimo às
instancias virtuais pois, como já mencionado, é necessário levar em consideração a sua utilização bem
como os limites operacionais das caixas e as demandas dos órgãos que farão uso desta funcionalidade.
Caso haja uma necessidade real para tal, é possível atender com Firewalls virtuais com especificações
condizentes com o tráfego que irá ser realizado trazendo, assim, uma economia à Administração Pública
por conta do aumento da Competitividade.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.15.1.7 Quantidade de novas sessoes por segundo 50.000.
Manifestação: O modelo que gostaríamos de ofertar neste lote faz exatamente 50 mil sessões novas por
segundo em datasheet. Gostaríamos de solicitar a alteração de 50 mil para 25 mil novas sessões por
segundo CONSIDERANDO AS CONDIÇÕES DO TESTE DE BANCADA. Entendemos que esta
mudança não tratará prejuízos técnicos ao processo, pois estima-se que as instituições que farão uso
deste LOTE possuem um número de sessões novas por segundo abaixo de 10 mil, sendo 50 mil um
valor compatível com operadoras.
Resposta: Não acatada. Tecnicamente implica em equipamentos com capacidade reduzida, o que
é incompatível com a perspectiva de uso da solução (60 meses) pelos órgãos.
Item 3.22.1.4 Possuir no mínimo 6 (seis) portas 10/100/1000 BASE-T, podendo 1 (uma) delas ser utilizada
para gerência, 4 (quatro) portas 1GE SFP, com os respectivos transceivers 1000BASE-SX e padrão IEEE
802.3z, e 2 (duas) portas 10GE SFP+ ou XFP, com os respectivos transceivers 10GBASE-SR e padrão
IEEE 802.3ae.
Manifestação: Favor informar se para o item 3.22.1.4, no caso das interfaces 1G SFP será possível
fornecer interfaces com velocidade superior (10G SFP+ ou XFP)?
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.22.1.5 Possuir a capacidade mínima de 2 (dois) discos rígidos ou SSD de 120 GB em RAID 1 para
armazenamento de logs.
3.29.1.5 Possuir a capacidade mínima de 2 (dois) discos rígidos ou SSD de 240 GB em RAID 1
para armazenamento de logs
Manifestação: No LOTE 4, item 3.22.1.5 e no LOTE 5, item 3.29.1.5 exige-se que os appliances
possuam 2(dois) discos rígidos de 120 GB em RAID1 para armazenamento de logs. Há duas
considerações aqui. A primeira é que hoje os equipamentos não possuem discos rígidos em sua
configuração. O padrão atual é a utilização da tecnologia SSD ou compact flash. A segunda é que, na
nossa solução, os logs não ficam armazenados por muito tempo no próprio appliance e são transferidos
automaticamente para o sistema de gerenciamento. Sendo assim, o uso da tecnologia RAID1 não é
utilizada por considerar que os logs estarão seguros em ambiente de gerenciamento. O espaço de
armazenamento no appliance será utilizado apenas enquanto não houver conectividade com o sistema
de gerenciamento. Sendo assim, solicitamos a alteração dos itens para o seguinte texto: “Possuir
capacidade de armazenamento de logs de, no mínimo, 120 GB”.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.22.1.5 Possuir a capacidade mínima de 2 (dois) discos rígidos ou SSD de 120 GB em RAID 1 para
armazenamento de logs.
Manifestação: Possuir a capacidade mínima de 2 (dois) discos rígidos ou SSD de 120 GB em RAID 1
ou possuir disco único SSD de 200 GB hot-swappable para armazenamento de logs.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.22.1.5 Possuir a capacidade mínima de 2 (dois) discos rígidos ou SSD de 120 GB em RAID 1 para
armazenamento de logs.
Manifestação: O projeto prevê o uso de uma solução de gerenciamento centralizado de logs para os
firewalls. Levando em consideração que um appliance de firewall não é otimizado para indexação e
análise maciça de logs, incluindo maiores prazos de retenção, e sim para controle de trafego de dados,
faz pouco sentido onerar a solução com o sistema de RAID sobre SSD (tecnologia que possui
confiabilidade muito maior do que discos tradicionais). A funcionalidade de análise de log é
normalmente realizada de forma separada ao appliance de firewall, permitindo com isso realizar
pesquisas mais detalhadas e janelas maiores de tempo sem onerar o firewall. Desta forma, e levando em
consideração que alguns fabricantes entregam sem ônus a solução de gestão de logs, a exigência de
RAID sobre SSD fere os princípios da economicidade e competitividade sem contrapartida de
benefícios justificáveis para a Administração.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.22.1.7 Ser licenciado para no mínimo 10 instâncias virtuais.
Manifestação: Entendemos que a utilização de instâncias virtuais não é recomendada em alguns
casos pois não há um controle sobre o processamento e a interferência que uma instância virtual pode
gerar em outra instância, fazendo com que o uso desta tecnologia coloque em risco ambientes
simultâneos. Oferecemos a possibilidade de instalação de firewalls virtuais independentes e
recomendamos o uso de outros mecanismos de controle (por zona e redes segregadas), feitas
diretamente nos firewalls. Acreditamos que dessa forma podemos participar dessa licitação. Está correto
o nosso entendimento?
Resposta: O entendimento está incorreto. O requisito necessário é que um mesmo equipamento
físico deve ser capaz de executar um ou mais contextos ou instâncias virtuais de execução.
Item 3.22.1.7 Ser licenciado para no mínimo 10 instâncias virtuais.
Manifestação: Sugestão de remoção.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.22.1.7 Ser licenciado para no mínimo 10 instâncias virtuais.
Manifestação: Tendo em vista que é um recurso pouquíssimo utilizado nessa capacidade, sistemas
virtuais são mais apropriados em operadoras de Telecom, que não é o caso deste projeto; entendemos,
portanto, que a exigência desta funcionalidade fere o princípio da competitividade sem a contrapartida
de benefícios reais para o projeto. Os quantitativos expostos neste Termo de Referência, na seção que
especifica cada Lote, vai de encontro às especificações técnicas propostas. O Lote 4 exige 5Gbps de
throughput com os componentes de segurança e controle de conteúdo e ameaça habilitados; uma vez
que faça uso de instancias virtuais neste Firewall, os recursos do mesmo serão compartilhados entre
contextos criados podendo, assim, causar uma impossibilidade técnica dos equipamentos em atender as
demandas propostas pelo órgão. Gostaríamos de entender a real necessidade de suporte mínimo às
instancias virtuais pois, como já mencionado, é necessário levar em consideração a sua utilização bem
como os limites operacionais das caixas e as demandas dos órgãos que farão uso desta funcionalidade.
Caso haja uma necessidade real para tal, é possível atender com Firewalls virtuais com especificações
condizentes com o tráfego que irá ser realizado trazendo, assim, uma economia à Administração Pública
por conta do aumento da Competitividade.
Resposta: Não acatada. Não se justifica tecnicamente tal solicitação. A equipe técnica procurou
definir as especificações técnicas e condições de prestação do serviço de modo a manter um nível
elevado de competitividade entre os fornecedores.
Item 3.29.1.5 Possuir a capacidade mínima de 2 (dois) discos rígidos ou SSD de 240 GB em RAID 1 para
armazenamento de logs.
Manifestação: O projeto prevê o uso de uma solução de gerenciamento centralizado de logs para os
firewalls. Levando em consideração que um appliance de firewall não é otimizado para indexação e
análise maciça de logs, incluindo maiores prazos de retenção, e sim para controle de trafego de dados,
faz pouco sentido onerar a solução com o sistema de RAID sobre SSD (tecnologia que possui
confiabilidade muito maior do que discos tradicionais). A funcionalidade de análise de log é
normalmente realizada de forma separada ao appliance de firewall, permitindo com isso realizar
pesquisas mais detalhadas e janelas maiores de tempo sem onerar o firewall. Desta forma, e levando em
consideração que alguns fabricantes entregam sem ônus a solução de gestão de logs, a exigência de
RAID sobre SSD fere os princípios da economicidade e competitividade sem contrapartida de
benefícios justificáveis para a Administração.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.29.1.5 Possuir a capacidade mínima de 2 (dois) discos rígidos ou SSD de 240 GB em RAID 1 para
armazenamento de logs.
Manifestação: 3.29.1.5 Possuir a capacidade de exportar todos os logs para uma unidade de
armazenamento externa.
Justificativa: Para o pleno atendimento aos requisitos deste lote, iremos ofertar um NGFW de grande
porte, desenhado para o ambiente de tráfego intensivo e de alta performance demandado pelas
operadoras. Por ser um equipamento de grande porte, o armazenamento de logs internos não é viável,
pois tais discos certamente se esgotariam em pouco tempo criando um problema para o armazenamento
de longo prazo. A utilização da extensão de capacidade de armazenamento externo, possui algumas das
vantagens mais significativas frente ao disco interno, são elas:
O recurso de armazenamento do servidor de log pode ser facilmente estendido e sem interrupção de
serviço do NGFW.
2) Servidor de log pode fornecer capacidade de armazenamento que é quase impossível para NGFW
dispositivo ou chassis.
3) O servidor de registro pode fornecer um desempenho de log mais alto, e não afetará o desempenho do
NGFW.
4) Registro de escrita / leitura não será o gargalo de desempenho do sistema.
5) Maior confiabilidade do armazenamento de log
6) O servidor de registro pode ser configurado com matriz de disco, que tem maior confiabilidade que
SSD.
7) Armazenamento centralizado, gerenciamento unificado: Todos os logs são coletados e salvos em um
sistema de servidor de log unificado, como resultado o servidor pode fornecer a análise de logs de forma
global.
Tomando esses benefícios como prerrogativas para um bom desempenho e segurança do ambiente
computacional do órgão, entendemos que a utilização de discos externos (como já especificado no item
7, Solução de gerencia centralizada) atende à necessidade da especificação.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.29.1.7 Ser licenciado para no mínimo 20 instâncias virtuais
Manifestação: Entendemos que a utilização de instâncias virtuais não é recomendada em alguns casos
pois não há um controle sobre o processamento e a interferência que uma instância virtual pode gerar
em outra instância, fazendo com que o uso desta tecnologia coloque em risco ambientes simultâneos.
Oferecemos a possibilidade de instalação de firewalls virtuais independentes e recomendamos o uso de
outros mecanismos de controle (por zona e redes segregadas), feitas diretamente nos firewalls.
Acreditamos que dessa forma podemos participar dessa licitação. Está correto o nosso entendimento?
Resposta: O entendimento está incorreto. O requisito necessário é que um mesmo equipamento
físico deve ser capaz de executar um ou mais contextos ou instâncias virtuais de execução.
Item 3.29.1.7 Ser licenciado para no mínimo 20 instâncias virtuais.
Manifestação: Sugestão de remoção.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Item 3.29.1.7 Ser licenciado para no mínimo 20 instâncias virtuais.
Manifestação: Tendo em vista que é um recurso pouquíssimo utilizado nessa capacidade, sistemas
virtuais são mais apropriados em operadoras de Telecom, que não é o caso deste projeto; entendemos,
portanto, que a exigência desta funcionalidade fere o princípio da competitividade sem a contrapartida
de benefícios reais para o projeto. Os quantitativos expostos neste Termo de Referência, na seção que
especifica cada Lote, vão de encontro às especificações técnicas propostas. O Lote 5 exige 10Gbps de
throughput com os componentes de segurança e controle de conteúdo e ameaça habilitados; uma vez
que faça uso de instancias virtuais neste Firewall, os recursos do mesmo serão compartilhados entre
contextos criados podendo, assim, causar uma impossibilidade técnica dos equipamentos em atender as
demandas propostas pelo órgão. Gostaríamos de entender a real necessidade de suporte mínimo às
instancias virtuais, pois, como já mencionado, é necessário levar em consideração a sua utilização bem
como os limites operacionais das caixas e as demandas dos órgãos que farão uso desta funcionalidade.
Caso haja uma necessidade real para tal, é possível atender com Firewalls virtuais com especificações
condizentes com o tráfego que irá ser realizado trazendo, assim, uma economia à Administração Pública
por conta do aumento da competitividade.
Resposta: Não acatada. Não se justifica tecnicamente tal solicitação. A equipe técnica procurou
definir as especificações técnicas e condições de prestação do serviço de modo a manter um nível
elevado de competitividade entre os fornecedores.
Item 9.3 Responsabilizar-se pelo ônus e a logística da retirada e devolução dos equipamentos para
realização de serviços de garantia, bem como da substituição de equipamentos não aceitos, cabendo à
CONTRATANTE a emissão de documento fiscal ou equivalente necessário ao transporte do equipamento,
quando for o caso.
Item 12.4.6 A CONTRATADA, no caso da atualização de equipamento para corrigir falhas apresentadas,
deve se responsabilizar pelos custos envolvidos, inclusive eventuais trocas de hardware, cabendo à
CONTRATANTE a emissão de documento fiscal ou equivalente necessário ao transporte do equipamento,
quando for o caso.
Manifestação: Nos itens 9.3 e 12.4.6 do Termo de Referência, que trata da logística de substituição de
equipamentos em caso de defeitos, há que se verificar que há um procedimento legal obrigatório que
deve ser realizado pela CONTRATANTE. Este procedimento obrigatório refere-se à emissão de nota
fiscal de saída emitido pela CONTRATANTE e só pode ser realizado pela própria CONTRATANTE.
Favor alterar este item para que reflita esta obrigatoriedade por parte da CONTRATANTE, já que sem
esta nota fiscal, a CONTRATADA não poderá cumprir o SLA exigido.
Resposta: Os itens 9.2 e 12.4.6 deixam claros a responsabilidade da CONTRATANTE quanto às
providências referentes a emissão do documento fiscal necessário a movimentação dos bens (nota
fiscal avulsa de simples remessa, nota de movimentação, etc.).
Item 12.5.1 A troca de qualquer unidade defeituosa deverá ser realizada em conformidade com os prazos
estabelecidos na Tabela 1 – Níveis Mínimos de Serviço do item 11.1.
Manifestação: A troca de qualquer unidade defeituosa deverá ser realizada em conformidade com os
prazos estabelecidos abaixo.
Resposta: Não acatada. Manifestação incompleta.
Item 17.1 - Tabela 4
Manifestação: Comprovação por Atestado de Quantitativo Mínimo para o Lote, considerando a
justificativa do item, entendeu que a capacidade de fornecimento a ser exigida deve ser condizente com
o quantitativo a ser adquirido, pois além de necessitar de capacidade técnica, a licitante vencedora
deverá possuir capacidade financeira para suportar esse fornecimento. A quantidade total de
equipamentos prevista no projeto é de, no mínimo, 916 equipamentos/appliances. Portanto, entendemos
que a quantidade de experiência em fornecimento a ser exigida da licitante vencedora deve ser de
aproximadamente 92 equipamentos. Segue como sugestão. Um projeto deste tamanho, além do
fornecimento, exige a capacidade de substituição em caso de defeito e esta é a principal experiência que
deve ser cobrada, a nosso ver.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 19.2 O(s) contrato(s) terá(ão) vigência de até 12 (meses) meses, os quais poderão ser prorrogados até
60 (sessenta) meses, a contar da data de sua assinatura.
Manifestação: Considerando a garantia solicitada para todos os equipamentos, conforme objeto do
edital e item 12.4.3 do Termo de Referência, não entendemos qual será a necessidade de prorrogação da
vigência do contrato após os 12 (doze) meses.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Item 19.2 O(s) contrato(s) terá(ão) vigência de até 12 (meses) meses, os quais poderão ser prorrogados até
12 (doze) meses, a contar da data de sua assinatura. Destacando-se que a garantia da solução e a atualização
de firmwares e softwares deve ser de 60 meses contados a partir do termo de recebimento definitivo.
Manifestação: Considerando todo o Termo de Referência, e considerando que vigência do contrato será
de apenas 12 (doze) meses e a vigência da garantia será de 60(sessenta) meses, entendemos que há
necessidade de alteração em todo o Termo de Referência do texto “vigência do contrato” para “vigência
da garantia”, quando for o caso. Portanto, sugerimos tal alteração.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Sugestão 1:
Manifestação: Durante os testes de capacidade, sugerimos que sejam previstas verificações que
comprovem que as configurações realizadas na gerência centralizada estejam, de fato, habilitadas nos
firewalls (verificação de políticas instaladas, por exemplo).
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Sugestão 2:
Manifestação: Devido ao tamanho e complexidade, sugerimos que os equipamentos de Firewall
Multifuncional dos Lotes 3, 4 e 5 suportem e sejam compatíveis com as novas interfaces 40G, que são
tendência neste tipo de soluções e estão em iminência de serem amplamente adotadas, de forma similar
às interfaces 10G há alguns anos atrás.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Sugestão 3:
Manifestação: Nos itens de requisitos específicos dos lotes 4 e 5 (por exemplo, 3.31.1 e 3.24.1), não
explicitam quais extensões ou “tipos” de arquivos devem ser suportados para inspeção e emulação nas
funcionalidades de prevenção de ameaças (conhecidas e desconhecidas). Sugerimos então a inclusão de
um item que especifique os tipos de arquivos e suas extensões comuns, contendo, no mínimo, as
seguintes: Documentos do Pacote Office (.doc, .docx, .ppt, etc.), PDF, PIF, TGZ, SWF, RAR, RTF,
SCR e executáveis em geral (EXE).
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Sugestão 4:
Manifestação: Entendemos que, no item 2.1.47, são solicitadas diversas funcionalidades relacionadas à
Solução de Gerenciamento e, especificamente no item 2.1.47.1, é solicitado que todas as
funcionalidades sejam suportadas tanto via interfaces Gráficas (GUI), quanto interfaces de linha de
comando (CLI). Entretanto, existem funcionalidades que não são viáveis em alguns formatos
específicos de console de gerenciamento e, apesar de estarem presentes e serem suportadas, só são
disponibilizadas em uma console específica (seja ela linha de comando ou gráfica). Desta forma,
entendemos que o item 2.1.47.1 deve ter sua redação alterada para que possa permitir a ampla
participação de soluções que atendem integralmente ao solicitado no item 2.1.47 e seus subitens, porém
não simultaneamente nas duas interfaces. Redação sugerida: “2.1.47.1 Deverão ser providas interfaces
de gerenciamento, capazes de atender todas as funcionalidades gerenciais previstas nos subitens do item
2.1.47, através de interface gráfica (GUI) ou linha de comando (CLI).”
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Sugestão 5:
Manifestação: Entendemos que o item 2.1.47.15 deverá ter sua redação alterada: “Deverá suportar
gerência remota (via rede local ou WAN) ou por meio de sistemas centralizados externos, além da
gerência local, por meio de interface gráfica ou linha de comando ou via SSH, sendo que:”.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Sugestão 6:
Manifestação: Gostaria que analisassem a possibilidade de aumentar o valor estimado do edital,
considerando os preços enviados pelos principais players de mercado
Os riscos são:
- Estarem utilizando preços estimados de equipamentos que não possuem a mesma capacidade de
performance exigida nos testes de bancada;
- Estarem utilizando preços estimados de equipamentos de fabricantes que não atendem as
especificações técnicas nem de performance;
- Estarem utilizando preços estimados de processos que compraram grandes quantidades de
equipamentos vendidos de uma única vez. Pois quanto maior o volume numa única venda, melhores são
os descontos. Como não temos a previsibilidade das quantidades, não conseguimos ofertar nossos
melhores preços. Talvez fosse o caso está central especificar as quantidades de compras iniciais;
- Risco da administração pública não conseguir contratar dentro do orçamento de 173 milhões, tendo
que desclassificar várias empresas dentro do orçamento, mas fora das especificações e exigências.
- Evitar problemas semelhantes aos que estão sendo enfrentados em processo semelhante no de outros
órgãos. Erros no dimensionamento das propostas técnicas e desclassificações em massa.
Resposta: Não acatada. Não se justifica tecnicamente tal solicitação. A equipe técnica procurou
definir as especificações técnicas e condições de prestação do serviço de modo a manter um nível
elevado de competitividade entre os fornecedores.
Sugestão 7:
Manifestação: Considerando que o TR prevê a entrega de equipamentos importados em todos os estados
da federação e, considerando que as unidades que receberão esses equipamentos não são contribuintes
do ICMS, então, dependendo do estado de origem e do estado de destino, haverá a necessidade de
recolhimento de ICMS SUBSTITUIÇÃO TRIBUTÁRIA/ diferencial de alíquota no estado de destino.
Portanto, dependendo do estado da federação em que se encontrar cada licitante, esta poderá ser
beneficiada ou prejudicada com um custo adicional. Apenas como exemplo, se a licitante estiver
sediada em Brasília/DF e tiver que enviar os equipamentos para o estado do Rio de Janeiro, haverá a
necessidade de recolhimento de ICMS ST de 17%, adicionais ao recolhimento do ICMS interestadual
de 4%. Sendo assim, sugerimos que o MPOG faça a previsão do reflexo desse diferencial de alíquota no
momento dos lances, igualando as condições a todos os licitantes. Para que a competição seja justa, a
sugestão é que o valor do lance a ser considerado seja apenas com a alíquota interestadual e que no
fechamento da proposta final, após a decisão do vencedor, seja incluído o diferencial de alíquota por
estado, ficando claro que para aquele licitante vencedor e para cada estado de destino será incluído o
valor relativo ao diferencial de alíquota, se houver. Basta verificar no exemplo que do DF para RJ, serão
17% a mais. Já de outro estado de origem, pode não haver este diferencial e a licitante vencedora neste
caso estará sendo beneficiada.
Resposta: Não acatada. Não é viável a APF ficar administrando alíquota de ICMS diferenciada
nos Estados em que estão sediadas as empresas. Cada CONTRATANTE tem que cotar olhando a
sua própria realidade do estado onde está sediado.
Sugestão 8:
Manifestação: Na tabela de LOTES no item 1.1, os itens 2 a 5 de cada lote tratam de funcionalidades de
segurança distintas. Considerando que diversas soluções existentes no mercado possuem uma forma de
comercialização em que são incluídas em uma mesma licença todas as funcionalidades exigidas nos
itens 2 a 5, comumente chamadas de BUNDLE, e que por conta disto, ficam mais baratas do que a soma
das licenças adquiridas separadamente, sugerimos a inclusão de um item, em cada lote, em que as
licitantes possam cotar o preço de uma licença que contenha todas as funcionalidades solicitadas nos
itens 2 a 5. Esta opção de uma licença agrupando todas as funcionalidades será mais barata que a soma
de todas elas em separado. Caso algum órgão deseje comprar apenas uma das funcionalidades, terá a
opção de escolher, da forma como está dividido hoje.
Resposta: Não acatada. Os descontos devem ser calculados por item considerando os volumes
totais estimados de contratação. Não haverá tratamento para combinações.
Sugestão 9:
Manifestação: Considerando que os equipamentos do item 1 de cada LOTE serão entregues e instalados
independentemente se as funcionalidades dos itens 2 a 5 tenham sido adquiridas, entendemos que o
aceite definitivo dos equipamentos (item 1) se dará independentemente do aceite dos demais itens (2 a
5). Está correto o entendimento?
Resposta: O entendimento está incorreto. O aceite definitivo será dado de forma única para todos
os itens que compõem o lote.
Sugestão 10:
Manifestação: Solicitamos sua análise para que o local de realização dos testes de bancada seja isento
neutro e de controle do MPOG.
Resposta: Parcialmente acatada. O item foi reformulado na nova versão do TR.
Sugestão 11:
Manifestação: A troca de qualquer unidade defeituosa deverá ser realizada em conformidade com os
prazos estabelecidos abaixo.
24x7x4 para as Capitais: Brasília, Rio de Janeiro e São Paulo: Vinte e quatro horas por dia, sete dias por
semana. Entrega na localidade da contratante em até 4 horas do momento em que se diagnosticou, no
chamado, a necessidade de troca. O tempo de entrega do equipamento para troca começa a ser contado
do momento em que se diagnosticou, no chamado, a necessidade de troca.
8x5xNBD para as demais Capitais e regiões metropolitanas: Oito horas por dia, cinco dias por semana,
com entrega no próximo dia útil, para chamados abertos até as 14:00h (horário local). Após as 14:00h
(horário local) o chamado passa a ser contado para o dia útil subsequente ao próximo (2-business-days).
O tempo de entrega do equipamento para troca começa a ser contado do momento em que se
diagnosticou, no chamado, a necessidade de troca.
8x5x3BD para as demais regiões (não metropolitanas): Oito horas por dia, cinco dias por semana, com
entrega até três dias úteis, para chamados abertos até as 14:00h (horário local). Após as 14:00h (horário
local) o chamado passa a ser contado para o dia útil subsequente ao próximo (4-business-days). O
tempo de entrega do equipamento para troca começa a ser contado do momento em que se diagnosticou,
no chamado, a necessidade de troca.
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Sugestão 12:
Manifestação: Em relação ao Item 2.2 Solução de gerência centralizada do Termo de Referência: Por se
trata de uma Ata de Registro de Preços, entendemos que o componente de gerência poderá ser
desvinculado dos Lotes de fornecimento de Firewall multifuncional devido as suas múltiplas
possibilidades de fornecimento e de licenciamento que variam, sobretudo, de acordo com a quantidade
de firewalls a serem gerenciados. Dessa forma, quanto for conveniente a cada órgão e/ou entidade
pública a contratação imediata dos Lotes desejados terão também a flexibilidade de escolher a
plataforma de gerência que melhor se encaixar as necessidades de sua infraestrutura. Estando de acordo
com esse entendimento, seria possível a criação de novos Lotes para gerência, de acordo com a
quantidade de elementos gerenciados?
Resposta: Não acatada. A especificação desse item foi definida tendo em vista as necessidades dos
órgãos participantes.
Top Related