Anatel

Agência Nacional de Telecomunicações - ANATEL

Sistema de Acompanhamento de Consulta Pública - SACP

Relatório de Contribuições Recebidas

 Data: 14/08/2022 07:32:11
 Total de Contribuições:141

CONSULTA PÚBLICA Nº 13


 Item:  MINUTA DE ATO
Contribuição N°: 1
ID da Contribuição: 92568
Autor da Contribuição: LUIZ GUSTAVO DE MORAIS
Data da Contribuição: 14/05/2020 12:17:16
Contribuição:

Sugestões referentes ao Art 2:

Art. 2º Este Ato entra em vigor 180 (cento e oitenta) 365 (trezentos e sessenta e cinco) dias após a data de sua publicação no Boletim de Serviços Eletrônico da Anatel para Novas Famílias de produtos homologados. Para as Famílias de produtos com certificados de homologação validos, este Ato entra em vigor no processo de renovação do certificado, quando houver modificações no produto, 730 (setecentos e trinta) dias apos a data de sua publicação no Boletim de Serviços Eletrônico da Anatel.

Justificativa:

Propõe-se  uma abordagem semelhante a adotada pelo DENATRAN, já que os produtos cobertos por essa regulamentação podem estar inseridos dentro dos veículos, onde as novas regulamentações permitem um prazo diferenciado entre as Novas Famílias de produtos (novos produtos ainda sem uma homologação vigente) e as Famílias de produtos existentes (produtos existentes que possuem certificados validos e que serão submetidos a processos de renovação de certificados no futuro).

Esta contribuição objetiva proporcionar um prazo de adequação minimamente adequado para modificações de produto aos novos requisitos, cobrindo todo o ciclo de alteração de produtos embarcados em veículos (projeto, aprovação, desenvolvimento, validação, liberação, implementação, logística e efetivação da modificação nas linhas de produção do fornecedor e montagem final).

Entende-se que os produtos com certificados de homologação validos e que não tenham sofrido modificações, conforme definições em Procedimento Operacional especifico, não serão submetidos aos requisitos deste Ato, uma vez tratarem-se de produtos que não possuem recursos alocados para modificações, muitas vezes não estarem sendo aplicados em produtos sendo comercializados mas sim fornecimento para reposição (atendendo prazo legal de fornecimento após produto sair de linha de produção).

Contribuição N°: 2
ID da Contribuição: 92610
Autor da Contribuição: MICHELLE MACHADO CALDEIRA
Data da Contribuição: 15/05/2020 17:13:36
Contribuição:

No contexto de Consulta Pública promovida por esta r. ANATEL, por meio de sua Superintendência de Outorga e Recursos à Prestação (“SOR”), relacionada a requisitos mínimos de segurança cibernética para equipamentos terminais que se conectem à Internet e para equipamentos de infraestrutura de redes de telecomunicações, a SES TELECOMUNICAÇÕES DO BRASIL LTDA., (doravante apenas “SES”), vem manifestar-se da forma que segue.

 

Inicialmente, a SES expressa sua concordância com o diagnóstico de que a expansão do uso de tecnologias da informação e comunicação (TICs), com a massificação do acesso à Internet, resulta no incremento de ameaças cibernéticas, o que requer a adoção de medidas por todos os stakeholders e agentes envolvidos neste ecossistema, cabendo ao Poder Público coordenar tais ações, na linha recentemente proposta na Estratégia Nacional de Segurança Cibernética (“E-Ciber”), aprovada pelo Decreto n.º 10.222/2020.

 

Nesse sentido, reconhecendo a relevância do tema, a SES pondera que qualquer abordagem regulatória sobre a questão deve partir do reconhecimento da dinamicidade dos mercados em questão e da complexidade das tecnologias envolvidas, sendo essencial, por este motivo, que as normas relacionadas à segurança cibernética tenham, sempre que possível, um caráter geral e principiológico, na mesma linha adotada, por exemplo, com relação ao Marco Civil da Internet (Lei n.º 12.965/2014) e à Lei Geral de Proteção de Dados Pessoais (Lei n.º 13.709/2018), de maneira a evitar restrições e entraves ao desenvolvimento tecnológico e à inovação. Sobre o tema, o i. Conselheiro Moisés Queiroz Moreira, ao analisar proposta de regulamentação de segurança cibernética aplicável a serviços de telecomunicações, já ponderou que “o estabelecimento de requisitos técnicos em regulamentos ou instrumentos de rigidez similar não é a abordagem mais adequada”.[1]

 

Mais do que permitir convivência harmoniosa do direito e da tecnologia, e a observância de princípios estabelecidos na legislação em vigor que buscam incentivar a inovação e o desenvolvimento do mercado de tecnologia no país, a regulamentação sobre segurança cibernética não pode perder de vista que a confiabilidade dos equipamentos, serviços e aplicações é cada vez mais uma demanda do consumidor, motivo pelo qual o próprio mercado têm incentivos para adotar melhores práticas visando garanti-la em seus produtos e serviços ofertados.

 

É nessa linha, por exemplo, que se vê com certa preocupação a proposta ora em Consulta Pública, na tentativa de padronizar requisitos mínimos de segurança cibernética, sem, no entanto, abrir uma porta para eventuais flexibilizações à vista de especificidades dos equipamentos envolvidos.

 

Chama-se a atenção, em particular, à obrigação estabelecida no subitem 6.1.6 (“[d]isponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa [...]”), que na forma proposta parece alcançar todos “[o]s fornecedores de equipamentos terminais que se conectam à Internet e de equipamentos de infraestrutura de redes de telecomunicações” (cf. item 6.1).

 

A ratio de referida obrigação encontra-se exposta no Informe que serve de motivação à Consulta Pública. Nele, a SOR anota que “[o] Anexo 6.1 apresenta uma proposta de requisitos mínimos de segurança cibernética para manutenção da homologação de terminais que se conectam à Internet e para equipamentos de infraestrutura de redes de telecomunicações. A aplicação de cada requisito contido na proposta deve levar em consideração as diferentes características técnicas (quantidade de memória, capacidade de processamento de dados, interfaces para usuário, interfaces de comunicação, etc.) de cada equipamento e os fins a que se destinam”.

 

Da forma como consta da proposta em discussão, a obrigação estabelecida no subitem 6.1.6 impõe onerosidade excessiva no caso de operações em escala global, que não tenham por alvo o mercado brasileiro. Em que pese a relevante finalidade por detrás da norma proposta, fato é que a preocupação do regulador poderia ser endereçada por outros meios menos onerosos e igualmente eficazes, a exemplo da obrigação de fornecimento de manuais em língua portuguesa.

 

Como consignado na recém editada Declaração de Direitos de Liberdade Econômica (Lei n.º 13.784/2019), não deve o Estado regulador agir de maneira a impedir ou retardar “a inovação e a adoção de novas tecnologias, processos ou modelos de negócios” (cf. artigo 4º, IV), motivo pelo qual a intervenção regulatória ex-ante não deve servir para criação de estrutura de desincentivo a investimentos no mercado nacional.

 

Além disso, a SES vê com alguma preocupação o risco de pulverização e de fragmentação das normas jurídicas voltadas à segurança cibernética, o que pode levar à insegurança jurídica para realização de investimentos no setor.

 

No âmbito da já referida E-Ciber, ponderou-se sobre “a falta de um alinhamento normativo, estratégico e operacional, o que frequentemente gera retrabalho ou resulta na constituição de forças-tarefas para ações pontuais, que prejudicam a absorção de lições aprendidas e colocam em risco a eficácia prolongada dessas ações”. Nesse aspecto, chama-se a atenção ao fato de o Gabinete de Segurança Institucional da Presidência da República (GSI), órgão responsável pelo planejamento, coordenação e supervisão da segurança cibernética no âmbito da administração pública federal, ter recentemente editado diretrizes com relação à segurança das redes 5G (Instrução Normativa GSI n.º 4/2020), estabelecendo princípios específicos a serem observados na prestação de serviços de telecomunicações.

 

Trata-se, para todos os efeitos, de uma sobreposição de atos normativos que não foi considerada pela r. ANATEL na elaboração da proposta ora submetida a Consulta Pública, circunstância esta que deveria ser objeto de nova reflexão pela Agência, inclusive para avaliar a conveniência e oportunidade do ato que se pretende editar.

 

Sendo o que nos cumpria para o momento, a SES renova seus votos de elevada estima e consideração.

 

 


[1] Item 4.69. da Análise n.º 31/2020/MM, disponibilizada nos autos do Processo SEI nº 53500.078752/2017-68.

Justificativa:

Vide contribuição.

Contribuição N°: 3
ID da Contribuição: 92611
Autor da Contribuição: Gilberto Martins de Almeida Filho
Data da Contribuição: 15/05/2020 17:14:53
Contribuição:

Alterar o Art. 1º e 2º

I - "Art. 1º Aprovar os requisitos e recomendações mínimas os de segurança cibernética para equipamentos para telecomunicações, nos moldes do Anexo a este Ato."

II - "Art. 2º Este Ato entra em vigor 180 (cento e oitenta) 365 (trezentos e sessenta e cinco) dias após a data de sua publicação no Boletim de Serviços Eletrônico da Anatel "

Justificativa:

I - Conforme referências apresentadas nesta Consulta Pública, não há registro de agências de telecomunicações internacionais que implementaram tais requisitos de segurança, mas sim, recomendações de organismos internacionais de telecomunicações.

II - Sugere-se seguir uma abordagem semelhante a adotada pelo DENATRAN, onde as novas regulamentações permitem um prazo diferenciado entre as Novas Famílias de produtos (novos produtos ainda sem uma homologação vigente) e as Famílias de produtos existentes (produtos existentes que possuem certificados validos e que serão submetidos a processos de renovação de certificados no futuro).
Esta contribuição objetiva proporcionar um prazo de adequação razoável para modificações de produto aos novos requisitos, cobrindo todo o ciclo de alteração do produto (projeto, aprovação, desenvolvimento, validação, liberação, implementação, logística e efetivação da modificação nas linhas de produção do fornecedor e montagem final).

Contribuição N°: 4
ID da Contribuição: 92631
Autor da Contribuição: Mariana Giostri M. Oliveira
Data da Contribuição: 15/05/2020 18:57:47
Contribuição:

COMENTÁRIOS À CONSULTA PÚBLICA No 13 REFERENTE AOS REQUISITOS MÍNIMOS DE SEGURANÇA PARA EQUIPAMENTOS DE TELECOMUNICAÇÕES DA ANATEL

 

Maio de 2020

Justificativa:

A Brasscom, Associação Brasileira das Empresas de Tecnologia da Informação e Comunicação (TIC), entidade que congrega empresas fornecedoras de software, soluções e serviços de TIC e que tem como missão trabalhar em prol do desenvolvimento do setor, disseminando seu alcance e potencializando seus efeitos sobre a economia e o bem-estar social, parabeniza a ANATEL pela iniciativa de submeter à Consulta Pública a minuta de ato sobre requisitos mínimos de segurança para equipamentos de telecomunicações.

A garantia da segurança cibernética de um país está no cerne das medidas estruturantes que geram vantagens competitivas para incentivar a inovação e o desenvolvimento tecnológico de forma sustentável e crescente e é neste cenário que o Brasil necessita inserir-se.

Para promover abordagens de security by design and default é fundamental que se respeite a natureza de tais conceitos, ou seja, a preocupação de segurança como conceito estruturante do próprio desenvolvimento do produto e/ou serviço, evitando-se regimes de padronização e certificação prescritivos para a cibersegurança. Certificações e padronizações obrigatórias de segurança para o mercado podem inadvertidamente encorajar as empresas a investir apenas no cumprimento de padrões ou práticas estáticas definidas em norma ou processo determinado de certificação e que podem – em virtude da dinamicidade do setor de tecnologia – ficar desatualizadas em breves espaços de tempo.

Preocupa o olhar da regulamentação no sentido de certificar todo e qualquer equipamento utilizado pelo ecossistema com vistas específicas ao cumprimento de premissas de segurança cibernética na medida em que nessa temática, o objetivo é se ter um ecossistema seguro como um todo, não sendo a consideração da segurança de cada elemento desse conjunto de maneira individual a melhor maneira de se garantir a segurança cibernética sistêmica.

Uma abordagem de gerenciamento de risco equilibrada é essencial, honrando e encorajando os atores que já estão envolvidos com as melhores práticas adotadas pelo mercado para segurança, focando na construção de conhecimento e encorajando as melhores práticas para os atores que ainda estão evoluindo neste tema em suas organizações. Nesse sentido, a Brasscom defende ser fundamental que discussões relacionadas a requisitos mínimos de segurança, e à gestão de riscos relacionados à cibersegurança, são melhor endereçadas por meio de padrões flexíveis, globais, induzidos pelas relações de mercado e fomentados pela indústria, justamente pela sua natureza consensual e baseada nas melhores práticas.

Ademais, é importante ressaltar que existem diversas variáveis que podem direta ou indiretamente afetar os requisitos mínimos necessários. Por exemplo, o tipo de equipamento e seus recursos, a finalidade de uso e o contexto no qual ele será implementado podem exigir requisitos mínimos diferentes, dependendo de uma vulnerabilidade específica, complexidade de um equipamento específico em toda a rede, capacidade da própria rede de fornecer determinadas proteções de segurança cibernética. Ou seja, entendemos que as discussões sejam norteadas pelo princípio de que abordagens prescritivas de “tamanho único” não necessariamente serão eficazes em endereçar todas as questões atreladas à temática de segurança cibernética.

Nesse sentido, sugerimos que a Agência segmente a edição de regulamentação específica sobre requisitos mínimos de segurança cibernética de modo a respeitar as características distintas de grupos de elementos de rede e dispositivos a ela conectados, para o objetivo maior da segurança seja atingido, sem a imposição de um ônus regulatório e de custo desnecessário e desproporcional a certos dispositivos cuja função e papel na rede é, na prática, de menor complexidade.

Sendo assim, a Brasscom agradece novamente a oportunidade de apresentar comentários à consulta pública e, abaixo, apresenta considerações específicas aos itens de discussão, bem como algumas alterações na minuta de ato, a fim de refletir a abordagem sobre o tema que mencionamos acima:

Contribuição N°: 5
ID da Contribuição: 92639
Autor da Contribuição: Mariana Giostri M. Oliveira
Data da Contribuição: 15/05/2020 19:13:22
Contribuição:

Art. 2º Este Ato entra em vigor 365 (trezentos e sessenta e cinco) 180 (cento e oitenta) dias após a data de sua publicação no Boletim de Serviços Eletrônico da Anatel.

Justificativa:

A Brasscom convida a Anatel a revisar o prazo de entrada em vigor do ato, e alterá-lo para 365 dias, para que as fabricantes de equipamentos possam adotar todas medidas necessárias para estarem em conformidade com o ato. Além disso, sugere que esses requisitos mínimos sejam discutidos recorrentemente, em parceria com a indústria, para garantir que estejam em consonância com as melhores práticas globais, a evolução tecnológica e o estado da arte.

Contribuição N°: 6
ID da Contribuição: 92641
Autor da Contribuição: LUCIMARA DESIDERA
Data da Contribuição: 15/05/2020 19:45:40
Contribuição:

Incluir consideração à Lei 13.709 de 14 de agosto de 2018 - Lei Geral de Proteção de Dados Pessoais.

Justificativa:

Necessidade de adotar medidas de segurança e privacidade desde a concepção dos produtos.

 

Contribuição N°: 7
ID da Contribuição: 92652
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:06:36
Contribuição:

Esta contribuição esta sendo realizada em nome da ABRAC - Associação Brasileira de Avaliação da Conformidade

Justificativa:

Não foi possivel vincular esse perfil a entidade ABRAC, não conseguimos cadastrar a associação, por gentileza considerar as contribuições abaixo como sendo da Associação ABRAC

Contribuição N°: 8
ID da Contribuição: 92681
Autor da Contribuição: Karla Menandro Pacheco da Silva
Data da Contribuição: 17/05/2020 10:13:14
Contribuição:

Art. 2º Este Ato entra em vigor 24 (vinte e quatro) meses após a data de sua publicação no Boletim de Serviços Eletrônico da Anatel para novas famílias e 48 (quarenta e oito) meses após a data de sua publicação no Boletim de Serviços Eletrônico da Anatel para famílias existentes.   

Justificativa:

Sugere-se seguir uma abordagem semelhante a adotada pelo DENATRAN, onde as novas regulamentações permitem um prazo diferenciado entre as Novas Famílias de produtos (novos produtos ainda sem uma homologação vigente) e as Famílias de produtos existentes (produtos existentes que possuem certificados validos e que serão submetidos a processos de renovação de certificados no futuro).
Esta contribuição objetiva proporcionar um prazo de adequação razoável para modificações de produto aos novos requisitos, cobrindo todo o ciclo de alteração do produto (projeto, aprovação, desenvolvimento, validação, liberação, implementação, logística e efetivação da modificação nas linhas de produção do fornecedor e montagem final). 

Contribuição N°: 9
ID da Contribuição: 92704
Autor da Contribuição: Sergio Mauro da Silva Maia
Data da Contribuição: 17/05/2020 20:10:26
Contribuição:

A Hughes Telecomunicações do Brasil Ltda (Hughes), empresa autorizada a prestar o Serviço de Comunicação Multimídia (SCM) desde 2003 através do ATO N.º 32.895/2003, emitido pela Agência Nacional de Telecomunicações (ANATEL), apoia a iniciativa da Agência em convidar à Sociedade civil e empresas da Indústria Brasileira de Telecomunicações a participarem desta Consulta Pública (CP 13) referente à aprovação dos  requisitos mínimos de segurança cibernética para equipamentos de telecomunicações.

Contribuição: Sugerir que o texto desta Consulta Pública contemple apenas os produtos fabricados após 2019, ano em que foi publicado o documento de diretiva LAC-BCOP-1 emitido por LACNOG.

Contribuição: Discordamos. Este prazo de  180 dias é um período muito curto para a    adaptação a vários dos itens propostos por esta CP,sugerimos o período de 1 ano. Além disso, as exceções devem ser consideradas, com base em justificativa plausível , para prorrogações adicionais.

Justificativa:

Justificativa:  Para os produtos comercializados antes de 2019 e ainda em operação, os novos requisitos propostos por esta Consulta Pública poderiam acarretar a substituição compulsória de parte signigficativa do parque instalado, gerando prejuízo financeiro para as prestadoras, acarretando um desequilibrio financeiro nos contratos vigentes em função deste custo. O direito já adquirido  nessas situações é apropriado.

Justificativa : As empresas que possuem equipamentos certificados pela Anatel provenientes de diversos fabricantes, poderão ser prejudicadas caso estes não se   adaptem às  mudanças propostas   neste prazo  de 180 dias.   O prazo de um ano nos parece um período razoável para o atendimento à este requisitos.

 Item:  ANEXO

REQUISITOS MÍNIMOS DE SEGURANÇA CIBERNÉTICA PARA EQUIPAMENTO DE TELECOMUNICAÇÕES

Contribuição N°: 10
ID da Contribuição: 92653
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:06:36
Contribuição:

 

CONTRIBUIÇÃO DA ABRAC  CT-TELECOM

 

14/05/2020

 

CONSULTA PÚBLICA Nº 13 - MINUTA DE ATO
 

 

O SUPERINTENDENTE DE OUTORGA E RECURSOS À PRESTAÇÃO - ANATEL, no uso das
atribuições que lhe foram conferidas pela Resolução n.º 715, de 23 de outubro de 2019, e CONSIDERANDO a competência dada pelos Incisos XIII e XIV do Art. 19 da Lei n.º 9.472/97 – Lei Geral de Telecomunicações;
CONSIDERANDO o Art. 22 do Regulamento para Avaliação da Conformidade e Homologação de Produtos para Telecomunicações, aprovado pela Resolução n.º 715, de 23 de outubro de 2019;
CONSIDERANDO a Estratégia Nacional de Segurança Cibernética, aprovada por meio do Decreto nº
10.222, de 5 de fevereiro de 2020; e
CONSIDERANDO o constante dos autos do processo nº 53500.026122/2019-70,
RESOLVE:

 

Art. 1º Aprovar os requisitos mínimos de segurança cibernética para equipamentos para telecomunicações, nos moldes do Anexo a este Ato.

 

Art. 2º Este Ato entra em vigor 180 (cento e oitenta) dias após a data de sua publicação no Boletim de
Serviços Eletrônico da Anatel.
 

 

ANEXO
REQUISITOS MÍNIMOS DE SEGURANÇA CIBERNÉTICA PARA EQUIPAMENTO DE TELECOMUNICAÇÕES
 

 

1. OBJETIVO
1.1.Estabelecer requisitos mínimos de segurança cibernética para equipamentos terminais que se
conectam à Internet e para equipamentos de infraestrutura de redes de telecomunicações, visando
minimizar vulnerabilidades por meio de atualizações de software/firmware ou por meio de recomendações em configurações e em seus mecanismos de gerenciamento remoto.

 

1.2. Atender aos requisitos de segurança cibernetica para os produtos do item 1.1 contidos na Instrução Normativa Nº 4, DE 26 DE MARÇO DE 2020 do GSI.  

 

 

 

Justificativa – incluir item 1,2,  -  Considerando que a Instrução Nortativa 5 da GSI foi publicada apos a CP13 entende,ps que e importante a sua referencia e atendimento.

 


2. REFERÊNCIAS
2.1.Regulamento de Avaliação da Conformidade e de Homologação de Produtos para Telecomunicações,
aprovado pela Resolução n.º 715, de 23 de outubro de 2019.
2.2.OECD - Enhancing the Digital Security of Products - Draft Scoping Paper (November 2019).
2.3.IEEE Internet Technology Policy Community White Paper - Internet of Things (IoT) Security Best
Practices (February 2017).
2.4.IETF - Internet of Things (IoT) Security: State of the Art and Challenges - RFC 8576.
2.5.LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.
2.6.ENISA - Baseline Security Recommendations for IoT in the Context of Critical Information
Infrastructures (November 2017).
2.7.GSMA IoT Security Guidelines – Complete Document Set.

 

Justificativa – Incluir a referencia publicada após a consulta e utilizada na contribuição

 

2.8. Instrução Normativa número 4 de 26/03/2020 - Gabinete de Segurança Institucional

 


3. DEFINIÇÕES
3.1.Backdoor: mecanismo não documentado contido no software/firmware do produto que possibilita
acesso não autorizado ao equipamento. A presença de backdoors pode ser intencional ou acidental,
podendo ser decorrente de erros de programação.
3.2.Customer Premise Equipment (CPE): equipamento utilizado para conectar assinantes à rede do
provedor de serviços de telecomunicações.
3.3.Firmware: software ou conjunto de softwares programados em um hardware de propósito específico e
que fornecem controle de baixo nível.
3.4.Hashing: algoritmo matemático que mapeia dados de comprimento variável na entrada de uma função
para um conjunto de dados de comprimento fixo na saída da função. O resultado da função hash possui
muito pouca correlação com os dados de entrada da função, impossibilitando a obtenção do valor inicial de entrada a partir do resultado da operação da função.
3.5.Métodos adequados de criptografia, autenticação e integridade: protocolos ou algoritmos de
criptografia, autenticação e integridade, em suas versões atualizadas. A implementação deve permitir a
seleção de conjuntos de criptografia e tamanhos de chave atualizados.
 

 

4. REQUISITOS GERAIS
4.1.O interessado na homologação deve demonstrar conformidade do produto por meio de declaração
afirmando:
a) que o equipamento e seu fornecedor atendem os requisitos contidos neste documento; e
b) estar ciente que este documento está sujeito a atualizações.
4.2.O escopo da declaração de conformidade deve considerar as diferentes características técnicas dos
equipamentos (quantidade de memória, capacidade de processamento de dados, interfaces do usuário,
interfaces de comunicação, etc.) e os fins a que se destinam, apontando quais requisitos são atendidos.
4.2.1.Para produtos enquadrados na definição de CPE, a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência 2.5.
4.3.Nas atividades de supervisão de mercado, a Agência poderá avaliar os requisitos contidos neste
documento por meio de procedimentos de ensaios orientados pelas melhores práticas, padronizadas
internacionalmente, para avaliação de vulnerabilidades.

 

(Acréscimo de novo item – Justificativa: Dada a complexidade da avaliação das características relativas a Ciber Security em conjunto com  a necessidade de ser uma ação preventiva anterior a homologação do produto, é primordial a OCD e laboratório como agentes para dar o devido dinamismo ao processo sem comprometimento temporal da disponibilização das soluções.)

 

4.x. Nas atividades de avaliação da conformidade referente a declaração do solicitante  e da validação de relatórios de ensaios  de produtos para telecomunicações e segurança cibernética  devem ser usados os Organismos de Certificação  Designados – OCD e os Laboratórios de Ensaio tecnicamente capacitados e devidamente habilitados. Acrescentando qualificação para as atividades de segurança cibernética - Art. 6º Resolução 715

 


4.4.Identificada, no produto homologado, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência notificará o responsável pela homologação a sana-la, indicando prazo
adequado para esse fim, considerando-se o grau de risco da vulnerabilidade.
4.4.1.Decorrido o prazo sem que se verifique as adaptações necessárias ou a justificativa aceita pela Anatel para sua não implementação, a Agência suspenderá a homologação do produto, podendo indicar o
recolhimento ou substituição do mesmo no mercado, garantidas as demais previsões regulamentares
referentes ao direito do consumidor.
4.4.2.A suspensão da homologação do equipamento será mantida até que as vulnerabilidades apontadas
sejam sanadas ou até que o potencial risco à segurança dos serviços para telecomunicações seja mitigado,
considerando-se o prazo máximo estabelecido na regulamentação vigente.
4.4.3.Após o prazo máximo determinado para sua suspensão, a homologação será cancelada, caso a
vulnerabilidade não seja solucionada.
 

 

5. REQUISITOS DE SEGURANÇA CIBERNÉTICA DOS EQUIPAMENTOS PARA
TELECOMUNICAÇÕES
5.1.Equipamentos terminais que se conectam à Internet e equipamentos de infraestrutura de redes de
telecomunicações, em suas versões finais destinadas à comercialização, devem:
5.1.1.Quanto à atualização de software/firmware:
a) Possuir mecanismos periódicos, seguros e automatizados para atualização de software/firmware que
empregam métodos adequados de criptografia, autenticação e integridade.
b) Permitir que os usuários verifiquem, de forma não automatizada, a disponibilidade de atualizações de
software/firmware.

 

((Acréscimo de novas alíneas Justificativa: Funcionalidades relevantes referente a atualização)

 

c) Possuir mecanismos para identificar se o software/firmware foi atualizado de acordo com as recomendações do fabricante, evitando atualização que possam incluir backdoors

 

d) Possuir mecanismos para permitir retornar as configurações anteriores em caso de detecção de não conformidade com as configurações do fabricante.

 

e) Possuir mecanismos de informar notificações sobre alterações de segurança devido às atualizações.

 

f) Se identificado uma vulnerabilidade no software/firmware garantir que o equipamento seja atualizado.

 

g) Possuir os mesmos mecanismos de segurança para softwares/firmwares em modelo Beta ou versão não final.

 


5.1.2.Quanto à instalação e à operação:
a) Implementar rotinas simplificadas para sua instalação e configuração, evitando potenciais falhas de
segurança não intencionais.
b) Realizar verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade.
c) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando
o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado.

 

d) Implementar ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários,
alteração de configurações do sistema e funcionamento do sistema.
e) Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as
funcionalidades do software/firmware e/ou sistema operacional utilizado.

 

(Acréscimo de novas alíneas – Justificativa: acréscimo de funcionalidades consideradas relevantes)

 

f) Realizar verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade e em caso de versões beta e versões não final, alertar sobre o modelo atual.

 

g) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado e permitindo o usuário a escolha de uma inicialização com os parâmetros de segurança de fábrica.

 

h) Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado e também as release Betas ou versões não finais.

 

i) Permitir rastrear todo o tráfego da rede e realizar o controle de acessos para que pessoas má intencionadas não tenham acesso a dados confidencias  (acesso baseada em confiança zero),

 

j) Permitir a re-autenticação do dispositivo quando ele se mover entre diferentes redes de acesso, com a implementação do SEAF ( SECURITY ANCHOR FUNCTION).

 

l) Permitir a utilização de identificação oculta até que o equipamento que faz acesso a rede seja autenticado, garantindo que depois dessa operação seja divulgada a identificação do usuário

 


5.1.3.Quanto ao acesso ao equipamento:
a) Não utilizar credenciais e senhas iniciais para acesso às suas configurações que sejam iguais entre todos os dispositivos produzidos.
b) Não utilizar senhas que sejam derivadas de informações de fácil obtenção por métodos de
escaneamento de tráfego de dados em rede, tal com endereços MAC - Media Access Control.
c) Forçar, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.
d) Não permitir o uso de senhas em branco ou senhas fracas.
e) Possuir mecanismos de defesa contra tentativas exaustivas de acesso não autorizado (ataques de
autenticação por força bruta).
f) Garantir que os mecanismos de recuperação de senha sejam robustos contra tentativas de roubo de
credenciais.
g) Não utilizar credenciais e senhas definidas no próprio código fonte do software/firmware e que não
podem ser alteradas (hard-coded).
h) Proteger senhas, chaves de acesso e credenciais armazenadas ou transmitidas utilizando métodos
adequados de criptografia ou hashing.

 

(Acréscimo de nova alínea – Justificativa: Para enfatizar que são características para todas versões)

 

i) Garantir todos os itens mencionados acima para qualquer versão de software/firmware (beta e versões não final) 

 

5.1.4.Quanto às interfaces/portas de comunicação:
a) Estar desprovido de qualquer ferramenta de teste ou backdoor intencional utilizados nos processos de
desenvolvimento do produto e desnecessários à sua operação usual.
b) Estar desprovido de qualquer forma de comunicação intencional não documentada, incluindo aquelas
para envio de informações de perfil de uso do equipamento para fabricantes ou para terceiros.
c) Ser fornecidos com serviços de transmissão de dados (portas de comunicação) não essenciais
desabilitados, reduzindo sua superfície de ataque.
d) Facultar ao usuário a possibilidade de desabilitar funcionalidades, serviços e portas de comunicação não essenciais à operação ou ao gerenciamento do equipamento.

 


5.1.5.Quanto aos dados sensíveis e informações pessoais:
a) Possibilitar a utilização de métodos adequados de criptografia para transmissão e armazenamento de
dados sensíveis, incluindo informações pessoais.
b) Permitir que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o
descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais.

 


5.1.6.Quanto à capacidade de mitigar ataques:
a) Possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do
usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos
ou sistemas (ataque de negação de serviço).
b) Ser projetados para mitigar os efeitos de ataques de negação de serviço em andamento, sendo
resistentes a um número excessivo de tentativas de autenticação, por meio de, por exemplo: priorização
de sua capacidade de processamento às sessões de comunicação já estabelecidas e autenticadas; e
limitação do número de sessões de autenticação concorrentes, descartando tentativas de estabelecimento
de novas sessões quando superado limite estabelecido.
 

 

6. REQUISITOS PARA FORNECEDORES DE EQUIPAMENTOS PARA TELECOMUNICAÇÕES
6.1.Os fornecedores de equipamentos terminais que se conectam à Internet e de equipamentos de
infraestrutura de redes de telecomunicações, devem:
6.1.1.Ter uma política clara de suporte ao produto, especialmente em relação à disponibilização de
atualizações de software/firmware para correção de vulnerabilidades de segurança.
6.1.2.Deixar claro para o consumidor até quando serão providas atualizações de segurança para o
equipamento e com que frequência ocorrerão.
6.1.3.Garantir que os processos de atualização automática de software/firmware sejam realizadas em fases
a fim de evitar que erros não intencionais da nova versão de software/firmware sejam distribuídos a todos
os equipamentos sob atualização de uma só vez.
6.1.4.Prover atualizações de segurança por, no mínimo, 2 (dois) anos após o lançamento do produto ou
enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que
mais se estender.
6.1.5.Disponibilizar um canal de comunicação que possibilite aos seus clientes, usuários finais e terceiros
reportarem vulnerabilidades de segurança identificadas nos produtos.
6.1.6.Disponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa, 
para:
a) Informar sobre novas vulnerabilidades identificadas em seus produtos, medidas de mitigação e
correções de segurança associadas;
b) Manter histórico de: vulnerabilidades identificadas, medidas de mitigação e correções de segurança;
c) Permitir acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos;
e
d) Fornecer manuais e outros materiais com orientações relativas à configuração, atualização e uso seguro
dos equipamentos.

 

(Acréscimo de novo item. Justificativa: impedir que versões ultrapassadas estejam em uso)

 

6.1.7 Garantir que a versão Beta ou versão não final do software/firmware deixe de funcionar após o lançamento da versão oficial.

 

(Acréscimo de um novo item 7.  Justificativa: Adequação do texto da consulta à Instrução Normativa 4)

 

7.x, REQUISITOS RETIRADOS DA Instrução Normativa número 4 - Segurança Cibernética QUE DEVEM SER ADOTADOS PARA OS EQUIPAMENTOS UTILIZADOS NAS REDES 5G.

 

7.1. Garantir que os serviços prestados e os equipamentos utilizados cumpram os protocolos de comunicação e as especificações técnicas de infraestrutura reconhecidos pela Agência Nacional de Telecomunicações ou, na sua ausência, aqueles estabelecidos pela Associação Brasileira de Normas Técnicas (ABNT) ou reconhecidos internacionalmente;

 

7.2. Garantir que, está disponível nos equipamentos a serem utilizados pela empresa provedora de serviços , ao menos os padrões nos moldes do SEC009 (Multi-tenant hosting management security) e do SEC002x (Security feature management of open source software), definidos pela ETSI (European Telecommunications.

 

7.3. Garantir que se utiliza o protocolo IPV6, a fim de se evitar o tráfego de dados forjados, sem prejuízo da proteção da origem dos dados trafegados.

 

7.4. Deixar claro se os softwares utilizados nos equipamentos de infraestrutura de redes 5G são abertos e se são passíveis de auditoria em termos de segurança.

 

7.5. Garantir que o produto / Sistema passou por um processo de auditoria que assegurem a segurança cibernética dos produtos / sistemas utilizados na rede 5G, podendo ser fornecidos de forma conjunta com as prestadoras de serviços e empresas interessadas em fornecer tecnologia 5G;

 

7.6. Garantir que o equipamento não afeta os requisitos de segurança da informação, quais sejam: disponibilidade, integridade, e confidencialidade na atividade de tráfego na rede 5G.

 

7.7 Deixar claro se os equipamentos dispõem de mecanismos que possibilitem inspeção, inclusive a sua auditoria, em equipamentos em produção, até mesmo com a retirada de hardware  para avaliação em laboratório;

 

7.8. Garantir que o equipamento dispõe de facilidade para  registrar o estado de configuração dos equipamentos de sua rede (resultado do gerenciamento de configuração), contendo informações como topologia de rede, versões de hardware e de software dos equipamentos, a fim de auxiliar a atividade de auditoria.

 

 

 

8. DISPOSIÇÕES FINAIS (Alteração da numeração do item 7 original)

 

8.1.Considerando as ininterruptas evoluções tecnológicas do setor de telecomunicações e o incessante
surgimento de novas ameaças à segurança cibernética para equipamentos de telecomunicações, este
documento está sujeito a periódicas atualizações a fim de manter-se alinhado ao estado da arte do setor.
Imprimir

 

 

 

(Acréscimo de item 9 – Justificativa: Contribuição necessário para dar maior objetividade na avaliação da característica de ciber segurança fornecido pelo produto)

 

9. MODELO DE RELATORIO COM  LISTA DE VERIFICAÇÃO E AVALIAÇÃO DO PRODUTO APRESETADO

 

Ferramenta para evidenciar conformidade do Produto/Sistema apresentado pelo SOLICITANTE aos requisitos da Anatel especificados na tabela abaixo.

 

Previsto determinar o grau de atendimento a estes requisitos básicos de segurança cibernética.

 

 

 

MODELO DE RELATÓRIO DE AVALIAÇÃO DE CONFORMIDADE 

 

1.           OBJETIVO

 

Ferramenta para evidenciar conformidade do Produto/Sistema apresentado pelo SOLICITANTE aos requisitos da Anatel especificados na tabela abaixo.

 

Previsto determinar o grau de atendimento a estes requisitos básicos de segurança cibernética.

 

 

 

2.           IDENTIFICAÇÃO DO PRODUTO

 

SISTEMA:

xxxxx

 

PRODUTO:

MODELOS:

Xxxxx

xxxxxx

ZZZZZZZ 

 

3.           CARACTERÍSTICAS TÉCNICAS DOS PRODUTOS

 

O Produto/Sistema  apresentado pelo solicitante é composto hardware contidos na lista anexa bem como de software.

 

Descrição de como funciona o produto/Sistema e as condições de contorno utilizadas no seu projeto.

 

Em particular descrever/declarar a política de segurança cibernética projetada e implementada.

 

 

 

4.           REFERÊNCIAS TÉCNICAS

 

Nota: Listar as referências técnicas utilizadas no projeto do seu produto de preferência com normas e melhores práticas internacionais.

 

4.1.           Regulamento de Avaliação da Conformidade e de Homologação de Produtos para Telecomunicações, aprovado pela Resolução n.º 715, de 23 de outubro de 2019.

 

4.2.           OECD - Enhancing the Digital Security of Products - Draft Scoping Paper (November 2019).

 

4.3.           IEEE Internet Technology Policy Community White Paper - Internet of Things (IoT) Security Best Practices (February 2017).

 

4.4.           IETF - Internet of Things (IoT) Security: State of the Art and Challenges - RFC 8576.

 

4.5.           LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

 

4.6.           ENISA - Baseline Security Recommendations for IoT in the Context of Critical Information Infrastructures (November 2017).

 

4.7.           GSMA IoT Security Guidelines – Complete Document Set.

 

4.8.           Instrução Normativa número 4 de 26/03/2020 - Gabinete de Segurança Institucional

 

 

 

5.        RELAÇÃO DE DOCUMENTOS APRESENTADOS

 

Manual/Especificações Técnicas; Declaração do fabricante

 

Fotos – Diagramas  -  Certificações

 

 

 

6.       AVALIAÇÃO DOS REQUISITOS BÁSICOS DE SEGURANÇA CIBERNÉTICA E O GRAU DE ATENDIMENTO EVIDENCIADO.

 

 

 

Requisitos mínimos de segurança cibernética para equipamentos de telecomunicações

1          

Ser Produto/Sistema  de terminal que se conectam à Internet e para produtos/ Sistemas de infraestrutura de redes de telecomunicações, com facilidades construídas visando minimizar vulnerabilidades por meio de atualizações de software/firmware ou por meio de recomendações em configurações e em seus mecanismos de gerenciamento remoto.

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

Requisitos  Gerais

 

2          

Analise e Avaliação dos documentos fornecidos e da declaração de conformidade para evidenciar consistência com produto e modelos abrangidos considera as diferentes características técnicas dos equipamentos (quantidade de memória, capacidade de processamento de dados, interfaces do usuário, interfaces de comunicação, etc.) e os fins a que se destinam. O que foi declarado/evidenciado e o que será comercializado?
 

Grau

0

4

8

10

 

 

 

 

 

3          

Evidenciar que para produtos enquadrados na definição de CPE (Customer Premises Equipment) , a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência :- LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

 

Grau

0

4

8

10

 

 

 

 

 

4          

Identificar/declarar vulnerabilidades relacionadas a um ou mais requisitos de segurança cibernética e o grau de risco da vulnerabilidade. Validar análise de risco e garantir que será informado aos usuários e demais interessados.

Grau

0

4

8

10

 

 

 

 

 

5          

Evidenciar/avaliar que possui mecanismos periódicos, seguros e automatizados para atualização de software/firmware que empregam métodos adequados de confidencialidade, integridade, disponibilidade e autenticidade.

Grau

0

4

8

10

 

 

 

 

 

6          

Deve garantir que as informações trafegadas estão suportadas por um protocolo de segurança, criptografia e algoritmos de segurança e métodos de verificação de integridade, provendo a confidencialidade e inviolabilidade dos dados.

Grau

0

4

8

10

 

 

 

 

 

7          

Evidenciar/avaliar que os usuários verifiquem, de forma não automatizada, a disponibilidade de atualizações de software/firmware.

Grau

0

4

8

10

 

 

 

 

 

 

 

 

 

8          

Evidenciar/avaliar  que se identificado uma vulnerabilidade no software/firmware é garantido que o equipamento seja atualizado/ação corretiva.

Grau

0

4

8

10

 

 

 

 

 

9          

Evidenciar/avaliar que possuir os mesmos mecanismos de segurança para softwares/firmwares em modelo Beta ou versão não final (quando utilizadas).

Grau

0

4

8

10

 

 

 

 

 

10       

Evidenciar/avaliar se estão implementadas rotinas simplificadas para sua instalação e configuração, evitando potenciais falhas de segurança não intencionais.

Grau

0

4

8

10

 

 

 

 

 

11       

Evidenciar/avaliar se e realizada verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade.

Grau

0

4

8

10

 

 

 

 

 

12       

Evidenciar/avaliar se possui mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado.

Grau

0

4

8

10

 

 

 

 

 

13       

Evidenciar/avaliar  se esta implementada ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários, alteração de configurações do sistema e funcionamento do sistema.

Grau

0

4

8

10

 

 

 

 

 

14       

Evidenciar/avaliar que a documentação fornecida deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado.

Grau

0

4

8

10

 

 

 

 

 

15       

Evidenciar/avaliar que é realizada verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade e em caso de versões beta e versões não final, alertar sobre o modelo atual.

 

Grau

0

4

8

10

 

 

 

 

 

16       

Evidenciar/avaliar se possui mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado e permitindo o usuário a escolha de uma inicialização com os parâmetros de segurança de fábrica.

 

Grau

0

4

8

10

 

 

 

 

 

17       

Evidenciar/avaliar  Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado e também as releases Betas ou versões não finais.

Grau

0

4

8

10

 

 

 

 

 

 

 

 

18       

Evidenciar/avaliar  que não são utilizadas credenciais e senhas iniciais para acesso às suas configurações que sejam iguais entre todos os dispositivos produzidos.

Grau

0

4

8

10

 

 

 

 

 

19       

Evidenciar/avaliar  que não são utilizadas senhas que sejam derivadas de informações de fácil obtenção por métodos de escaneamento de tráfego de dados em rede, tal com endereços MAC - Media Access Control.

 

Grau

0

4

8

10

 

 

 

 

 

20       

Evidenciar/avaliar que seja forçada, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.

Grau

0

4

8

10

 

 

 

 

 

21       

Evidenciar/avaliar  que não é permitido o uso de senhas em branco ou senhas fracas.

Grau

0

4

8

10

 

 

 

 

 

22       

Evidenciar/avaliar  se possui mecanismos de defesa contra tentativas exaustivas de acesso não autorizado (ataques de autenticação por força bruta).

Grau

0

4

8

10

 

 

 

 

 

23       

Evidenciar/avaliar utilização de mecanismos de autenticação baseados em 2 fatores.

Grau

0

4

8

10

 

 

 

 

 

24       

Evidenciar/avaliar solicitar novas confirmações periódicas para os meios utilizados em autenticação baseada em 2 fatores.

Grau

0

4

8

10

 

 

 

 

 

25       

Evidenciar/avaliar  se não é utilizado credenciais e senhas definidas no próprio código fonte do software/firmware e que não podem ser alteradas (hard-code).
 

Grau

0

4

8

10

 

 

 

 

 

26       

Evidenciar/avaliar que mecanismos de segurança devam ser aplicados também para portas físicas de serviço.

Grau

0

4

8

10

 

 

 

 

 

27       

Evidenciar/avaliar se são protegidas as senhas, chaves de acesso e credenciais armazenadas ou transmitidas utilizando métodos adequados de criptografia ou hashing.

Grau

0

4

8

10

 

 

 

 

 

28       

Evidenciar/avaliar que tem garantia que os mecanismos de recuperação de senha sejam robustos contra tentativas de roubo de credenciais.

Grau

0

4

8

10

 

 

 

 

 

29       

Evidenciar/avaliar que em caso de comportamento não padrão durante telas de login solicitar testes de CAPTCHA .

Grau

0

4

8

10

 

 

 

 

 

 

30       

Evidenciar/avaliar que após tentativas seguidas de acesso sem sucesso, seja gerado um bloqueio temporário a novas tentativas.

Grau

0

4

8

10

 

 

 

 

 

31       

Evidenciar/avaliar que seja garantido os itens mencionados acima para qualquer versão de software/firmware (beta e versões não finais).

Grau

0

4

8

10

 

 

 

 

 

32       

Evidenciar/avaliar que está desprovido de qualquer ferramenta de teste ou backdoor intencional utilizados nos processos de desenvolvimento do produto e desnecessários à sua operação usual.

Grau

0

4

8

10

 

 

 

 

 

33       

Evidenciar/avaliar que  não sejam fornecidas portas de comunicação não essenciais, reduzindo sua superfície de ataque.

Grau

0

4

8

10

 

 

 

 

 

34       

Evidenciar/avaliar que é facultar ao usuário a possibilidade de desabilitar funcionalidades, serviços e portas de comunicação não essenciais à operação ou ao gerenciamento do equipamento.

Grau

0

4

8

10

 

 

 

 

 

35       

Evidenciar/avaliar a utilização de métodos adequados de criptografia para transmissão e armazenamento de dados sensíveis, incluindo informações pessoais.

 

Grau

0

4

8

10

 

 

 

 

 

36       

Evidenciar/avaliar que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais.

Grau

0

4

8

10

 

 

 

 

 

37       

Evidenciar/avaliar que possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos ou sistemas (ataque de negação de serviço).

 

Grau

0

4

8

10

 

 

 

 

 

38       

Evidenciar/avaliar se são projetados para mitigar os efeitos de ataques de negação de serviço em andamento, sendo resistentes a um número excessivo de tentativas de autenticação, por meio de, por exemplo: priorização de sua capacidade de processamento às sessões de comunicação já estabelecidas e autenticadas; e
limitação do número de sessões de autenticação concorrentes, descartando tentativas de estabelecimento de novas sessões quando superado limite estabelecido.

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

REQUISITOS PARA FORNECEDORES DE EQUIPAMENTOS PARA TELECOMUNICAÇÕES

Os fornecedores de equipamentos terminais que se conectam à Internet e de equipamentos de infraestrutura de redes de telecomunicações, devem :

39       

Evidenciar/Avaliar que tem uma política clara de suporte ao produto, especialmente em relação à disponibilização de atualizações de software/firmware para correção de vulnerabilidades de segurança.

Grau

0

4

8

10

 

 

 

 

 

40       

Evidenciar/Avaliar  que .Deixa claro para o consumidor até quando serão providas atualizações de segurança para o equipamento e com que frequência ocorrerão.
reportarem vulnerabilidades de segurança identificadas nos produtos.

Grau

0

4

8

10

 

 

 

 

 

41       

Evidenciar/Avaliar como está garantido que os processos de atualização automática de software/firmware sejam realizados em fases a fim de evitar que erros não intencionais da nova versão de software/firmware sejam distribuídos a todos os equipamentos sob atualização de uma só vez.

 

Grau

0

4

8

10

 

 

 

 

 

42       

Evidenciar/Avaliar se e como são providas as atualizações de segurança por, no mínimo, 2 (dois) anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

 

Grau

0

4

8

10

 

 

 

 

 

43       

Evidenciar/Avaliar  se está disponibilizado um canal de comunicação que possibilite aos seus clientes, usuários finais e terceiros reportarem vulnerabilidades de segurança identificadas nos produtos

Grau

0

4

8

10

 

 

 

 

 

44       

Evidenciar/Avaliar que está a garantir que a versão Beta ou não final do software/firmware deixe de funcionar após o lançamento da versão oficial.

 

Grau

0

4

8

10

 

 

 

 

 

45       

Evidenciar/Avaliar que uma versão antigas/anteriores de firmware (desde que versões oficiais e não betas) só deverão funcionar em caso de bug ou problemas identificados na versão final pelo fabricante/fornecedor.

Grau

0

4

8

10

 

 

 

 

 

46       

Evidenciar/Avaliar que está a garantir que seja mínimo o impacto nas atividades dos clientes, usuários finais e terceiros durante uma atualização, sugerindo que esta seja feita durante inatividade do equipamento ou via agendamento proposto pelo usuário.

 

Grau

0

4

8

10

 

 

 

 

 

47       

Evidenciar/Avaliar estabelecer um prazo máximo para que todos os equipamentos estejam atualizados após o lançamento de uma nova versão de software/firmware, podendo em alguns casos não depender de intervenções de usuário para essa atualização.

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

48       

Evidenciar/Avaliar que caso algum problema ocorra durante a atualização de firmware/software o equipamento seja capaz de restaurar as ultimas configurações válidas garantindo o seu correto funcionamento.

 

Grau

0

4

8

10

 

 

 

 

 

Disponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa, 
para: 

49       

Evidenciar/Avaliar que está disponível como informar sobre novas vulnerabilidades identificadas em seus produtos, medidas de mitigação e correções de segurança associadas.

Grau

0

4

8

10

 

 

 

 

 

50       

Evidenciar/Avaliar que está disponível  e mantido histórico de: vulnerabilidades identificadas, medidas de mitigação e correções de segurança.

Grau

0

4

8

10

 

 

 

 

 

51       

Evidenciar/Avaliar que está disponível e permitido acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos.

Grau

0

4

8

10

 

 

 

 

 

52       

Evidenciar/Avaliar que está disponível os manuais e outros materiais com orientações relativas à configuração, atualização e uso seguro dos equipamentos.

Grau

0

4

8

10

 

 

 

 

 

 

 

 

Requisitos  da Instrução Normativa número 4 - Segurança Cibernética que devem ser adotados no estabelecimento para os equipamentos utilizados nas redes 5G.

53       

Evidenciar / Avaliar que os serviços prestados e os equipamentos utilizados cumpram os protocolos de comunicação e as especificações técnicas de infraestrutura reconhecidos pela Agência Nacional de Telecomunicações ou, na sua ausência, aqueles estabelecidos pela Associação Brasileira de Normas Técnicas (ABNT) ou reconhecidos internacionalmente;
 

Grau

0

4

8

10

 

 

 

 

 

54       

Evidenciar / Avaliar se está disponível nos equipamentos a serem utilizados pela empresa provedora de serviços  ao menos os padrões nos moldes do SEC009 (Multi-tenant hosting management security) e do SEC002x (Security feature management of open source software), definidos pela ETSI (European Telecommunications

 

Grau

0

4

8

10

 

 

 

 

 

55       

Evidenciar / Avaliar se utiliza o protocolo IPV6, a fim de se evitar o tráfego de dados forjados, sem prejuízo da proteção da origem dos dados trafegados

Grau

0

4

8

10

 

 

 

 

 

 

56       

Evidenciar / Avaliar se os softwares utilizados nos equipamentos de infraestrutura de redes 5G são abertos e se são passíveis de auditoria em termos de segurança;

 

Grau

0

4

8

10

 

 

 

 

 

57       

Evidenciar / Avaliar se o produto / Sistema passou por um processo de auditoria que assegurem a segurança cibernética dos produtos / sistemas utilizados na rede 5G, podendo ser fornecidos de forma conjunta com as prestadoras de serviços e empresas interessadas em fornecer tecnologia 5G;

Grau

0

4

8

10

 

 

 

 

 

58       

Evidenciar / Avaliar se o equipamento não afeta os requisitos de segurança da informação, quais sejam: disponibilidade, integridade, e confidencialidade na atividade de tráfego na rede 5G.

 

Grau

0

4

8

10

 

 

 

 

 

59       

Evidenciar / Avaliar se os equipamentos dispõem de mecanismos que possibilitem inspeção, inclusive a sua auditoria, em equipamentos em produção, até mesmo com a retirada de hardware  para avaliação em laboratório;

Grau

0

4

8

10

 

 

 

 

 

60       

Evidenciar / Avaliar se o equipamento dispõe de facilidade para  registrar o estado de configuração dos equipamentos de sua rede (resultado do gerenciamento de configuração), contendo informações como topologia de rede, versões de hardware e de software dos equipamentos, a fim de auxiliar a atividade de auditoria

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

CRITÉRIO DE AVALIAÇÃO

0 (zero) pontos

INACEITÁVEL

não apresentou os requisitos mínimos.

4 (quatro) pontos

INSUFICIENTE

apresentou os requisitos mínimos, mas contendo erros ou omissões que caracterizam conhecimento insuficiente dos assuntos , não satisfazendo adequadamente às funcionalidades exigidas;

8 (oito) pontos

BOM

apresentou os requisitos mínimos e conhecimento suficiente dos assuntos, satisfazendo adequadamente às funcionalidades exigidas;

10 (dez) pontos

EXCELENTE

apresentou os requisitos mínimos e conhecimento aprofundado, demonstrando evidências em atuar com desempenho sólido e segurança na melhoria das funcionalidades exigidas. Funções que apesar de não requeridas agregam valor aos requisitos específicos,

 

 

 

Nota:- Coma soma destes pontos pode ser criado critérios para comparação dos  produtos

 

 

 

Contribuição da ABRAC CT-TELECOM

 

Esclarecimentos adicionais:-

 

A declaração de conformidade deve ser analisada e ter uma avaliação de conformidade do produtos / software x versus documentos apresentados. Deve ser feito por organismos credenciados no INMETRO / Anatel e com escopo adequado a esta atividade.

 

ENTREGAVEL:- Relatório Garantindo que o produto / serviço esta devidamente avaliado quanto a SEGURANÇA CIBERNETICA . Requisitos mínimos especificados pela Anatel.

 

 

 

RECEBIMENTO / ACEITAÇÃO DE AUTO DECLARAÇÃO DE PRODUTOS E SERVIÇOS

 

1)      Utilizar organismo com escopo para este trabalho técnico  no ANATEL / INMETRO

 

2)      Empresa Solicitante com autorização legal na atividade que especifica a sua declaração de conformidade.

 

3)      Profissional Especialista com acervo  no seu conselho – atuação profissional coberto pela lei

 

4)      Analise da consistência dos documentos técnicos apresentados para suportar sua Declaração de Conformidade e se o produto ensaiado são idêntico ao que pretende ser comercializar no Brasil .

 

5)      VALIDAR A AUTO DECLARAÇÃO PARA ANATEL

  

Justificativa:

Considerando que não consegui anexar item por item, anexamos toda a contribuição por inteiro no item acima:  anexo

Contribuição N°: 11
ID da Contribuição: 92667
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:13:36
Contribuição:

 

CONTRIBUIÇÃO DA ABRAC  CT-TELECOM

 

14/05/2020

 

CONSULTA PÚBLICA Nº 13 - MINUTA DE ATO
 

 

O SUPERINTENDENTE DE OUTORGA E RECURSOS À PRESTAÇÃO - ANATEL, no uso das
atribuições que lhe foram conferidas pela Resolução n.º 715, de 23 de outubro de 2019, e CONSIDERANDO a competência dada pelos Incisos XIII e XIV do Art. 19 da Lei n.º 9.472/97 – Lei Geral de Telecomunicações;
CONSIDERANDO o Art. 22 do Regulamento para Avaliação da Conformidade e Homologação de Produtos para Telecomunicações, aprovado pela Resolução n.º 715, de 23 de outubro de 2019;
CONSIDERANDO a Estratégia Nacional de Segurança Cibernética, aprovada por meio do Decreto nº
10.222, de 5 de fevereiro de 2020; e
CONSIDERANDO o constante dos autos do processo nº 53500.026122/2019-70,
RESOLVE:

 

Art. 1º Aprovar os requisitos mínimos de segurança cibernética para equipamentos para telecomunicações, nos moldes do Anexo a este Ato.

 

Art. 2º Este Ato entra em vigor 180 (cento e oitenta) dias após a data de sua publicação no Boletim de
Serviços Eletrônico da Anatel.
 

 

ANEXO
REQUISITOS MÍNIMOS DE SEGURANÇA CIBERNÉTICA PARA EQUIPAMENTO DE TELECOMUNICAÇÕES
 

 

1. OBJETIVO
1.1.Estabelecer requisitos mínimos de segurança cibernética para equipamentos terminais que se
conectam à Internet e para equipamentos de infraestrutura de redes de telecomunicações, visando
minimizar vulnerabilidades por meio de atualizações de software/firmware ou por meio de recomendações em configurações e em seus mecanismos de gerenciamento remoto.

 

1.2. Atender aos requisitos de segurança cibernetica para os produtos do item 1.1 contidos na Instrução Normativa Nº 4, DE 26 DE MARÇO DE 2020 do GSI.  

 

 

 

Justificativa – incluir item 1,2,  -  Considerando que a Instrução Nortativa 5 da GSI foi publicada apos a CP13 entende,ps que e importante a sua referencia e atendimento.

 


2. REFERÊNCIAS
2.1.Regulamento de Avaliação da Conformidade e de Homologação de Produtos para Telecomunicações,
aprovado pela Resolução n.º 715, de 23 de outubro de 2019.
2.2.OECD - Enhancing the Digital Security of Products - Draft Scoping Paper (November 2019).
2.3.IEEE Internet Technology Policy Community White Paper - Internet of Things (IoT) Security Best
Practices (February 2017).
2.4.IETF - Internet of Things (IoT) Security: State of the Art and Challenges - RFC 8576.
2.5.LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.
2.6.ENISA - Baseline Security Recommendations for IoT in the Context of Critical Information
Infrastructures (November 2017).
2.7.GSMA IoT Security Guidelines – Complete Document Set.

 

Justificativa – Incluir a referencia publicada após a consulta e utilizada na contribuição

 

2.8. Instrução Normativa número 4 de 26/03/2020 - Gabinete de Segurança Institucional

 


3. DEFINIÇÕES
3.1.Backdoor: mecanismo não documentado contido no software/firmware do produto que possibilita
acesso não autorizado ao equipamento. A presença de backdoors pode ser intencional ou acidental,
podendo ser decorrente de erros de programação.
3.2.Customer Premise Equipment (CPE): equipamento utilizado para conectar assinantes à rede do
provedor de serviços de telecomunicações.
3.3.Firmware: software ou conjunto de softwares programados em um hardware de propósito específico e
que fornecem controle de baixo nível.
3.4.Hashing: algoritmo matemático que mapeia dados de comprimento variável na entrada de uma função
para um conjunto de dados de comprimento fixo na saída da função. O resultado da função hash possui
muito pouca correlação com os dados de entrada da função, impossibilitando a obtenção do valor inicial de entrada a partir do resultado da operação da função.
3.5.Métodos adequados de criptografia, autenticação e integridade: protocolos ou algoritmos de
criptografia, autenticação e integridade, em suas versões atualizadas. A implementação deve permitir a
seleção de conjuntos de criptografia e tamanhos de chave atualizados.
 

 

4. REQUISITOS GERAIS
4.1.O interessado na homologação deve demonstrar conformidade do produto por meio de declaração
afirmando:
a) que o equipamento e seu fornecedor atendem os requisitos contidos neste documento; e
b) estar ciente que este documento está sujeito a atualizações.
4.2.O escopo da declaração de conformidade deve considerar as diferentes características técnicas dos
equipamentos (quantidade de memória, capacidade de processamento de dados, interfaces do usuário,
interfaces de comunicação, etc.) e os fins a que se destinam, apontando quais requisitos são atendidos.
4.2.1.Para produtos enquadrados na definição de CPE, a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência 2.5.
4.3.Nas atividades de supervisão de mercado, a Agência poderá avaliar os requisitos contidos neste
documento por meio de procedimentos de ensaios orientados pelas melhores práticas, padronizadas
internacionalmente, para avaliação de vulnerabilidades.

 

(Acréscimo de novo item – Justificativa: Dada a complexidade da avaliação das características relativas a Ciber Security em conjunto com  a necessidade de ser uma ação preventiva anterior a homologação do produto, é primordial a OCD e laboratório como agentes para dar o devido dinamismo ao processo sem comprometimento temporal da disponibilização das soluções.)

 

4.x. Nas atividades de avaliação da conformidade referente a declaração do solicitante  e da validação de relatórios de ensaios  de produtos para telecomunicações e segurança cibernética  devem ser usados os Organismos de Certificação  Designados – OCD e os Laboratórios de Ensaio tecnicamente capacitados e devidamente habilitados. Acrescentando qualificação para as atividades de segurança cibernética - Art. 6º Resolução 715

 


4.4.Identificada, no produto homologado, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência notificará o responsável pela homologação a sana-la, indicando prazo
adequado para esse fim, considerando-se o grau de risco da vulnerabilidade.
4.4.1.Decorrido o prazo sem que se verifique as adaptações necessárias ou a justificativa aceita pela Anatel para sua não implementação, a Agência suspenderá a homologação do produto, podendo indicar o
recolhimento ou substituição do mesmo no mercado, garantidas as demais previsões regulamentares
referentes ao direito do consumidor.
4.4.2.A suspensão da homologação do equipamento será mantida até que as vulnerabilidades apontadas
sejam sanadas ou até que o potencial risco à segurança dos serviços para telecomunicações seja mitigado,
considerando-se o prazo máximo estabelecido na regulamentação vigente.
4.4.3.Após o prazo máximo determinado para sua suspensão, a homologação será cancelada, caso a
vulnerabilidade não seja solucionada.
 

 

5. REQUISITOS DE SEGURANÇA CIBERNÉTICA DOS EQUIPAMENTOS PARA
TELECOMUNICAÇÕES
5.1.Equipamentos terminais que se conectam à Internet e equipamentos de infraestrutura de redes de
telecomunicações, em suas versões finais destinadas à comercialização, devem:
5.1.1.Quanto à atualização de software/firmware:
a) Possuir mecanismos periódicos, seguros e automatizados para atualização de software/firmware que
empregam métodos adequados de criptografia, autenticação e integridade.
b) Permitir que os usuários verifiquem, de forma não automatizada, a disponibilidade de atualizações de
software/firmware.

 

((Acréscimo de novas alíneas Justificativa: Funcionalidades relevantes referente a atualização)

 

c) Possuir mecanismos para identificar se o software/firmware foi atualizado de acordo com as recomendações do fabricante, evitando atualização que possam incluir backdoors

 

d) Possuir mecanismos para permitir retornar as configurações anteriores em caso de detecção de não conformidade com as configurações do fabricante.

 

e) Possuir mecanismos de informar notificações sobre alterações de segurança devido às atualizações.

 

f) Se identificado uma vulnerabilidade no software/firmware garantir que o equipamento seja atualizado.

 

g) Possuir os mesmos mecanismos de segurança para softwares/firmwares em modelo Beta ou versão não final.

 


5.1.2.Quanto à instalação e à operação:
a) Implementar rotinas simplificadas para sua instalação e configuração, evitando potenciais falhas de
segurança não intencionais.
b) Realizar verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade.
c) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando
o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado.

 

d) Implementar ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários,
alteração de configurações do sistema e funcionamento do sistema.
e) Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as
funcionalidades do software/firmware e/ou sistema operacional utilizado.

 

(Acréscimo de novas alíneas – Justificativa: acréscimo de funcionalidades consideradas relevantes)

 

f) Realizar verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade e em caso de versões beta e versões não final, alertar sobre o modelo atual.

 

g) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado e permitindo o usuário a escolha de uma inicialização com os parâmetros de segurança de fábrica.

 

h) Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado e também as release Betas ou versões não finais.

 

i) Permitir rastrear todo o tráfego da rede e realizar o controle de acessos para que pessoas má intencionadas não tenham acesso a dados confidencias  (acesso baseada em confiança zero),

 

j) Permitir a re-autenticação do dispositivo quando ele se mover entre diferentes redes de acesso, com a implementação do SEAF ( SECURITY ANCHOR FUNCTION).

 

l) Permitir a utilização de identificação oculta até que o equipamento que faz acesso a rede seja autenticado, garantindo que depois dessa operação seja divulgada a identificação do usuário

 


5.1.3.Quanto ao acesso ao equipamento:
a) Não utilizar credenciais e senhas iniciais para acesso às suas configurações que sejam iguais entre todos os dispositivos produzidos.
b) Não utilizar senhas que sejam derivadas de informações de fácil obtenção por métodos de
escaneamento de tráfego de dados em rede, tal com endereços MAC - Media Access Control.
c) Forçar, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.
d) Não permitir o uso de senhas em branco ou senhas fracas.
e) Possuir mecanismos de defesa contra tentativas exaustivas de acesso não autorizado (ataques de
autenticação por força bruta).
f) Garantir que os mecanismos de recuperação de senha sejam robustos contra tentativas de roubo de
credenciais.
g) Não utilizar credenciais e senhas definidas no próprio código fonte do software/firmware e que não
podem ser alteradas (hard-coded).
h) Proteger senhas, chaves de acesso e credenciais armazenadas ou transmitidas utilizando métodos
adequados de criptografia ou hashing.

 

(Acréscimo de nova alínea – Justificativa: Para enfatizar que são características para todas versões)

 

i) Garantir todos os itens mencionados acima para qualquer versão de software/firmware (beta e versões não final) 

 

5.1.4.Quanto às interfaces/portas de comunicação:
a) Estar desprovido de qualquer ferramenta de teste ou backdoor intencional utilizados nos processos de
desenvolvimento do produto e desnecessários à sua operação usual.
b) Estar desprovido de qualquer forma de comunicação intencional não documentada, incluindo aquelas
para envio de informações de perfil de uso do equipamento para fabricantes ou para terceiros.
c) Ser fornecidos com serviços de transmissão de dados (portas de comunicação) não essenciais
desabilitados, reduzindo sua superfície de ataque.
d) Facultar ao usuário a possibilidade de desabilitar funcionalidades, serviços e portas de comunicação não essenciais à operação ou ao gerenciamento do equipamento.

 


5.1.5.Quanto aos dados sensíveis e informações pessoais:
a) Possibilitar a utilização de métodos adequados de criptografia para transmissão e armazenamento de
dados sensíveis, incluindo informações pessoais.
b) Permitir que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o
descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais.

 


5.1.6.Quanto à capacidade de mitigar ataques:
a) Possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do
usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos
ou sistemas (ataque de negação de serviço).
b) Ser projetados para mitigar os efeitos de ataques de negação de serviço em andamento, sendo
resistentes a um número excessivo de tentativas de autenticação, por meio de, por exemplo: priorização
de sua capacidade de processamento às sessões de comunicação já estabelecidas e autenticadas; e
limitação do número de sessões de autenticação concorrentes, descartando tentativas de estabelecimento
de novas sessões quando superado limite estabelecido.
 

 

6. REQUISITOS PARA FORNECEDORES DE EQUIPAMENTOS PARA TELECOMUNICAÇÕES
6.1.Os fornecedores de equipamentos terminais que se conectam à Internet e de equipamentos de
infraestrutura de redes de telecomunicações, devem:
6.1.1.Ter uma política clara de suporte ao produto, especialmente em relação à disponibilização de
atualizações de software/firmware para correção de vulnerabilidades de segurança.
6.1.2.Deixar claro para o consumidor até quando serão providas atualizações de segurança para o
equipamento e com que frequência ocorrerão.
6.1.3.Garantir que os processos de atualização automática de software/firmware sejam realizadas em fases
a fim de evitar que erros não intencionais da nova versão de software/firmware sejam distribuídos a todos
os equipamentos sob atualização de uma só vez.
6.1.4.Prover atualizações de segurança por, no mínimo, 2 (dois) anos após o lançamento do produto ou
enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que
mais se estender.
6.1.5.Disponibilizar um canal de comunicação que possibilite aos seus clientes, usuários finais e terceiros
reportarem vulnerabilidades de segurança identificadas nos produtos.
6.1.6.Disponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa, 
para:
a) Informar sobre novas vulnerabilidades identificadas em seus produtos, medidas de mitigação e
correções de segurança associadas;
b) Manter histórico de: vulnerabilidades identificadas, medidas de mitigação e correções de segurança;
c) Permitir acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos;
e
d) Fornecer manuais e outros materiais com orientações relativas à configuração, atualização e uso seguro
dos equipamentos.

 

(Acréscimo de novo item. Justificativa: impedir que versões ultrapassadas estejam em uso)

 

6.1.7 Garantir que a versão Beta ou versão não final do software/firmware deixe de funcionar após o lançamento da versão oficial.

 

(Acréscimo de um novo item 7.  Justificativa: Adequação do texto da consulta à Instrução Normativa 4)

 

7.x, REQUISITOS RETIRADOS DA Instrução Normativa número 4 - Segurança Cibernética QUE DEVEM SER ADOTADOS PARA OS EQUIPAMENTOS UTILIZADOS NAS REDES 5G.

 

7.1. Garantir que os serviços prestados e os equipamentos utilizados cumpram os protocolos de comunicação e as especificações técnicas de infraestrutura reconhecidos pela Agência Nacional de Telecomunicações ou, na sua ausência, aqueles estabelecidos pela Associação Brasileira de Normas Técnicas (ABNT) ou reconhecidos internacionalmente;

 

7.2. Garantir que, está disponível nos equipamentos a serem utilizados pela empresa provedora de serviços , ao menos os padrões nos moldes do SEC009 (Multi-tenant hosting management security) e do SEC002x (Security feature management of open source software), definidos pela ETSI (European Telecommunications.

 

7.3. Garantir que se utiliza o protocolo IPV6, a fim de se evitar o tráfego de dados forjados, sem prejuízo da proteção da origem dos dados trafegados.

 

7.4. Deixar claro se os softwares utilizados nos equipamentos de infraestrutura de redes 5G são abertos e se são passíveis de auditoria em termos de segurança.

 

7.5. Garantir que o produto / Sistema passou por um processo de auditoria que assegurem a segurança cibernética dos produtos / sistemas utilizados na rede 5G, podendo ser fornecidos de forma conjunta com as prestadoras de serviços e empresas interessadas em fornecer tecnologia 5G;

 

7.6. Garantir que o equipamento não afeta os requisitos de segurança da informação, quais sejam: disponibilidade, integridade, e confidencialidade na atividade de tráfego na rede 5G.

 

7.7 Deixar claro se os equipamentos dispõem de mecanismos que possibilitem inspeção, inclusive a sua auditoria, em equipamentos em produção, até mesmo com a retirada de hardware  para avaliação em laboratório;

 

7.8. Garantir que o equipamento dispõe de facilidade para  registrar o estado de configuração dos equipamentos de sua rede (resultado do gerenciamento de configuração), contendo informações como topologia de rede, versões de hardware e de software dos equipamentos, a fim de auxiliar a atividade de auditoria.

 

 

 

8. DISPOSIÇÕES FINAIS (Alteração da numeração do item 7 original)

 

8.1.Considerando as ininterruptas evoluções tecnológicas do setor de telecomunicações e o incessante
surgimento de novas ameaças à segurança cibernética para equipamentos de telecomunicações, este
documento está sujeito a periódicas atualizações a fim de manter-se alinhado ao estado da arte do setor.
Imprimir

 

 

 

(Acréscimo de item 9 – Justificativa: Contribuição necessário para dar maior objetividade na avaliação da característica de ciber segurança fornecido pelo produto)

 

9. MODELO DE RELATORIO COM  LISTA DE VERIFICAÇÃO E AVALIAÇÃO DO PRODUTO APRESETADO

 

Ferramenta para evidenciar conformidade do Produto/Sistema apresentado pelo SOLICITANTE aos requisitos da Anatel especificados na tabela abaixo.

 

Previsto determinar o grau de atendimento a estes requisitos básicos de segurança cibernética.

 

 

 

MODELO DE RELATÓRIO DE AVALIAÇÃO DE CONFORMIDADE 

 

1.           OBJETIVO

 

Ferramenta para evidenciar conformidade do Produto/Sistema apresentado pelo SOLICITANTE aos requisitos da Anatel especificados na tabela abaixo.

 

Previsto determinar o grau de atendimento a estes requisitos básicos de segurança cibernética.

 

 

 

2.           IDENTIFICAÇÃO DO PRODUTO

 

SISTEMA:

xxxxx

 

PRODUTO:

MODELOS:

Xxxxx

xxxxxx

ZZZZZZZ 

 

3.           CARACTERÍSTICAS TÉCNICAS DOS PRODUTOS

 

O Produto/Sistema  apresentado pelo solicitante é composto hardware contidos na lista anexa bem como de software.

 

Descrição de como funciona o produto/Sistema e as condições de contorno utilizadas no seu projeto.

 

Em particular descrever/declarar a política de segurança cibernética projetada e implementada.

 

 

 

4.           REFERÊNCIAS TÉCNICAS

 

Nota: Listar as referências técnicas utilizadas no projeto do seu produto de preferência com normas e melhores práticas internacionais.

 

4.1.           Regulamento de Avaliação da Conformidade e de Homologação de Produtos para Telecomunicações, aprovado pela Resolução n.º 715, de 23 de outubro de 2019.

 

4.2.           OECD - Enhancing the Digital Security of Products - Draft Scoping Paper (November 2019).

 

4.3.           IEEE Internet Technology Policy Community White Paper - Internet of Things (IoT) Security Best Practices (February 2017).

 

4.4.           IETF - Internet of Things (IoT) Security: State of the Art and Challenges - RFC 8576.

 

4.5.           LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

 

4.6.           ENISA - Baseline Security Recommendations for IoT in the Context of Critical Information Infrastructures (November 2017).

 

4.7.           GSMA IoT Security Guidelines – Complete Document Set.

 

4.8.           Instrução Normativa número 4 de 26/03/2020 - Gabinete de Segurança Institucional

 

 

 

5.        RELAÇÃO DE DOCUMENTOS APRESENTADOS

 

Manual/Especificações Técnicas; Declaração do fabricante

 

Fotos – Diagramas  -  Certificações

 

 

 

6.       AVALIAÇÃO DOS REQUISITOS BÁSICOS DE SEGURANÇA CIBERNÉTICA E O GRAU DE ATENDIMENTO EVIDENCIADO.

 

 

 

Requisitos mínimos de segurança cibernética para equipamentos de telecomunicações

1          

Ser Produto/Sistema  de terminal que se conectam à Internet e para produtos/ Sistemas de infraestrutura de redes de telecomunicações, com facilidades construídas visando minimizar vulnerabilidades por meio de atualizações de software/firmware ou por meio de recomendações em configurações e em seus mecanismos de gerenciamento remoto.

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

Requisitos  Gerais

 

2          

Analise e Avaliação dos documentos fornecidos e da declaração de conformidade para evidenciar consistência com produto e modelos abrangidos considera as diferentes características técnicas dos equipamentos (quantidade de memória, capacidade de processamento de dados, interfaces do usuário, interfaces de comunicação, etc.) e os fins a que se destinam. O que foi declarado/evidenciado e o que será comercializado?
 

Grau

0

4

8

10

 

 

 

 

 

3          

Evidenciar que para produtos enquadrados na definição de CPE (Customer Premises Equipment) , a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência :- LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

 

Grau

0

4

8

10

 

 

 

 

 

4          

Identificar/declarar vulnerabilidades relacionadas a um ou mais requisitos de segurança cibernética e o grau de risco da vulnerabilidade. Validar análise de risco e garantir que será informado aos usuários e demais interessados.

Grau

0

4

8

10

 

 

 

 

 

5          

Evidenciar/avaliar que possui mecanismos periódicos, seguros e automatizados para atualização de software/firmware que empregam métodos adequados de confidencialidade, integridade, disponibilidade e autenticidade.

Grau

0

4

8

10

 

 

 

 

 

6          

Deve garantir que as informações trafegadas estão suportadas por um protocolo de segurança, criptografia e algoritmos de segurança e métodos de verificação de integridade, provendo a confidencialidade e inviolabilidade dos dados.

Grau

0

4

8

10

 

 

 

 

 

7          

Evidenciar/avaliar que os usuários verifiquem, de forma não automatizada, a disponibilidade de atualizações de software/firmware.

Grau

0

4

8

10

 

 

 

 

 

 

 

 

 

8          

Evidenciar/avaliar  que se identificado uma vulnerabilidade no software/firmware é garantido que o equipamento seja atualizado/ação corretiva.

Grau

0

4

8

10

 

 

 

 

 

9          

Evidenciar/avaliar que possuir os mesmos mecanismos de segurança para softwares/firmwares em modelo Beta ou versão não final (quando utilizadas).

Grau

0

4

8

10

 

 

 

 

 

10       

Evidenciar/avaliar se estão implementadas rotinas simplificadas para sua instalação e configuração, evitando potenciais falhas de segurança não intencionais.

Grau

0

4

8

10

 

 

 

 

 

11       

Evidenciar/avaliar se e realizada verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade.

Grau

0

4

8

10

 

 

 

 

 

12       

Evidenciar/avaliar se possui mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado.

Grau

0

4

8

10

 

 

 

 

 

13       

Evidenciar/avaliar  se esta implementada ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários, alteração de configurações do sistema e funcionamento do sistema.

Grau

0

4

8

10

 

 

 

 

 

14       

Evidenciar/avaliar que a documentação fornecida deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado.

Grau

0

4

8

10

 

 

 

 

 

15       

Evidenciar/avaliar que é realizada verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade e em caso de versões beta e versões não final, alertar sobre o modelo atual.

 

Grau

0

4

8

10

 

 

 

 

 

16       

Evidenciar/avaliar se possui mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado e permitindo o usuário a escolha de uma inicialização com os parâmetros de segurança de fábrica.

 

Grau

0

4

8

10

 

 

 

 

 

17       

Evidenciar/avaliar  Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado e também as releases Betas ou versões não finais.

Grau

0

4

8

10

 

 

 

 

 

 

 

 

18       

Evidenciar/avaliar  que não são utilizadas credenciais e senhas iniciais para acesso às suas configurações que sejam iguais entre todos os dispositivos produzidos.

Grau

0

4

8

10

 

 

 

 

 

19       

Evidenciar/avaliar  que não são utilizadas senhas que sejam derivadas de informações de fácil obtenção por métodos de escaneamento de tráfego de dados em rede, tal com endereços MAC - Media Access Control.

 

Grau

0

4

8

10

 

 

 

 

 

20       

Evidenciar/avaliar que seja forçada, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.

Grau

0

4

8

10

 

 

 

 

 

21       

Evidenciar/avaliar  que não é permitido o uso de senhas em branco ou senhas fracas.

Grau

0

4

8

10

 

 

 

 

 

22       

Evidenciar/avaliar  se possui mecanismos de defesa contra tentativas exaustivas de acesso não autorizado (ataques de autenticação por força bruta).

Grau

0

4

8

10

 

 

 

 

 

23       

Evidenciar/avaliar utilização de mecanismos de autenticação baseados em 2 fatores.

Grau

0

4

8

10

 

 

 

 

 

24       

Evidenciar/avaliar solicitar novas confirmações periódicas para os meios utilizados em autenticação baseada em 2 fatores.

Grau

0

4

8

10

 

 

 

 

 

25       

Evidenciar/avaliar  se não é utilizado credenciais e senhas definidas no próprio código fonte do software/firmware e que não podem ser alteradas (hard-code).
 

Grau

0

4

8

10

 

 

 

 

 

26       

Evidenciar/avaliar que mecanismos de segurança devam ser aplicados também para portas físicas de serviço.

Grau

0

4

8

10

 

 

 

 

 

27       

Evidenciar/avaliar se são protegidas as senhas, chaves de acesso e credenciais armazenadas ou transmitidas utilizando métodos adequados de criptografia ou hashing.

Grau

0

4

8

10

 

 

 

 

 

28       

Evidenciar/avaliar que tem garantia que os mecanismos de recuperação de senha sejam robustos contra tentativas de roubo de credenciais.

Grau

0

4

8

10

 

 

 

 

 

29       

Evidenciar/avaliar que em caso de comportamento não padrão durante telas de login solicitar testes de CAPTCHA .

Grau

0

4

8

10

 

 

 

 

 

 

30       

Evidenciar/avaliar que após tentativas seguidas de acesso sem sucesso, seja gerado um bloqueio temporário a novas tentativas.

Grau

0

4

8

10

 

 

 

 

 

31       

Evidenciar/avaliar que seja garantido os itens mencionados acima para qualquer versão de software/firmware (beta e versões não finais).

Grau

0

4

8

10

 

 

 

 

 

32       

Evidenciar/avaliar que está desprovido de qualquer ferramenta de teste ou backdoor intencional utilizados nos processos de desenvolvimento do produto e desnecessários à sua operação usual.

Grau

0

4

8

10

 

 

 

 

 

33       

Evidenciar/avaliar que  não sejam fornecidas portas de comunicação não essenciais, reduzindo sua superfície de ataque.

Grau

0

4

8

10

 

 

 

 

 

34       

Evidenciar/avaliar que é facultar ao usuário a possibilidade de desabilitar funcionalidades, serviços e portas de comunicação não essenciais à operação ou ao gerenciamento do equipamento.

Grau

0

4

8

10

 

 

 

 

 

35       

Evidenciar/avaliar a utilização de métodos adequados de criptografia para transmissão e armazenamento de dados sensíveis, incluindo informações pessoais.

 

Grau

0

4

8

10

 

 

 

 

 

36       

Evidenciar/avaliar que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais.

Grau

0

4

8

10

 

 

 

 

 

37       

Evidenciar/avaliar que possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos ou sistemas (ataque de negação de serviço).

 

Grau

0

4

8

10

 

 

 

 

 

38       

Evidenciar/avaliar se são projetados para mitigar os efeitos de ataques de negação de serviço em andamento, sendo resistentes a um número excessivo de tentativas de autenticação, por meio de, por exemplo: priorização de sua capacidade de processamento às sessões de comunicação já estabelecidas e autenticadas; e
limitação do número de sessões de autenticação concorrentes, descartando tentativas de estabelecimento de novas sessões quando superado limite estabelecido.

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

REQUISITOS PARA FORNECEDORES DE EQUIPAMENTOS PARA TELECOMUNICAÇÕES

Os fornecedores de equipamentos terminais que se conectam à Internet e de equipamentos de infraestrutura de redes de telecomunicações, devem :

39       

Evidenciar/Avaliar que tem uma política clara de suporte ao produto, especialmente em relação à disponibilização de atualizações de software/firmware para correção de vulnerabilidades de segurança.

Grau

0

4

8

10

 

 

 

 

 

40       

Evidenciar/Avaliar  que .Deixa claro para o consumidor até quando serão providas atualizações de segurança para o equipamento e com que frequência ocorrerão.
reportarem vulnerabilidades de segurança identificadas nos produtos.

Grau

0

4

8

10

 

 

 

 

 

41       

Evidenciar/Avaliar como está garantido que os processos de atualização automática de software/firmware sejam realizados em fases a fim de evitar que erros não intencionais da nova versão de software/firmware sejam distribuídos a todos os equipamentos sob atualização de uma só vez.

 

Grau

0

4

8

10

 

 

 

 

 

42       

Evidenciar/Avaliar se e como são providas as atualizações de segurança por, no mínimo, 2 (dois) anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

 

Grau

0

4

8

10

 

 

 

 

 

43       

Evidenciar/Avaliar  se está disponibilizado um canal de comunicação que possibilite aos seus clientes, usuários finais e terceiros reportarem vulnerabilidades de segurança identificadas nos produtos

Grau

0

4

8

10

 

 

 

 

 

44       

Evidenciar/Avaliar que está a garantir que a versão Beta ou não final do software/firmware deixe de funcionar após o lançamento da versão oficial.

 

Grau

0

4

8

10

 

 

 

 

 

45       

Evidenciar/Avaliar que uma versão antigas/anteriores de firmware (desde que versões oficiais e não betas) só deverão funcionar em caso de bug ou problemas identificados na versão final pelo fabricante/fornecedor.

Grau

0

4

8

10

 

 

 

 

 

46       

Evidenciar/Avaliar que está a garantir que seja mínimo o impacto nas atividades dos clientes, usuários finais e terceiros durante uma atualização, sugerindo que esta seja feita durante inatividade do equipamento ou via agendamento proposto pelo usuário.

 

Grau

0

4

8

10

 

 

 

 

 

47       

Evidenciar/Avaliar estabelecer um prazo máximo para que todos os equipamentos estejam atualizados após o lançamento de uma nova versão de software/firmware, podendo em alguns casos não depender de intervenções de usuário para essa atualização.

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

48       

Evidenciar/Avaliar que caso algum problema ocorra durante a atualização de firmware/software o equipamento seja capaz de restaurar as ultimas configurações válidas garantindo o seu correto funcionamento.

 

Grau

0

4

8

10

 

 

 

 

 

Disponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa, 
para: 

49       

Evidenciar/Avaliar que está disponível como informar sobre novas vulnerabilidades identificadas em seus produtos, medidas de mitigação e correções de segurança associadas.

Grau

0

4

8

10

 

 

 

 

 

50       

Evidenciar/Avaliar que está disponível  e mantido histórico de: vulnerabilidades identificadas, medidas de mitigação e correções de segurança.

Grau

0

4

8

10

 

 

 

 

 

51       

Evidenciar/Avaliar que está disponível e permitido acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos.

Grau

0

4

8

10

 

 

 

 

 

52       

Evidenciar/Avaliar que está disponível os manuais e outros materiais com orientações relativas à configuração, atualização e uso seguro dos equipamentos.

Grau

0

4

8

10

 

 

 

 

 

 

 

 

Requisitos  da Instrução Normativa número 4 - Segurança Cibernética que devem ser adotados no estabelecimento para os equipamentos utilizados nas redes 5G.

53       

Evidenciar / Avaliar que os serviços prestados e os equipamentos utilizados cumpram os protocolos de comunicação e as especificações técnicas de infraestrutura reconhecidos pela Agência Nacional de Telecomunicações ou, na sua ausência, aqueles estabelecidos pela Associação Brasileira de Normas Técnicas (ABNT) ou reconhecidos internacionalmente;
 

Grau

0

4

8

10

 

 

 

 

 

54       

Evidenciar / Avaliar se está disponível nos equipamentos a serem utilizados pela empresa provedora de serviços  ao menos os padrões nos moldes do SEC009 (Multi-tenant hosting management security) e do SEC002x (Security feature management of open source software), definidos pela ETSI (European Telecommunications

 

Grau

0

4

8

10

 

 

 

 

 

55       

Evidenciar / Avaliar se utiliza o protocolo IPV6, a fim de se evitar o tráfego de dados forjados, sem prejuízo da proteção da origem dos dados trafegados

Grau

0

4

8

10

 

 

 

 

 

 

56       

Evidenciar / Avaliar se os softwares utilizados nos equipamentos de infraestrutura de redes 5G são abertos e se são passíveis de auditoria em termos de segurança;

 

Grau

0

4

8

10

 

 

 

 

 

57       

Evidenciar / Avaliar se o produto / Sistema passou por um processo de auditoria que assegurem a segurança cibernética dos produtos / sistemas utilizados na rede 5G, podendo ser fornecidos de forma conjunta com as prestadoras de serviços e empresas interessadas em fornecer tecnologia 5G;

Grau

0

4

8

10

 

 

 

 

 

58       

Evidenciar / Avaliar se o equipamento não afeta os requisitos de segurança da informação, quais sejam: disponibilidade, integridade, e confidencialidade na atividade de tráfego na rede 5G.

 

Grau

0

4

8

10

 

 

 

 

 

59       

Evidenciar / Avaliar se os equipamentos dispõem de mecanismos que possibilitem inspeção, inclusive a sua auditoria, em equipamentos em produção, até mesmo com a retirada de hardware  para avaliação em laboratório;

Grau

0

4

8

10

 

 

 

 

 

60       

Evidenciar / Avaliar se o equipamento dispõe de facilidade para  registrar o estado de configuração dos equipamentos de sua rede (resultado do gerenciamento de configuração), contendo informações como topologia de rede, versões de hardware e de software dos equipamentos, a fim de auxiliar a atividade de auditoria

 

Grau

0

4

8

10

 

 

 

 

 

 

 

 

CRITÉRIO DE AVALIAÇÃO

0 (zero) pontos

INACEITÁVEL

não apresentou os requisitos mínimos.

4 (quatro) pontos

INSUFICIENTE

apresentou os requisitos mínimos, mas contendo erros ou omissões que caracterizam conhecimento insuficiente dos assuntos , não satisfazendo adequadamente às funcionalidades exigidas;

8 (oito) pontos

BOM

apresentou os requisitos mínimos e conhecimento suficiente dos assuntos, satisfazendo adequadamente às funcionalidades exigidas;

10 (dez) pontos

EXCELENTE

apresentou os requisitos mínimos e conhecimento aprofundado, demonstrando evidências em atuar com desempenho sólido e segurança na melhoria das funcionalidades exigidas. Funções que apesar de não requeridas agregam valor aos requisitos específicos,

 

 

 

Nota:- Coma soma destes pontos pode ser criado critérios para comparação dos  produtos

 

 

 

Contribuição da ABRAC CT-TELECOM

 

Esclarecimentos adicionais:-

 

A declaração de conformidade deve ser analisada e ter uma avaliação de conformidade do produtos / software x versus documentos apresentados. Deve ser feito por organismos credenciados no INMETRO / Anatel e com escopo adequado a esta atividade.

 

ENTREGAVEL:- Relatório Garantindo que o produto / serviço esta devidamente avaliado quanto a SEGURANÇA CIBERNETICA . Requisitos mínimos especificados pela Anatel.

 

 

 

RECEBIMENTO / ACEITAÇÃO DE AUTO DECLARAÇÃO DE PRODUTOS E SERVIÇOS

 

1)      Utilizar organismo com escopo para este trabalho técnico  no ANATEL / INMETRO

 

2)      Empresa Solicitante com autorização legal na atividade que especifica a sua declaração de conformidade.

 

3)      Profissional Especialista com acervo  no seu conselho – atuação profissional coberto pela lei

 

4)      Analise da consistência dos documentos técnicos apresentados para suportar sua Declaração de Conformidade e se o produto ensaiado são idêntico ao que pretende ser comercializar no Brasil .

 

5)      VALIDAR A AUTO DECLARAÇÃO PARA ANATEL

  

Justificativa:

Não estamos conseguindo anexar os itens a itens então colocamoa toda a contribuição no anexo acima. em nome da ABRAC - Associação Brasileira de Avaliação da Conformidade

 Item:  1. OBJETIVO

1.1.Estabelecer requisitos mínimos de segurança cibernética para equipamentos terminais que se conectam à Internet e para equipamentos de infraestrutura de redes de telecomunicações, visando minimizar vulnerabilidades por meio de atualizações de software/firmware ou por meio de recomendações em configurações e em seus mecanismos de gerenciamento remoto.

Contribuição N°: 12
ID da Contribuição: 92536
Autor da Contribuição: Grace Kelly de Cassia Caporalli
Data da Contribuição: 12/05/2020 09:53:45
Contribuição:

MANIFESTAÇÃO: Entendemos que os requisitos mínimos de segurança cibernética dispostos nessa minuta de ato devem ser aplicáveis somente aos equipamentos de infraestrutura de redes de telecomunicações, excluindo-se expressamente os terminais de acesso, bem como os dispositivos de IoT. Portanto, a redação do Item 1.1. deverá ser revista nesse sentido, sendo o mais precisa possível.

Ademais, quanto aos equipamentos de infraestrutura de redes de telecomunicações, sugerimos que a ANATEL considere também como adequados aqueles que estejam em conformidade com todas as disposições previstas no LAC-BCOP.

Justificativa:

JUSTIFICATIVA: A Abinee entende que iniciativas voltadas para o estabelecimento de requisitos mínimos de segurança devem ser desenvolvidas cautelosamente para evitar que sejam impostos os mais variáveis requisitos, muito dos quais inviáveis, nas diversas granularidades das redes de telecomunicações. Tal cenário poderia inadvertidamente frear o desenvolvimento tecnológico no país.

A sugestão de arcabouços normativos distintos para infraestrutura de redes de telecomunicações e para terminais e dispositivos na ponta é fundamental para a elaboração de uma política equilibrada, respeitando as naturezas distintas de tais produtos. As redes de telecomunicações são compostas por diferentes camadas de operação, fazendo com que a abordagem sobre requisitos mínimos de segurança cibernética mais apropriada seja aquela voltada a tratar das especificidades de cada uma delas, que por vezes, permitem de fato a implementação de alguns controles granulares por aquele que opera os produtos e em outras não.

Como exemplo, podemos citar dispositivos que, devido seu propósito único e/ou recursos limitados, como é o caso dos  medidores em redes Smartgrids para leitura de consumo de eletricidade  não dispõem de uma granularidade que possibilite os usuários finais a mexer em sua interface. O que não quer dizer que os equipamentos da rede smargrid não permitam, ao detentor da rede, implementar alguns controles nessa camada.

É fundamental que possíveis requisitos mínimos de segurança para dispositivos de IoT sejam desenvolvidos considerando as especificidades desse ecossistema, a fim de evitar que sejam criadas barreiras onerosas que indesejavelmente poderão inviabilizar a oferta de produtos, equipamentos e serviços baseados na oferta de conectividade máquina-a-máquina.

Neste cenário, a homologação de dispositivos IoT deve ter conformidade não somente com requisitos regulamentados de comunicação, mas considerando também novos requisitos em aspectos de segurança, que são principalmente de alerta/logging, autenticação, criptografia, segurança física e segurança de plataforma, levando em consideração seus propósitos e/ou recursos limitados. Para o contexto brasileiro, seria preferível que a regulamentação fizesse referência a adoção de boas práticas ou requisitos internacionalmente aceitos do que uma lista prescritiva de requisitos próprios e engessados no contexto de uma regulamentação.

Como referência internacional, citamos os EUA que para certificar requisitos de segurança, permite que diversos laboratórios acreditados ofereçam homologação de produtos IoT a partir de “pacote de testes” baseado em orientações emergentes de projetos de segurança e de alianças voltadas para IoT, compondo assim um pacote de requisitos oferecido e testado pelo laboratório acreditado. Como exemplo, cita-se o laboratório ICSA Lab [1] que se baseia em três diretrizes, a saber: do OWASP Open Web Application Security Project, do IIC Reference Architeture e da arquitetura do Online Trust Alliance. Todas essas diretrizes apresentam requisitos e testes considerados necessários para segurança em IoT.

[1] https://www.icsalabs.com/technology-program/iot-testing

 

Contribuição N°: 13
ID da Contribuição: 92564
Autor da Contribuição: JULIO RODRIGUES
Data da Contribuição: 14/05/2020 09:35:51
Contribuição:

SONY BRASIL LTDA 

Responsável por Conformidade de Produto

1) O documento deve esclarecer o escopo dos produtos abrangidos pela regulamentação. Ou seja equipamentos terminais que se conectam à Internet seriam aqueles definidos na lIsta de Referência de Produtos para Telecomunicação da Anatel, ou abrangeria outros produtos fora da Lista?

2) Os requisitos de segurança cibernética devem estar em harmonia com os regulamentos de outros países (Europa, USA, Japão, etc) caso contrário estaremos criando barreiras técnicas para importação e utilização de novos equipamentos / tecnologias

Justificativa:

1) Não está claro no documento que o escopo de produtos seriam aqueles definidos na Lista de Referência de Produtos para Telecom da Anatel ou abrangeria outros produtos / equipamentos fora da lista de referência. A abrangência de produtos deve estar claro na regulamentação.

2) Evitar barreiras técnicas.

Contribuição N°: 14
ID da Contribuição: 92565
Autor da Contribuição: Fernando Capez
Data da Contribuição: 14/05/2020 11:57:40
Contribuição:

Prezados,

Entendemos oportuno apresentarmos preliminarmentes algumas ponderações  acerca da presente consulta pública.

A presente Consulta Pública, que trata de requisitos mínimos de segurança cibernética para equipamentos terminais que se conectam à internet e para equipamentos de infraestrutura de redes de telecomunicações, tem como objetivo minimizar vulnerabilidades, por intermédio de atualizações de software/firmware ou por recomendações em configurações e em seus mecanismos de gerenciamento remoto.

Segundo órgão regulador, a proposta está alinhada com as disposições do Decreto n.º 10.222, de 5 de fevereiro de 2020, que aprovou a Estratégia Nacional de Segurança Cibernética, e também pela Instrução Normativa nº 4, de 26 de março de 2020, que dispõe sobre os requisitos mínimos de Segurança Cibernética que devem ser adotados no estabelecimento das redes 5G.

Em relação a mitigação das vulnerabilidades dos equipamentos de telecomunicações pretendidas pelo instrumento regulatório, entendemos que os dispositivos conectados à internet, além da sua funcionalidade, devem proporcionar segurança, não só dos equipamentos, como também dos sistemas e dos dados dos usuários.

Continuando, o documento INFORME Nº 6/2020/ORCN/SOR que acompanha a Consulta Pública, em seu item 5.3. DA AVALIAÇÃO DE RISCOS, apresenta as seguintes opções de ação regulatória: a) Não estabelecimento de requisitos mínimos de segurança cibernética, mantendo o cenário atual; b) Estabelecimento de requisitos mínimos de segurança cibernética para certificação de produtos; e c) Estabelecimento de procedimento de declaração de conformidade a requisitos mínimos de segurança cibernética para produtos de telecomunicações.

Agência optou pelo item “c” – Declaração de Conformidade – para elaboração da Minuta do Normativo proposto, baseado em uma suposta harmonização entre prós e contras do método, com garantia da segurança das redes e dos usuários sem representar grandes barreiras técnicas e econômicas para colocação de novos produtos e tecnologias no país.

Salienta-se que, no contexto da Declaração de Conformidade, os produtos não serão submetidos a ensaios de certificação quanto aos requisitos de segurança cibernética, o que consideramos temerário, tendo em vista a possibilidade de colocação no mercado de consumo de produtos vulneráveis a ataques cibernéticos.

Quanto a isto, a ANATEL procura mitigar esta questão afirmando que, caso se evidencie a existência de equipamento que não esteja em conformidade com os requisitos técnicos, a Agência poderá suspender a homologação do equipamento até que as vulnerabilidades apontadas ou o potencial risco à segurança dos serviços para telecomunicações sejam sanadas.

Frisa-se que tal avaliação seria feita após um procedimento de fiscalização ou por denúncias de consumidores, ou seja, num momento posterior à colocação do produto no mercado, lapso de tempo em que os usuários ficariam expostos aos vícios do produto, a exemplo de abertura remota de fechaduras eletrônicas, hackeamento de computadores, invasão em Smart TV expondo a privacidade das pessoas. São problemas reais, com potencial de causar ao consumidor impactos materiais, patrimoniais e físicos, além da exposição dos seus dados privativos.

Ora, o Código de Defesa do Consumidor, em seu art. 6º, inciso I, dispõe que o consumidor possui o direito básico de proteção à sua vida, saúde e segurança contra os riscos provocados por práticas no fornecimento de produtos e serviços considerados perigosos ou nocivos. Esse direito reforça a proteção à vida, saúde e segurança, estabelecida pelo caput do art. 4º da lei.

Aliás, a proteção a vida, saúde e segurança são direitos fundamentais inalienáveis, indisponíveis e indissociáveis, previstos no art. 5º da Constituição Federal. O Código de Defesa do Consumidor estabelece tais disposições fundamentais para, de forma expressa, proteger o consumidor de práticas no fornecimento de produtos e serviços que possam lhe causar danos e / ou que abalem a sua integridade física.

Essas vulnerabilidades poderão resultar em um produto, processo ou serviço inseguro, ou seja, entendido como aquele que não oferece a segurança que dele razoavelmente se espera, de maneira que não poderiam ser colocados no mercado de consumo, justamente pelos riscos que possam causar ao usuário consumidor.

Vale dizer que o mesmo Diploma Legal, em seu art. 12, determina a responsabilidade objetiva dos fornecedores, ou seja, independente de culpa, bastando apenas que seja constatado a ocorrência de dano ao consumidor, resultando assim no dever do fornecedor em responder por todos os prejuízos causados ao consumidor.

Posto isto, entendemos que o estabelecimento de requisitos mínimos de segurança cibernética deverá ser feito através de certificação de produto, visando uma maior segurança aos consumidores, uma vez que o processo de avaliação da conformidade é baseado em ensaio de tipo, onde a certificação é realizada para modelos de equipamentos.

Conceitualmente, a Avaliação de Conformidade é um processo sistematizado, acompanhado e avaliado, de forma a propiciar adequado grau de confiança de que um produto, processo ou serviço, atende a requisitos pré-estabelecidos em normas e regulamentos técnicos.

Estas normas e regulamentos técnicos têm como escopo garantir à sociedade, meios eficazes para comprovar a qualidade dos produtos, processos e serviços utilizados, trazendo transparência nas relações estabelecidas entre fornecedores e seus consumidores.

Do ponto de vista consumerista, o processo de avaliação de conformidade é de suma importância pois assegura que a certificação e a homologação sejam feitas através requisitos pré-estabelecidos, permitindo que o consumidor realize à sua aquisição de produtos, processos e / ou serviços munido de informações claras, precisas, objetivas e ostensivas, para a sua correta e segura utilização, prevenindo-se de potenciais riscos.

Vale dizer que o próprio Código de Defesa do Consumidor, em seu art. 39, inciso VIII, proíbe o fornecedor de colocar no mercado de consumo, qualquer produto ou serviço em desacordo com as normas técnicas pertinentes e obrigatórias, expedidas por órgão competente, sujeitando seus infratores as sanções administrativas em caso de não observância da normatização.

Importante salientar, após o inicio da presente Consulta Pública, foi publicado o Ato nº 2220, de 20 de abril de 2020, que aprovou procedimento operacional que estabelece as regras e documentos para a avaliação da conformidade de produto para telecomunicações na modalidade de Certificação, conforme disposto no Regulamento de Avaliação da Conformidade e Homologação de Produtos para Telecomunicações.

Diante do exposto, a Fundação Procon / SP entende como fundamental que a Agência promova meios rígidos de certificação e homologação destes equipamentos, no que tange aos requisitos de segurança contra ataques cibernéticos.

Continuando, também entendemos por equivocado a obrigação de provimento de atualizações de segurança por, no mínimo, dois anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, pois os

equipamentos de telecomunicações são bens duráveis, portanto, a sua permanência em uso pode-se perpetrar por longo período, não sendo razoável que em tão pouco tempo haja a descontinuidade de suporte para novas atualizações de segurança, o que colocaria o produto vulnerável a falhas de segurança por falta de atualização ou correção.

Nesse sentido, as atualizações de segurança devem ser disponibilizadas enquanto o bem estiver em distribuição no mercado de consumo, bem como a manutenção do procedimento por, no mínimo, 5 (cinco) anos, após cessada a sua comercialização, levando também em consideração a vida útil de cada equipamento, o que torna o dispositivo uma norma em aberto, possibilitando ao consumidor o reclamo dos seus direitos, caso esteja de posse de produto descontinuado, vulnerável à ataque cibernético.

Dessa forma, a Fundação Procon / SP, vem através da presente Manifestação Técnica, apresentar sua contribuição tendo como fundamento à aplicação do Código de Defesa do Consumidor e legislações correlatas, nas relações de consumo que envolvem produtos voltados aos meios de comunicação.

Justificativa:

a justificativa está contida na contribuição

Contribuição N°: 15
ID da Contribuição: 92579
Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
Data da Contribuição: 14/05/2020 17:04:24
Contribuição:

A BSA The Software Alliance[1] agradece a oportunidade de submeter comentários à Anatel em sua Consulta Pública nº 13 (doravante, a “consulta”), relativa aos requisitos mínimos de segurança cibernética propostos para terminais conectados à Internet e para equipamentos de infraestrutura de rede de telecomunicações. A BSA é a principal defensora da indústria global de software perante governos e no mercado internacional. O software capacita tecnologias que melhoram nossas vidas pessoais e negócios em todos os setores, e os membros da BSA estão na vanguarda da inovação habilitada por software, incluindo a Internet das Coisas, blockchain e inteligência artificial (IA). Além disso, os membros da BSA são pioneiros no campo da segurança de software, liderando o desenvolvimento de princípios relacionados ao ciclo de vida de desenvolvimento de software seguro (SDLC) e segurança por projeto.

A comunidade de software desenvolveu métodos e ferramentas para ajudar os desenvolvedores de software a abordar aspectos importantes da segurança de software, incluindo princípios de segurança, processos seguros do ciclo de vida do desenvolvimento e padrões reconhecidos internacionalmente, e os membros da BSA foram pioneiros em muitas das melhores práticas de segurança de software utilizadas na indústria hoje. A BSA reconhece que a segurança efetiva requer uma abordagem abrangente e informada sobre riscos, que combina considerações de segurança individuais em uma estrutura holística e ao longo do ciclo de vida. Consequentemente, a BSA desenvolveu e publicou o BSA Framework for Secure Software, uma ferramenta inédita para descrever e avaliar a segurança de software por meio de uma metodologia flexível, baseada em resultados e informada sobre riscos. A estrutura da BSA aborda os processos organizacionais e os recursos de segurança do produto para informar e avaliar a segurança do software durante todo o seu ciclo de vida.

A BSA desenvolveu essa estrutura porque nossos membros compartilham o compromisso da Anatel de melhorar as práticas de segurança em todo o setor de TI. No desenvolvimento da estrutura, um dos desafios mais significativos que enfrentamos foi contemplar como um conjunto comum de princípios de segurança poderia ser aplicado à enorme diversidade de produtos orientados por software, variando de aplicativos da Web simples a sistemas de controle industrial complexos. Esse desafio foi ampliado pelo reconhecimento de que, além de um espectro diversificado de funções e complexidade, os projetos de software também são desenvolvidos usando dezenas de diferentes linguagens de codificação e processos de desenvolvimento. Reconhecemos que a chave para abordar a segurança em um cenário tão diversificado é adequar as medidas de segurança a uma avaliação consciente dos riscos. Por esse motivo, desenvolvemos nossas diretrizes de segurança de software como uma estrutura baseada em riscos, orientada para resultados e orientada por flexibilidade suficiente para permitir decisões baseadas em riscos sobre como alcançar esses resultados.


Essa experiência contorna os comentários da BSA sobre os padrões de segurança cibernética propostos. A BSA congratula a Anatel pelo seu esforço em aprimorar a segurança no setor de tecnologia da informação (TI) e apoia muitos aspectos da proposta; no entanto, estamos preocupados que a proposta não tenha flexibilidade suficiente para abarcar a diversidade da indústria de tecnologia. Fornecemos os seguintes comentários como sugestões construtivas para melhorar os padrões de segurança cibernética com essa perspectiva em mente.

Os padrões de cibersegurança propostos na consulta se aplicariam a todos os "equipamentos terminais que se conectam aos equipamentos de infra-estrutura de redes de Internet e telecomunicações, em suas versões finais destinadas à comercialização". Esse aplicativo cobriria um escopo incrivelmente amplo de dispositivos de TI, incluindo dispositivos de Internet das Coisas (IoT) para consumidores e industriais, dispositivos de computação em geral, dispositivos móveis e sistemas de controle industrial. Esses dispositivos enfrentarão um amplo espectro de riscos, e estamos preocupados com o fato de que tratá-los da mesma forma imponha requisitos desnecessariamente onerosos em dispositivos de baixo risco e pode limitar a flexibilidade na abordagem da segurança em ambientes mais sofisticados

Para enfrentar esse desafio, recomendamos que a consulta seja alterada para distinguir entre grandes classes de dispositivos. Primeiro, os dispositivos IoT do consumidor devem ser tratados de maneira diferente da IoT industrial. Criar categorias separadas para a Internet das Coisas industrial e do consumidor permitiria abordagens de segurança mais adaptadas às características específicas de cada categoria. Por exemplo, dispositivos de IoT de consumidor comuns, como alto-falantes sem fio ou alarmes de incêndio, podem ter interfaces de usuário limitadas que tornam mais difíceis de incorporar medidas de segurança que exigem configurações implementáveis & 8203;& 8203;pelo usuário. Em alguns casos, os dispositivos de IoT dos consumidores, como sensores, são tão básicos que podem nem incluir um sistema operacional; nesses casos, a implementação de requisitos de segurança considerados de outra forma (como exigir que o dispositivo seja detectável) pode realmente aumentar a superfície de ataque do dispositivo. Ao mesmo tempo, os dispositivos de IoT industriais podem exigir mais flexibilidade na implementação de medidas de segurança para dar conta dos ambientes complexos e interconectados nos quais eles costumam ser instalados.

Segundo, os dispositivos IoT devem ser tratados de maneira diferente dos dispositivos de computação em geral. Em muitos casos, os dispositivos de computação em geral terão a capacidade de executar mais e mais diversas operações sensíveis e armazenar e processar dados mais sensíveis do que os dispositivos da IoT, que geralmente serão limitados a um conjunto restrito de funções. Como tal, medidas de segurança que podem não ser apropriadas para dispositivos IoT podem ser altamente desejáveis & 8203;& 8203;para dispositivos de computação em geral. Por exemplo, os dispositivos IoT de funcionalidade limitada podem não exigir nenhum tipo de controle de acesso, enquanto os dispositivos de computação geral podem exigir controles de acesso robustos, incluindo fortes recursos de gerenciamento de identidade e controles que segregam o acesso a diferentes funções no software do dispositivo.

 


[1] BSA’s members include:  Adobe, Akamai, Apple, Autodesk, Bentley Systems, Box, Cadence, CNC/Mastercam, DataStax, DocuSign, IBM, Informatica, MathWorks, Microsoft, Okta, Oracle, PTC, Salesforce, Siemens PLM Software, Slack, Splunk, Symantec, Trend Micro, Trimble Solutions Corporation, Twilio, and Workday.

Justificativa:

Em geral, a BSA recomenda que as definições técnicas da consulta sejam alinhadas ao máximo possível com as definições estabelecidas em padrões internacionalmente reconhecidos; por exemplo, a ISO / IEEE 24765 que cataloga definições técnicas de vários padrões relevantes.

Recomendamos que a consulta seja alterada para distinguir entre grandes classes de dispositivos. Primeiro, os dispositivos IoT do consumidor devem ser tratados de maneira diferente da IoT industrial. Criar categorias separadas para a Internet das Coisas industrial e do consumidor permitiria abordagens de segurança mais adaptadas às características específicas de cada categoria.

Os dispositivos IoT devem ser tratados de maneira diferente dos dispositivos de computação em geral. Em muitos casos, os dispositivos de computação em geral terão a capacidade de executar mais e mais diversas operações sensíveis e armazenar e processar dados mais sensíveis do que os dispositivos da IoT, que geralmente serão limitados a um conjunto restrito de funções

Contribuição N°: 16
ID da Contribuição: 92588
Autor da Contribuição: Wilson Cardoso
Data da Contribuição: 14/05/2020 18:11:41
Contribuição:

Agradecemos a possibilidade de participar nesta Consulta Pública, e a aprorveitamos a oportunidade mais que oportuna de explorar este tema que é fundamental para a segurança do estado, dos direitos dos utilizadores das rede brasileiras de telecomunicações, da soberaia nacional e com a introdução próxima do 5G das cadeias produtivas.

Entendemos que os requisitos mínimos de segurança cibernética, objeto desta CP, devem ser aplicáveis somente aos equipamentos de infraestrutura de redes de telecomunicações. Os equipamentos terminais apresentam uma multitude de aplicações desde simples sensores, passando por smartphones até complexas gateways de usuário, que apresentam normas internacionais que são atualizadas constantemente.

 

Justificativa:

Requisitos comuns para equipamentos de infraestrutura e para equipamentos terminais apresentam caracteristicas e dimensões completamente distintas. 

 

Contribuição N°: 17
ID da Contribuição: 92632
Autor da Contribuição: Mariana Giostri M. Oliveira
Data da Contribuição: 15/05/2020 18:59:39
Contribuição:

Estabelecer requisitos mínimos de segurança cibernética para equipamentos terminais que se conectam à Internet e para equipamentos de infraestrutura de redes de telecomunicações, visando minimizar vulnerabilidades por meio de atualizações de software/firmware ou por meio de recomendações em configurações e em seus mecanismos de gerenciamento remoto.

Justificativa:

Conforme explorado na parte introdutória de nossa contribuição, entendemos que a melhor política pública para garantir a segurança cibernética não é por meio da certificação individual de todo e qualquer elemento da rede, tendo em vista que tal abordagem poderá desconsiderar uma visão holística do funcionamento do sistema, e levar a imposição de custos muito altos em dispositivos de baixa complexidade.

Portanto, de modo a equacionar essa questão, sugerimos que o texto da proposta de regulamento seja revisto de modo a se limitar, exclusivamente,  a equipamentos de infraestrutura de rede de telecomunicações que possuam um papel com algum grau de complexidade na arquitetura da rede. Limitando o escopo de aplicação do ato em questão aos equipamentos de infraestrutura de redes de telecomunicações, vale ressaltar que essa camada da rede conta com uma enorme variedade de dispositivos, de diversos grupos e com funcionalidades diferentes.

Entendemos, ainda, legítima a preocupação da Agência  com a segurança do ecossistema como um todo.

Sendo assim, sugerimos a constituição de um grupo de trabalho, composto por membros da Agência e da indústria, para empenhar esforços na discussão de item por item dos requisitos futuramente estabelecidos, tendo mente uma abordagem de gestação de risco, os custos, o perfil de cada classe de equipamento e, consequentemente, a viabilidade da incorporação de tais mecanismos em cada uma delas.

Contribuição N°: 18
ID da Contribuição: 92654
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:06:37
Contribuição:

   

1.2. Atender aos requisitos de segurança cibernetica para os produtos do item 1.1 contidos na Instrução Normativa Nº 4, DE 26 DE MARÇO DE 2020 do GSI.  

 

 

  

Justificativa:

Justificativa – incluir item 1,2,  -  Considerando que a Instrução Nortativa 5 da GSI foi publicada apos a CP13 entende,ps que e importante a sua referencia e atendimento 

Contribuição N°: 19
ID da Contribuição: 92668
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:14:27
Contribuição:

 

1.2. Atender aos requisitos de segurança cibernetica para os produtos do item 1.1 contidos na Instrução Normativa Nº 4, DE 26 DE MARÇO DE 2020 do GSI.  

  

Justificativa:

 

Justificativa – incluir item 1,2,  -  Considerando que a Instrução Nortativa 5 da GSI foi publicada apos a CP13 entende,ps que e importante a sua referencia e atendimento.

  

Contribuição N°: 20
ID da Contribuição: 92676
Autor da Contribuição: EMILIO CARLOS REBOUCAS SANTANA LOURES
Data da Contribuição: 16/05/2020 19:25:43
Contribuição:

A Intel Semicondutores do Brasil Ltda. (Intel), subsidiária integral da Intel Corporation, agradece pela oportunidade de enviar comentários à Consulta Pública no 13 de 2020 da ANATEL sobre os requisitos mínimos de segurança cibernética para equipamentos de telecomunicações. Esperamos que a ANATEL mantenha o diálogo estreito entre os líderes do setor e a agência para fortalecer a segurança cibernética e nos colocamos disponíveis para quaisquer perguntas e discussões de acompanhamento.

A Intel está entre as líderes mundiais em computação e inovação tecnológica. A empresa projeta e constrói tecnologias essenciais que servem de base para produtos de consumo, sistemas comerciais e equipamentos de infraestrutura. A Intel também investe no desenvolvimento e adoção de padrões globais que permitiram avanços e interoperabilidade de produtos e sistemas em todo o mundo, inclusive na área de equipamentos terminais e comunicação.

Na busca por aprimorar a norma proposta, apresentamos à ANATEL os comentários abaixo:

Comentários gerais

A complexidade e a diversidade tecnológica dos sistemas, bem como os desafios de segurança, continuarão a evoluir rapidamente. Dessa forma, políticas e requisitos precisarão contar fortemente com princípios-chave adotados no campo da política de segurança, como promover a harmonização (evitar a fragmentação), a neutralidade tecnológica / design (regulamentação baseada em princípios) e a adoção de padrões internacionais abertos, garantindo flexibilidade para lidar com questões emergentes, evitando uma abordagem única e apoiando a inovação e as abordagens baseadas em avaliação de risco.

Oferecer incentivos para adoção voluntária de padrões amplamente adotados e melhores práticas internacionais, construídos por consenso, escaláveis, que são desenvolvidos com a indústria e contribuição de especialistas, rotineiramente atualizados – é um pilar fundamental das políticas de segurança, buscando enfrentar desafios complexos em um ecossistema em rápida evolução tecnológica.

Entendemos que a presente norma deveria focar-se exclusivamente nos equipmentos designados como CPE, conforme sua relação de definições. Em relação a IoT e outros ecossistemas, várias associações na área de tecnologia publicaram recomendações de princípios de políticas que devem ser considerados por formuladores de políticas que buscam estabelecer requisitos mínimos de segurança nessas áreas.

  • Recommendations for IoT Device Manufacturers: Foundational Activities and Core Device Cybersecurity Capability Baseline (2nd Draft) https://csrc.nist.gov/publications/detail/nistir/8259/draft.
  • The C2 Consensus on IoT Device Security Baseline Capabilities (in revision), https://securingdigitaleconomy.org/wp-content/uploads/2019/09/CSDE_IoT-C2-Consensus-Report_FINAL.pdf.
  • ISO/IEC 27402 (in process) (IoT security and privacy – Device baseline requirements).

Alguns desses recursos são relevantes para consideração, pois apresentam uma abordagem para definir os requisitos mínimos de segurança, mas se concentram em um setor diferente (ecossistema de IoT) do que entendemos ser objeto da presente norma. As referências a IoT deveriam ser retiradas da norma em consulta.

Utilizar padrões internacionais orientados por consenso e as melhores práticas de segurança existentes e evitar a fragmentação de definições e requisitos

Políticas e modelos podem utilizar e se referir a padrões internacionais amplamente adotados, orientados por consenso, e às melhores práticas, desenvolvidos com ampla contribuição da indústria e de especialistas - e são atualizados regularmente - em vez de descrever requisitos excessivamente prescritivos em normas que podem se tornar desatualizadas. Os padrões amplamente adotados podem facilitar a interoperabilidade entre os ecossistemas, promover o investimento e a concorrência, melhorar a colaboração internacional, promover a auto-atestação / certificação e permitir soluções escaláveis & 8203;& 8203;e econômicas.

Neutralidade de design e abordagens baseadas em avaliação de risco

Nós encorajamos a ANATEL a considerar maior flexibilidade aos fabricantes na adotação de requisitos com base em normas internacionais estabelecidas / melhores práticas (promulgadas por organização de desenvolvimento de padrão global reconhecida pela indústria) em vez de delinear requerimentos específicos e regulação. Essa adoção pode se basear em uma avaliação de risco dos dispositivos em questão para determinar os recursos de segurança relevantes / necessários . A título de exemplo, as estruturas propostas atualmente (em padrões / melhores práticas), que estabelecem requisitos básicos de segurança em ambientes diferentes e distintos, como a IoT, partem de práticas estabelecidas em avaliações de riscos e padrões internacionais.

Essas normas / práticas recomendadas descrevem mais detalhadamente e explicam que a aplicabilidade de recursos / requisitos, incluindo recursos mínimos, depende de vários fatores [1]. Propostas atuais de regulação e legislação já em vigor no ecossistema da IoT especificamente evitam delineamentos prescritivos de requisitos e são baseadas em princípios. Recomendamos ainda que a norma proposta se concentre no equipamento terminal necessário para a infraestrutura das redes de telecomunicações, especificamente, no CPE (descrito abaixo), excluindo expressamente os dispositivos de IoT . Outras jurisdições, que consideraram os esforços semelhantes em padrões técnicos (em oposição a legislação) para equipamentos terminais, geralmente excluiram dispositivos IoT e se concentraram em princípios de alto nível[2]. Muitas das disposições propostas na presente consulta podem não ser apropriadas para todos os dispositivos no ecossistema da IoT, considerando-se várias práticas, estruturas e padrões construídos por consenso, desenvolvidos globalmente – especificamente no contexto de requisitos / capacidades de segurança básicos para IoT, além de divergir substancialmente de tais esforços [3]. Vários requisitos podem divergir ainda mais de padrões internacionais amplamente adotados sobre processos coordenados de divulgação e tratamento de vulnerabilidades, à exemplo do estabelecimento de prazos para o desenvolvimento da mitigação de vulnerabilidades[4].

É muito provável que regulamentos divergentes dos padrões internacionais prejudiquem a interoperabilidade e, em última análise, possam restringir a capacidade das empresas locais de competir nos mercados globais e prejudicar o objetivo que a legislação busca alcançar, ou seja, promover a segurança – dada a natureza global da cadeia de suprimentos do ecossistema de TI e processos coordenados de divulgação e enfrentamento das vulnerabilidades.

[1] O consenso C2 sobre os recursos da linha de base de segurança de dispositivos IoT, 8; Veja também NISTIR 8259 (Rascunho 2º ).

[2] Ver Japão, Diretrizes para certificação padrão de equipamentos terminais com base no Telecommunications Business Act (Primeira edição) (22 de abril de 2019).

[3] Recomendações para fabricantes de dispositivos IoT: atividades básicas e linha de base de capacidade de segurança cibernética de dispositivos principais (2º rascunho) https://csrc.nist.gov/publications/detail/nistir/8259/draft ; O consenso C2 sobre os recursos de linha de base de segurança de dispositivos IoT (em revisão), https://securingdigitaleconomy.org/wp-content/uploads/2019/09/CSDE_IoT-C2-Consensus-Report_FINAL.pdf ; ISO / IEC 27402 (em processo) (segurança e privacidade da Internet das coisas - requisitos da linha de base do dispositivo).

[4] ISO / IEC 29147 (2018) (divulgação de vulnerabilidades) e ISO / IEC 30111 (2019) (processos de tratamento de vulnerabilidades). A natureza global da tecnologia e a colaboração necessárias para esse processo são reconhecidas há muito tempo , bem como a importância da adoção de padrões internacionais. Consulte ENISA, Guia de Boas Práticas sobre Divulgação de Vulnerabilidades: Dos Desafios às Recomendações (2016), na p. 9, Governo do Reino Unido, DCMS, Código de Práticas de Segurança da IoT do Consumidor aos 18 anos e CISA do DHS dos EUA, Diretiva Operacional Vinculativa 20-01 27 de novembro de 2019 (rascunho), “Desenvolva e publique uma política de divulgação de vulnerabilidades”.

Justificativa:

Presente no corpo da contribuição.

Contribuição N°: 21
ID da Contribuição: 92682
Autor da Contribuição: Karla Menandro Pacheco da Silva
Data da Contribuição: 17/05/2020 10:29:18
Contribuição:

Excluir os componentes veiculares do escopo da certificação.

Justificativa:

A Volkswagen entende que esta certificação não deveria abranger os componentes veícular uma vez que os as montadoras possuem processos internos para garantir o cyber security do veículo completo, incluindo seus componentes e não somente aqueles que se conectam à internet.  

Contribuição N°: 22
ID da Contribuição: 92690
Autor da Contribuição: CARLOS JOSE LAURIA NUNES DA SILVA
Data da Contribuição: 17/05/2020 12:21:04
Contribuição:

Prezados Senhores,
 
A Huawei do Brasil vem mui respeitosamente felicitar a Anatel pelo trabalho realizado na preparação desta Consulta Pública. Somos a empresa líder mundial no nosso segmento e que está no Brasil há 22 anos, gerando mais de 1.300 empregos diretos e cerca de 12.000 empregos indiretos. Instalamos uma grande parte das redes 3G, 4G e 4.5G atualmente em operação no país, bem como entregamos com sucesso mais de 600.000 ERBs 5G em todo o mundo. Destacamos também atuação da nossa unidade de Negócios Empresariais com produtos para empresas privadas e governamentais, a unidade de Serviços de Cloud e a unidade de Produtos de Consumo, esta última nos posicionando em segundo lugar global na fabricação de smartphones.

Ao longo desses 22 anos no Brasil temos colaborado sobremaneira com a Agência sempre que chamados a compartilhar a reconhecida experiência global de nossos experts. Dessa forma, entendemos que podemos oferecer ainda mais por meio das contribuições que enviamos em seguida, com o intuito de aprimorar o texto dessa Consulta Pública.

A segurança e confiabilidade de produtos e serviços é um antiga preocupação da Huawei, tratada sistematicamente desde as fases iniciais do projeto e desenvolvimento, passando por sua colocação no mercado e seguindo até o final de seu ciclo de vida. Temos estruturas formais internas, como comitês e departamentos, desde 1999 e nossos funcionários são frequentemente treinados e testados para que tenhamos garantia fim a fim de que atingimos os mais rigorosos requisitos. Trabalhamos globalmente com os principais organismos padronizadores destacando cuidados com Confidencialidade, Integridade, Disponibilidade e Rastreabilidade. 

Cyber security é uma questão tratada com seriedade e transparência pela Huawei e isso se reflete na confiança de nossos clientes e na ausência de eventos de segurança em nossos produtos nos mais de 170 países em que atuamos. 

Contribuições ao documento:

- Com base em todo esse histórico positivo gostaríamos de destacar a importância de adoção de padrões globais, como os desenvolvidos por 3GPP e GSMA NESAS (Network Equipment Security Assurance Scheme), por exemplo.

- Sugerimos também que seja avaliada a conveniência de segmentação desta regulamentação para CPEs, IoT e infraestrutura, por se tratar de produtos por demais diferentes, destinados a usos e usuários muito diversos para serem submetidos a regras comuns.

São nossas contribuições, as quais temos certeza de que serão levadas em consideração pela Anatel visando aprimorar o texto sob consulta.
 
Atenciosamente,
Carlos Lauria
Diretor de Relações Governamentais e Assuntos Regulatórios
HUAWEI DO BRASIL
 

Justificativa:

Conforme texto da Contribuição.

Contribuição N°: 23
ID da Contribuição: 92694
Autor da Contribuição: Tiago Brocardo Machado
Data da Contribuição: 17/05/2020 17:42:04
Contribuição:

A Ericsson parabeniza a ANATEL pela iniciativa de apresentar propostas para os requisitos mínimos de segurança cibernética que os equipamentos destinados a telecomunicações devam apresentar. Suportamos a visão de que os requisitos mínimos de cibersegurança devam ser fragmentados por diferentes setores da indústria de telecomunicações visto que a existem diferenças graduais de complexidade entre os equipamentos utilizados por cada setor.

Ressaltamos a importância de que homologação e certificação e requisitos para tal sejam discutidos num contexto mais amplo, que enderece também padrões, requisitos de rede e de operação dos serviços de telecomunicações.

Propomos, por fim, cibersegurança seja discutido setorialmente como uma possibilidade de autorregulação, uma vez que é um interesse convergente do regulador, provedores de soluções, prestadores de serviços e consumidores finais.

Justificativa:

A Ericsson entende que o escopo de cibersegurança e a discussão relativa à certificação de conformidade de equipamentos de telecomunicações está presente em um contexto muito mais amplo que sua definição com impacto direto nos padrões de desenvolvimento, design e construção de redes de telecomunicações. Desta forma é necessário que exista uma política setorial e regulatória em compasso com a dinâmica do setor, visto que o assunto é de interesse comum do agente regulador, da indústria de infraestrutura, das operadoras de telecomunicações e do consumidor final. Levando isto em consideração sugere-se a criação de grupos de trabalho que consigam endereçar os pontos relativos à cibersegurança de acordo com a seguinte divisão sugerida: 1. Infraestrutura de acesso e transporte; 2. Core e 3. Terminais destinados ao consumidor final (Devices, smartphones, CPE’s, etc). Além disso, a discussão de cibersegurança não deve ficar restrita aos equipamentos, mas também incluir padrões, design e construção de redes e operação de serviços de telecomunicações.

Por se tratar de um tema de interesse comum entre os diferentes atores do mercado, desde o agente regulador até o consumidor final, verifica-se a possibilidade que o tema de cibersegurança possa ser um espaço propício para autorregulação setorial, tema que deve ser amplamente discutido dentro dos grupos de trabalho obedecendo à segmentação acima.

A Ericsson entende que ao preparar uma regulamentação de alcance tão amplo, a ANATEL possa levar o ecossistema brasileiro a um cenário regulatório que é muito leve em certas partes e muito pesado em outras e que. Desta forma recomenda-se a adoção de guideiines que não restringem a inovação em um setor que apresenta  constante inovação, disrupção tecnológica, em vez disso, promova discussões em torno dele em outra oportunidade, priorizando a harmonização global e seguindo estreitamente as discussões internacionais para apoiar um consenso voluntário e orientado pelo setor sobre os principais recursos da linha de base para a cibersegurança baseada em padrões globais.

 Mais informações podem ser consultadas em https://www.ericsson.com/en/security/a-guide-to-5g-network-security

Contribuição N°: 24
ID da Contribuição: 92705
Autor da Contribuição: Sergio Mauro da Silva Maia
Data da Contribuição: 17/05/2020 20:13:57
Contribuição:

Contribuição: Acrescentar ao texto, “desde que os requisitos mínimos não infrijam a legislação brasileira que regula as atividades de tratamento de dados e o uso da Internet no Brasil por meio da previsão de princípios, garantias, direitos e deveres para quem usa a rede”.

 

Justificativa:

Justificativa: Na proposta deste caput, a expressão “recomendações em configurações” pode ser interpretada como uma operação de filtragem e análise de pacotes de dados, o que vai contra ao previsto no Art.9, § 3º da Lei 12.965 (Marco Civil da Internet).

 Item:  2. REFERÊNCIAS

2.1.Regulamento de Avaliação da Conformidade e de Homologação de Produtos para Telecomunicações, aprovado pela Resolução n.º 715, de 23 de outubro de 2019.

2.2.OECD - Enhancing the Digital Security of Products - Draft Scoping Paper (November 2019).

2.3.IEEE Internet Technology Policy Community White Paper - Internet of Things (IoT) Security Best Practices (February 2017).

2.4.IETF - Internet of Things (IoT) Security: State of the Art and Challenges - RFC 8576.

2.5.LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

2.6.ENISA - Baseline Security Recommendations for IoT in the Context of Critical Information Infrastructures (November 2017).

2.7.GSMA IoT Security Guidelines – Complete Document Set.

Contribuição N°: 25
ID da Contribuição: 92537
Autor da Contribuição: Grace Kelly de Cassia Caporalli
Data da Contribuição: 12/05/2020 09:56:03
Contribuição:

MANIFESTAÇÃO 1: Incluir as seguintes referências:

NESAS do GSMA- FS.16 Network Equipment Security Assurance Scheme - Development and Lifecycle Security Requirements
ETSI GS NFV-SEC 001 V1.1.1 (2014-10): Network Functions Virtualisation (NFV); NFV Security; problem Statement.

 

MANIFESTAÇÃO 2: Exclusão dos itens 2.3.; 2.4.; 2.6.; e 2.7.

Justificativa:

JUSTIFICATIVA 1: A fim de enriquecer o debate acerca do tema de segurança cibernética, nós entendemos que os dois documentos listados acima apresentam discussões e práticas internacionais de extrema relevância.

 

JUSTIFICATIVA 2: Na medida em que solicitamos expressamente a exclusão de dispositivos de IoT do escopo de aplicação do ato, sugerimos que haja exclusão das referências que discutam sobre segurança de dispositivos de IoT.

Contribuição N°: 26
ID da Contribuição: 92567
Autor da Contribuição: Fernando Capez
Data da Contribuição: 14/05/2020 12:14:44
Contribuição:

Inclusão

 

2.2. Procedimento Operacional para Avaliação da Conformidade de Produtos para Telecomunicações por Certificação, aprovado pelo Ato nº 2220, de 20 de abril de 2020.

Justificativa:

Entendemos que a avaliação de conformidade dos produtos, no que diz respeito aos requisitos mínimos de segurança cibernética, devem ser feitos por intermédio de Certificação, motivo pelo qual incluímos no item “2. REFERÊNCIAS”, o Ato nº 2200/2020, normativo da ANATEL que disciplina o referido procedimento.

Contribuição N°: 27
ID da Contribuição: 92589
Autor da Contribuição: Wilson Cardoso
Data da Contribuição: 14/05/2020 18:15:20
Contribuição:

Pedimos a gentileza de incluir as normas:

NESAS do GSMA- FS.16 Network Equipment Security Assurance Scheme - Development and Lifecycle Security Requirements
ETSI GS NFV-SEC 001 V1.1.1 (2014-10): Network Functions Virtualisation (NFV); NFV Security; problem Statement

E excluir todas as normas relacionadas a IoT.

Justificativa:

A inclusão das normas do GSAM e ESTI para cibersegurança garante um framework para os fornecedores de tecnologia de acordo com as normas internacionais e suporta a Anatel em uma abordagem ampla do tema.

Contribuição N°: 28
ID da Contribuição: 92596
Autor da Contribuição: Mateus de Faria Pereira
Data da Contribuição: 15/05/2020 14:59:59
Contribuição:

3GPP TS 33.117 V16.4.1 - Catalogue of General Security Assurance Requirements

Justificativa:

É um padrão de uma organização mundialmente conhecida e que no nosso entendimento deve ser considerado.

Contribuição N°: 29
ID da Contribuição: 92655
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:06:37
Contribuição:

2.8. Instrução Normativa número 4 de 26/03/2020 - Gabinete de Segurança Institucional  

Justificativa:

 

Justificativa – Incluir a referencia publicada após a consulta e utilizada na contribuição

  

Contribuição N°: 30
ID da Contribuição: 92669
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:15:24
Contribuição:

 

2.8. Instrução Normativa número 4 de 26/03/2020 - Gabinete de Segurança Institucional

  

Justificativa:

 

Justificativa – Incluir a referencia publicada após a consulta e utilizada na contribuição

  

Contribuição N°: 31
ID da Contribuição: 92677
Autor da Contribuição: EMILIO CARLOS REBOUCAS SANTANA LOURES
Data da Contribuição: 16/05/2020 19:30:32
Contribuição:

Fontes adicionais são relevantes para consideração neste contexto:

 

Justificativa:

Algumas das referências internacionais listadas estão desatualizadas e o texto da presente consulta diverge de vários esforços atualizados.

Essas indicações são relevantes para consideração, pois trazem uma abordagem para definir os requisitos mínimos de segurança, mas se concentram em um setor diferente (ecossistema de IoT) que deve ser excluído da presente consulta (ver comentários ao 1.Objetivo).

 Item:  3. DEFINIÇÕES

3.1.Backdoor: mecanismo não documentado contido no software/firmware do produto que possibilita acesso não autorizado ao equipamento. A presença de backdoors pode ser intencional ou acidental, podendo ser decorrente de erros de programação.

3.2.Customer Premise Equipment (CPE): equipamento utilizado para conectar assinantes à rede do provedor de serviços de telecomunicações.

3.3.Firmware: software ou conjunto de softwares programados em um hardware de propósito específico e que fornecem controle de baixo nível.

3.4.Hashing: algoritmo matemático que mapeia dados de comprimento variável na entrada de uma função para um conjunto de dados de comprimento fixo na saída da função. O resultado da função hash possui muito pouca correlação com os dados de entrada da função, impossibilitando a obtenção do valor inicial de entrada a partir do resultado da operação da função.

3.5.Métodos adequados de criptografia, autenticação e integridade: protocolos ou algoritmos de criptografia, autenticação e integridade, em suas versões atualizadas. A implementação deve permitir a seleção de conjuntos de criptografia e tamanhos de chave atualizados.

Contribuição N°: 32
ID da Contribuição: 92538
Autor da Contribuição: Grace Kelly de Cassia Caporalli
Data da Contribuição: 13/05/2020 11:33:29
Contribuição:

MANIFESTAÇÃO 1-  GERAL: Para fins deste ato, entendemos ser de suma importância o estabelecimento de uma definição de “usuário” e se buscar o esclarecimento das obrigações eventualmente destinadas aos usuários finais e aquelas destinadas aos detentores das redes das telecomunicações.

 

MANIFESTAÇÃO 2- ITEM 3.1 : Revisar texto item 3.1

“Backdoor: mecanismo não documentado contido no software/firmware do produto que possibilita com intenção de possibilitar acesso não autorizado ao equipamento. A presença de backdoors pode ser intencional malicioso ou acidental, podendo ser decorrente de erros de programação.”

 

MANIFESTAÇÃO 3-ITEM 3.1: Criar definição de “vulnerabilidade”, conforme abaixo:

“Vulnerabilidade: mecanismo não documentado contido no software/firmware do produto que pode permitir acesso não autorizado ao equipamento, ou mal funcionamento. A presença de vulnerabilidades pode ser intencional ou acidental, podendo ser decorrente de erro de programação”.

 

MANIFESTAÇÃO 4-ITEM 3.2: Revisar texto item 3.2.

“Customer Premise Equipment (CPE): equipamento utilizado para conectar assinantes à rede do provedor de serviços de telecomunicações. O termo não se aplica a terminais de acesso, nem a componentes, sensores e dispositivos de propósito único e/ou recursos limitados, normalmente referidos como dispositivos para Internet das Coisas ou IoT.

 

MANIFESTAÇÃO 5-ITEM 3.2: Substituir ao longo do texto todas as referências ao termo “terminal”, por “CPE”

 

MANIFESTAÇÃO 6-ITEM 3.5: Revisar o item 3.5, a fim de criar definições específicas a cada um dos conceitos, conforme abaixo:

3.5. Métodos adequados de criptografia: protocolos ou algoritmos de criptografia documentadas pela IETF (Internet Engineering Task Force) e em suas versões atualizadas. A implementação deve permitir a seleção de conjuntos de criptografia e tamanhos de chave atualizados.

3.6. Métodos adequados de autenticação: protocolos ou algoritmos de autenticação e integridade, em suas versões atualizadas. 

3.7. Métodos adequados de integridade: protocolos ou algoritmos de integridade dos dados, software, sistema operacional e firmware, em suas versões atualizadas.

Justificativa:

JUSTIFICATIVA 1- GERAL: O ato sob consulta faz menção diversas vezes ao termo “usuário”. Portanto, entendemos ser apropriado que se crie uma definição específica para delimitar aqueles que nela se enquadram, em consonância com os outros regulamentos emitidos pela ANATEL e evitar a confusão de figuras ao longo da arquitetura das redes de telecomunicações.

JUSTIFICATIVA 2- ITEM 3.1: Por definição, um backdoor é sempre intencional, já que é criado com a intenção de permitir o acesso direto ao equipamento. Conforme o item 1.3 do LAC-BCOP-1, documento citado nas referências do ato sob consulta, o backdoor não necessariamente é concebido para causar danos, na medida em que pode ter sido incluído durante o desenvolvimento do software/firmware e esquecido pelo programador.

JUSTIFICATIVA 3-ITEM 3.1: Tendo em vista a questão que o texto parece pretender atacar com a definição de backdoor, sugerimos que seja acrescida a resolução uma definição de vulnerabilidade, pois esse conceito parece melhor aproximar da preocupação da Agência com o conjunto de requisitos identificados. Na medida em que o termo “vulnerabilidade” é mencionado diversas vezes ao longo do texto sob consulta, nós entendemos ser importante definir separadamente os conceitos de backdoor e vulnerabilidade, pois enquanto o primeiro é intencional, decorrentes das mais diversas motivações, inclusive criminosas ou de espionagem, o segundo pode ser apenas por erro de programação, sem más intenções.

JUSTIFICATIVA 4-ITEM 3.2: Reforçamos aqui a necessidade de se excluir expressamente os dispositivos de IoT e terminais de acesso do escopo de aplicação do ato em discussão, conforme exposto na justificativa do Item 1. O conceito de Customer Premises Equipment refere-se a equipamentos de acesso como gateways domésticos, modems e roteadores. Smartphones e tablets são produtos que utilizam muitas outras características além e aquém daquelas tipicamente destinadas à CPEs, portanto smartwatches, smartphones e tablets devem ser excluídos também do conceito de CPE. A própria definição de CPE no documento de referência 2.5 (LAC-BCOP-1) na sessão “Executive Summary” e em “Terminology” deixa isso claro.

JUSTIFICATIVA 5-ITEM 3.2: A fim de manter coerência ao longo do texto normativo, bem como evitar interpretações dúbias sobre, entendemos ser importante a adequação e unificação de todos os termos utilizados para refletir precisamente os conceitos abarcados.

JUSTIFICATIVA 6-ITEM 3.5 : É importante uma definição em separado para criptografia, e a especificação que o método esteja padronizado e previsto por documento da IETF, conforme item 1.4 do LAC-BOP-1, documento que consta nas referências do texto sob consulta. Ademais, entendemos que, apesar de serem métodos complementares, é de suma importância que suas respectivas definições sejam concebidas separadamente, para permitir conceituação mais clara.

Contribuição N°: 33
ID da Contribuição: 92580
Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
Data da Contribuição: 14/05/2020 16:59:16
Contribuição:

A BSA recomenda que as definições técnicas da consulta sejam alinhadas ao máximo possível com as definições estabelecidas em padrões internacionalmente reconhecidos; por exemplo, a ISO / IEEE 24765 que cataloga definições técnicas de vários padrões relevantes. Especificamente, a BSA recomenda o seguinte:

  • Backdoors. A definição atual sugere que as backdoors podem ser criadas intencionalmente ou não. Como tal, estamos preocupados que a definição não caracterize com precisão a diferença entre um backdoor e uma vulnerabilidade. Conforme usado nas normas, o termo “backdoor” seria mais adequadamente definido estritamente como um mecanismo intencional que permite o acesso ao equipamento. Essa definição a distinguiria das vulnerabilidades, abordadas em outras partes dos padrões. Além disso, pode ser útil esclarecer que as backdoors permitem o acesso ao equipamento não autorizado pelo usuário final.
  • Firmware. Recomendamos que a definição de firmware tenha sido substituída pela definição incluída na ISO / IEEE 24765: “firmware. 1. Combinação de um dispositivo de hardware e instruções do computador ou dados do computador que residem como software somente leitura no dispositivo de hardware; 2. Conjunto ordenado de instruções e dados associados armazenados de uma forma funcionalmente independente do armazenamento principal, geralmente em uma ROM. ”
  • De maneira geral, recomendamos que a consulta se refira a padrões reconhecidos internacionalmente sempre que possível. Os padrões e as melhores práticas internacionais amplamente adotados, orientados por consenso, refletem a contribuição da indústria e de especialistas e são rotineiramente atualizados, tornando-os um ponto de referência muito mais eficaz do que os requisitos prescritivos que podem se tornar rapidamente desatualizados e divergir de tais padrões[1]. Esta recomendação é aplicável à seção de definição e aos requisitos de segurança (fornecedor/mínimo) (Seções 5, 6).

 


[1] Esses mecanismos de incentivo podem incluir proteção de responsabilidade ou processos de compras que priorizam recursos de segurança interoperáveis & 8203;& 8203;e escaláveis, de forma voluntária, que adotam padrões internacionais liderados pelo setor e orientados por consenso.

Justificativa:

A BSA recomenda que as definições técnicas da consulta sejam alinhadas ao máximo possível com as definições estabelecidas em padrões internacionalmente reconhecidos; por exemplo, a ISO / IEEE 24765 que cataloga definições técnicas de vários padrões relevantes

Contribuição N°: 34
ID da Contribuição: 92590
Autor da Contribuição: Wilson Cardoso
Data da Contribuição: 14/05/2020 18:19:56
Contribuição:

Sugerimos alterar o texto do item 3.1 para:  “Backdoor: mecanismo não documentado contido no software/firmware do produto que possibilita com intenção de possibilitar acesso não autorizado ao equipamento. A presença de backdoors pode ser intencional malicioso ou acidental, podendo ser decorrente de erros de programação"

Justificativa:

Com a proposta de caso o backdoor existir no equipamento e que o mesmo esteja documentado garantimos a integridade do produto e caso necessário seja criado os mecanismos de acesso corretos.

Contribuição N°: 35
ID da Contribuição: 92633
Autor da Contribuição: Mariana Giostri M. Oliveira
Data da Contribuição: 15/05/2020 19:03:38
Contribuição:

Backdoor: mecanismo não documentado contido no software/firmware do produto que possibilita com intenção de possibilitar acesso não autorizado ao equipamento. A presença de backdoors pode ser intencional maliciosa ou acidental, podendo ser decorrente de erros de programação.

**

Vulnerabilidade: mecanismo não documentado contido no software/firmware do produto que pode permitir acesso não autorizado ao equipamento, ou mal funcionamento. A presença de vulnerabilidades pode ser acidental, podendo ser decorrente de erro de programação.

**

Customer Premise Equipment (CPE): equipamento utilizado para conectar assinantes à rede do provedor de serviços de telecomunicações. O termo não se aplica a sensores e dispositivos de propósito único e/ou recursos limitados, normalmente referidos como dispositivos para Internet das Coisas ou IoT.

**

Métodos adequados de criptografia: protocolos ou algoritmos de criptografia documentadas pela IETF (Internet Engineering Task Force) e em suas versões atualizadas. A implementação deve permitir a seleção de conjuntos de criptografia e tamanhos de chave atualizados.

Métodos adequados de autenticação: protocolos ou algoritmos de autenticação e integridade, em suas versões atualizadas. A autenticação deverá ser por senha segura, e não poderá ser definida no próprio código do hardware ou software, impedindo sua alteração.

Métodos adequados de integridade: protocolos ou algoritmos de integridade dos dados, software, sistema operacional e firmware, em suas versões atualizadas.

Justificativa:

Por definição, um backdoor é sempre intencional, já que é criado com a intenção de permitir o acesso direto ao equipamento.

Segundo o documento “Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition”, que conta como referência no texto sob consulta, um backdoor não necessariamente é concebido para causar danos, na medida em que pode ter sido incluído durante o desenvolvimento do software/firmware e esquecido pelo programador.

Dessa forma, sugerimos um pequeno ajuste na definição proposta para que fique mais aderente à definição técnica do termo.

**

O conceito de Customer Premises Equipment refere-se usualmente a equipamentos de acesso como gateways domésticos, modems e roteadores.

Os dispositivos de IoT utilizam muitas outras características aquém daquelas tipicamente destinadas à CPEs. Por tal razão, sugerimos que a definição de CPE constante do regulamento seja revista para se delimitar aos conceitos utilizados como CPE, podendo, eventualmente, incluir outros elementos do core de rede, mas não devendo abranger dispositivos terminais e dispositivos de IoT em virtude das características simplificadas desse dispositivo. A segurança cibernética, nestes casos, deverá ser garantida por outros elementos da rede, dispensando o controle granular dos dispositivos colocados na ponta.

Quanto à eventualidade de se incluir outros elementos de core de rede, sugerimos que haja a elaboração de uma definição que englobe esses equipamentos, de forma clara e que proporcione uma interpretação objetiva. Da forma como apresentada a consulta pública, o texto se refere a equipamentos terminais que se conectam à Internet e para equipamentos de infraestrutura de redes de telecomunicações, de maneira muito vaga, gerando incerteza e insegurança quanto a abrangência da obrigação estabelecida na norma.

Na medida em que o termo “vulnerabilidade” é mencionado diversas vezes ao longo do texto sob consulta, nós entendemos ser importante definir separadamente os conceitos de backdoor e vulnerabilidade, pois enquanto o primeiro é intencional, decorrentes das mais diversas motivações, inclusive criminosas ou de espionagem, o segundo pode ser apenas por erro de programação, sem más intenções. Além disso, esse conceito parece melhor aproximar da preocupação da Agência com o conjunto de requisitos identificados.

**

É importante uma definição em separado para criptografia, e a especificação que o método esteja padronizado e previsto por documento da IETF, conforme o documento “Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition” do LAC-BOP-1.

Além disso, entendemos que, apesar de serem métodos complementares, é de suma importância que suas respectivas definições sejam concebidas separadamente, para permitir conceituação mais clara.

Contribuição N°: 36
ID da Contribuição: 92642
Autor da Contribuição: LUCIMARA DESIDERA
Data da Contribuição: 15/05/2020 19:47:41
Contribuição:

No intuito de melhorar a qualidade dos métodos criptográficos, incluindo-se hashing criptográfico, disponibilizados nos equipamentos e a serem aplicados em sigilo, autenticação e integridade, gostaríamos de sugerir a inclusão de exigência do uso de especificações padronizadas, publicadas por instituições internacionais de padronização, de tal forma que sejam de conhecimento público.

Justificativa:

Ao adotar a implementação de algoritmos e protocolos padronizados, alguns diferenciais podem ser alcançados, dentre os quais destacam-se: 1. melhora da segurança, fazendo-se valer do Princípio de Kerckhoffs, o qual preconiza que um sistema criptográfico deve ser seguro mesmo que tudo sobre o sistema, exceto a chave, seja de conhecimento público; Ademais, sendo as especificações padronizadas e de conhecimento público, torna-se possível verificar, junto às instituições que a publicaram, quais são as versões atualizadas e as cifras disponíveis, e também facilita a disseminação de conhecimento a respeito de vulnerabilidades e mitigações existentes; 2. Viabiliza a interoperabilidade. Seguir especificações padrão é um fator primordial para viabilizar a interoperabilidade entre os diversos equipamentos da rede, entre distintos fornecedores, assim como entre os equipamentos e os sistemas de gerenciamento dos operadores de rede, em especial em ambientes heterogêneos. Convém ainda observar, como melhoria futura, visando dispositivos restritos em capacidade computacional, e a medida que especificações padrão aberto tornarem-se disponíveis, poderá ser desejável solicitar implementações compatíveis com algoritmos criptográficos leves (Lightweight Cryptography - LWC).

 

Contribuição N°: 37
ID da Contribuição: 92662
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:06:37
Contribuição:
Justificativa:
Contribuição N°: 38
ID da Contribuição: 92678
Autor da Contribuição: EMILIO CARLOS REBOUCAS SANTANA LOURES
Data da Contribuição: 16/05/2020 19:35:04
Contribuição:

3.2. Customer Premise Equipment (CPE): equipamento, produto final, utilizado para conectar assinantes à rede do provedor de serviços de telecomunicações.

Justificativa:

Como uma visão holística dos recursos de segurança do dispositivo é desejável e a funcionalidade e os aplicativos finais são configurados no nível do dispositivo, os padrões internacionais, estruturas e esforços de consenso propostos geralmente aplicam os recursos de segurança no nível do produto final (referências citadas).

O termo "equipamento" não se aplica a sensores ou dispositivos que são geralmente considerados dispositivos IoT (sensor ou atuador) e deve ter um escopo restrito ao CPE (Customer Premise Equipment), como definido.

Contribuição N°: 39
ID da Contribuição: 92706
Autor da Contribuição: Sergio Mauro da Silva Maia
Data da Contribuição: 17/05/2020 20:17:56
Contribuição:

Contribuição: Sugerimos que acrescentem a definição de “usuário”.

Justificativa:

Justificativa:  O termo usuário é mencionado no ato diversas vezes na proposta, porém sem definição se é aplicada apenas a pessoa natural ou jurídica.

 

 Item:  4. REQUISITOS GERAIS

4.1.O interessado na homologação deve demonstrar conformidade do produto por meio de declaração afirmando:

a) que o equipamento e seu fornecedor atendem os requisitos contidos neste documento; e

b) estar ciente que este documento está sujeito a atualizações.

4.2.O escopo da declaração de conformidade deve considerar as diferentes características técnicas dos equipamentos (quantidade de memória, capacidade de processamento de dados, interfaces do usuário, interfaces de comunicação, etc.) e os fins a que se destinam, apontando quais requisitos são atendidos.

4.2.1.Para produtos enquadrados na definição de CPE, a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência 2.5.

4.3.Nas atividades de supervisão de mercado, a Agência poderá avaliar os requisitos contidos neste documento por meio de procedimentos de ensaios orientados pelas melhores práticas, padronizadas internacionalmente, para avaliação de vulnerabilidades.

4.4.Identificada, no produto homologado, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência notificará o responsável pela homologação a sana-la, indicando prazo adequado para esse fim, considerando-se o grau de risco da vulnerabilidade.

4.4.1.Decorrido o prazo sem que se verifique as adaptações necessárias ou a justificativa aceita pela Anatel para sua não implementação, a Agência suspenderá a homologação do produto, podendo indicar o recolhimento ou substituição do mesmo no mercado, garantidas as demais previsões regulamentares referentes ao direito do consumidor.

4.4.2.A suspensão da homologação do equipamento será mantida até que as vulnerabilidades apontadas sejam sanadas ou até que o potencial risco à segurança dos serviços para telecomunicações seja mitigado, considerando-se o prazo máximo estabelecido na regulamentação vigente.

4.4.3.Após o prazo máximo determinado para sua suspensão, a homologação será cancelada, caso a vulnerabilidade não seja solucionada.

Contribuição N°: 40
ID da Contribuição: 92541
Autor da Contribuição: GILBERTO VILAS BOAS MAGALHAES
Data da Contribuição: 12/05/2020 15:50:14
Contribuição:

4.1.A demonstração de conformidade do produto deve ser através de  análise de software realizada por laboratórios acreditados pela Coordenação geral de acreditação do Inmetro (CGCRE) de forma a demonstrar o atendimento aos seguintes requisitos:

a) Análise de vulnerabilidades, coerência da implementação dos programas embarcados em relação à documentação técnica depositada.

4.2.O escopo da análise de software deve considerar as diferentes características técnicas dos equipamentos (quantidade de memória, capacidade de processamento de dados, interfaces do usuário, interfaces de comunicação, etc.) e os fins a que se destinam, apontando quais requisitos são atendidos.

Justificativa:

No Brasil há vários laboratórios acreditados para homologação de software com escopo para homologação de Registrador eletrônico de ponto, Medidor de energia,.... Neste segmento, para homologação inicial deve haver constatação com relação aos requisitos de segurança e não ser aceito somente a declaração do fabricante.Devemos ter maior cuidado com segurança da informação e não ficar na mão de fornecedores e fabricantes (chineses em geral) onde não se sabe se há "codigo malicioso" ou mesmo falta de segurança involuntária. Da forma como colocado nesta consulta pública, ao meu ver não muda basicamente nada do que se tem hoje, somente será adicionado um documento à certificação do produto onde não haverá forma de evidenciar a veracidade uma vez que não haverá constatação. 

Contribuição N°: 41
ID da Contribuição: 92542
Autor da Contribuição: Grace Kelly de Cassia Caporalli
Data da Contribuição: 13/05/2020 11:51:58
Contribuição:

MANIFESTAÇÃO 1 - ITEM 4.1 =  Revisar item 4.1. subitem a) e b). Inclusão de item 4.1.1.

a) que o equipamento e seu fornecedor atendem – no momento de homologação - os requisitos contidos neste documento; e

b)  estar ciente que este documento essa conformidade estará sujeita a atualizações, decorrente da evolução tecnológica e eventual atualização dos requisitos mínimos definidos pela Agência em regulamentação. O fabricante ou requerente do certificado de homologação da Anatel terá o prazo de 180 dias para se adequar, contados a partir da publicação do ato ou notificação da Agência.

ITEM 4.1.1.- Na definição dos requisitos mínimos, a Anatel deverá, necessariamente, seguir as referências estabelecidas no LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

 

MANIFESTAÇÃO 2 - ITEM 4.3 = Alterar o item 4.3.  Nas atividades de supervisão de mercado, a Agência poderá avaliar os requisitos contidos neste documento por meio de procedimentos de solicitar a documentação dos ensaios e testes realizados para fornecimento da declaração de conformidade. Tais ensaios deverão ser orientados pelas melhores práticas, padronizadas internacionalmente, para avaliação de vulnerabilidades.

MANIFESTAÇÃO 3 - ITEM 4.4 = Revisar item 4.4. e criar subitem 4.4.1.

Item 4.4  “Identificada,  durante o processo de homologação de um produto, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência  e o responsável pela homologação notificarão o fabricante do equipamento, o qual será responsável por sana-la, considerando-se o grau de risco da vulnerabilidade”.  

Inserir 4.4.1 –  O fabricante deverá prover atenuação da vulnerabilidade, se tecnicamente viável, de maneira consistente com os padrões internacionais e com as melhores práticas do setor o mais rápido possível e em prazos razoáveis, levando em consideração a integridade e eficácia da atenuação proposta, bem como como a gravidade da vulnerabilidade. Esse prazo não deverá ser inferior a 180 dias.

MANIFESTAÇÃO 4 - ITENS 4.4.1/4.4.2/4.4.3 = Alterar texto dos itens 4.4.1., 4.4.2. e 4.4.3.

& 8203;& 8203;& 8203;& 8203;& 8203;& 8203;& 8203;4.4.1  Decorrido o prazo sem que se verifique as adaptações necessárias ou a justificativa aceita pela Anatel para sua não implementação, a Agência suspenderá o processo de homologação do produto, podendo indicar o recolhimento ou substituição do mesmo no mercado, garantidas as demais previsões regulamentares referentes ao direito do consumidor.

4.4.2.A suspensão do processo de homologação do equipamento será mantida até que as vulnerabilidades apontadas sejam sanadas ou até que o potencial risco à segurança dos serviços para telecomunicações seja mitigado, considerando-se o prazo máximo estabelecido na regulamentação vigente.

4.4.3. Após o prazo máximo determinado para sua suspensão, o processo de homologação será cancelado, caso a vulnerabilidade não seja solucionada.

Justificativa:

JUSTIFICATIVA 1 - ITEM 4.1 : A fim de evitar indesejáveis custos regulatórios onerosos, bem como possíveis conjuntos de requisitos obsoletos e em desarmonia com as práticas internacionais, sugerimos que a ANATEL sempre tenha como base as referências apresentadas pelo LAC-BCOP-1.

JUSTIFICATIVA 2 - ITEM 4.3:  De modo a preservar a integridade dos produtos e garantir a propriedade intelectual dos fabricantes no desenvolvimento de produtos com o estado da arte da tecnologia, sugerimos que sejam feitas as alterações acima dispostas.

JUSTIFICATIVA 3 - ITEM 4.4: A ABINEE entende que os processos de avaliação e identificação de vulnerabilidades devem ser restritos no âmbito do processo de homologação do produto e não após a sua finalização, o que poderá levar a uma situação de constante insegurança jurídica para os fabricantes de equpamentos. Outro ponto importante é deixar claro que o fabricante do equipamento deve ser o responsável por sanar as eventuais vulnerabilidades identificadas, e não o órgão responsável pela homologação.          A viabilidade e prazos envolvidos devem ser analisados pelo responsável ou fabricante do produto. Muitas vezes as soluções de vulnerabilidades dependem da atuação conjunta de várias entidades (fornecedor do Sistema Operacional/plataforma, fornecedor do chipset, integrador OEM). As atividades não se resumem a simples modificação do código, mas também aprovação em testes laboratoriais ou testes de campo, aprovação e integração da correção na plataforma, aprovação pelas operadoras que fazem uso de suas redes e outras atividades antes do envio ao usuário final. Uma correção apressada pode gerar problemas colaterais não previstos, as vezes maiores que o problema original, por isso todo o ciclo de testes e aprovação se faz necessário, bem como a expertise para determinar os prazos e viabilidade técnica.    A sugestão de prazo acima referida é compatível com os prazos de certificação de equipamentos usualmente utilizados pela Agência.

JUSTIFICATIVA 4 - ITENS 4.4.1/4.4.2/4.4.3 : Os ajustes propostos nos subitens acima foram sugeridos para que haja uma harmonização com a nossa manifestação apresentada ao item 4.4., de que tais medidas devem restringir-se a produtos que estão em processo de homologação.

Contribuição N°: 42
ID da Contribuição: 92566
Autor da Contribuição: Fernando Capez
Data da Contribuição: 14/05/2020 12:09:30
Contribuição:

4.1.O interessado na homologação deve demonstrar conformidade do produto por meio de certificação baseada em ensaio de tipo, em avaliações periódicas do produto.

 

Sugestão de exclusão dos demias item desse tema, pois opinamos que à avaliação de conformidade dos produtos devem ser feitos por intermédio de Certificação. Consequentemente, o presente dispositivo deve ser revogado, pois o mesmo versa sobre o procedimento de avaliação por Declaração de Conformidade

Justificativa:

Item 4.1 Em que pese todos os esforços para desburocratizar o processo de avaliação de conformidade, entendemos que a atuação da ANATEL deve ser no sentido de reprimir a entrada de equipamentos no mercado de consumo, que não sejam devidamente certificados, preservando a conformidade regulatória. Ademais, a solicitação da homologação por parte do fabricante/fornecedor através de mera declaração de conformidade aos requisitos mínimos de segurança cibernética, é um ato no mínimo temerário, uma vez que pode acarretar em introdução de produtos que, apesar dos informes de conformidade trazidos na respectiva Declaração, podem não ser adequados com a versão do equipamento comercializado no Brasil, seja por algum cuidado não observado na montagem ou por falta de componente bastante relevante para seu funcionamento local, ou mesmo resultado do projeto de climatização do produto para o nosso país. Portanto, a demonstração de conformidade

do produto deve ser feita por meio de certificação baseada em ensaio de tipo, com avaliações periódicas do produto, na qual os laboratórios de ensaio avaliam os produtos, rotineiramente, para que os equipamentos reprovados nos ensaios não sejam inseridos no mercado. Frisa-se a recente aprovação do procedimento operacional que estabelece as regras e documentos para a avaliação da conformidade de produto para telecomunicações na modalidade de Certificação (Ato nº 2220, de 20 de abril de 2020). Nesse aspecto, é necessário considerar sempre que o objetivo da regulamentação é uma ação preventiva em relação ao fato ou vício do produto, já que o custo envolvido no ressarcimento dos prejuízos causados aos consumidores, são bem mais elevados em termos de recursos humanos e financeiros. Quanto ao item “4. REQUISITOS GERAIS” contido na Minuto de Ato, somos contrários a avaliação da conformidade por Declaração, tendo em vista os riscos à saúde e à segurança dos consumidores que tal procedimento pode perpetrar, como já explicitada acima.

 

Sugestão de exclusão dos demias item desse tema, pois opinamos que à avaliação de conformidade dos produtos devem ser feitos por intermédio de Certificação. Consequentemente, o presente dispositivo deve ser revogado, pois o mesmo versa sobre o procedimento de avaliação por Declaração de Conformidade

Contribuição N°: 43
ID da Contribuição: 92570
Autor da Contribuição: LUIZ GUSTAVO DE MORAIS
Data da Contribuição: 14/05/2020 13:32:53
Contribuição:

Os Comentários a seguir dizem respeito à referência descrita abaixo:

2.5.LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

Subitem 4.2.1. Para produtos enquadrados na definição de CPE, a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência 2.5.

Questionamento: Favor esclarecer se a intenção da referencia 2.5 neste caso deve ser entendida como requisitos adicionais mandatórios ou como sugestões de praticas a serem adotadas nos produtos. Adicionalmente, favor esclarecer como devem ser tratados os conflitos entre os itens da referencia 2.5 e o texto da Consulta Publica 13. Usualmente, entende-se que o Ato Anatel deve ser mais prioritário, mas isso não esta definido explicitamente.

Subitem MR-03: The remote management and administration, and remote updating mechanisms MUST support:

d. When applicable, The ability to choose the connection port (i.e. support changing the port number from the DEFAULT/assigned port for the service [17]).

Subitem MR-07: Regarding checking for updates, CPE:

a. MUST SHOULD have the ability to run periodic checks to pull updates on an automated, scheduled basis;

c. SHOULD MUST support ISP-prompted or service/equipment provider push updates on an on-demand basis

Subitem: FR-19: Passwords MUST NOT be visible in clear text BY DEFAULT in any management interface, unless the password management interface is not available at the home screen. Passwords MAY be made visible when requested

Subitem IR-05: When WiFi is provided, the WiFi network(s) MUST have a unique initial password, NOT equal to the WiFi SSID, and it MUST be possible to identify the initial password(s) visually on the device label or on the device display, if equipped. The password(s) SHOULD be different from the DEFAULT admin password

Subitem IR-06: When WiFi is provided, the WiFi Service Set Identifier(s)(SSIDs) DEFAULT value(s) MUST NOT be related to the vendor name nor the product model, except when provided with random numeric characters, and it MUST be customizable. Check the table in Annex I for ISP customized DEFAULT values

Subitem VR-04: MUST have a publicly available support channel that does not require pre-registration or an account, at minimum, through a website in English to:

a. Inform about existing vulnerabilities, mitigation measures and security fixes associated with its product(s);

b. Provide security fixes and/or new versions of firmware or software for its product(s);

c. Provide manuals and other materials regarding device configuration, updating and security.

Subitem 4.4: Identificada, no produto homologado, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência notificará o responsável pela homologação a sana-la, indicando prazo adequado para esse fim, considerando-se o grau de risco da vulnerabilidade. A Agência pode aceitar sugestões do responsável pela homologação para avaliar o prazo de mitigação da vulnerabilidade, quando razoável.

Justificativa:

Justificativa Subitem 4.2.1: Já está contida na Contribuição acima

Justificativa Subitem MR-03: Todas as atualizações de software/firmware de segurança para equipamentos de telecomunicações em veículos são automaticamente instalados via ar, através da conexão 4G ou WiFi hotspot. O cliente final não precisa configurar o equipamento para receber atualizações, isso é feito de forma segura e protegida pela montadora. Portanto, a seleção de uma porta de conexão pelo cliente final não é requerida, uma vez executado antecipadamente pela montadora e tendo o ecossistema capacidade de suportar atualizações remotas de nossos veículos.

Justificativa Subitem MR-07:

Recomenda-se considerar uma abordagem de PODE ao invés de DEVE para a capacidade de rodar verificações e instalação de atualizações de software/firmware periódicas automáticas, uma vez que isso implica em consumo de dados e aplicações de taxas mediante seu uso, o que depende do plano de acesso de internet do cliente.

Por outro lado, quando o fornecedor do equipamento libera uma atualização de software/firmware de segurança, recomenda-se considerar uma abordagem de DEVE ao invés de PODE pois é altamente recomendável que o equipamento receba e passe a operar usando novo software/firmware o quanto antes.

O provedor de serviço ou equipamento também deve ser autorizado, em adição ao Internet Service Provider, a enviar atualizações sob demanda, pois as atualizações de software/firmware são disponibilizadas pelo provedor de serviço ou equipamento ao invés do Internet Service Provider.

Justificativa Subitem FR-19:

Esta contribuição visa adequar algumas condições nas quais as Senhas de acesso não são visíveis na pagina de configuração principal do equipamento e sim disponibilizadas em um ou mais cliques a partir da pagina principal.

Alem disso, a funcionalidade de ponto de acesso WiFi é um novo recurso comumente fornecido em veículos mais novos e, considerando que os veículos são uma rede distribuída descentralizada complexa, existem muitas camadas de defesa para proteger seus sistemas, módulos eletrônicos e ocupantes contra ataques cibernéticos, inclusive através da rede WiFi do veículo.

Entende-se que a senha para a rede WiFi embarcada pode estar sempre visível, quando em ambiente automotivo, uma vez que opera sob condições restritas, como o proprietário do veículo acessando o veículo com chave válida, verificação durante inicialização dos módulos de rádio e telemática para confirmar que eles pertencem ao veículo específico , supervisão do proprietário do veículo, veículos não serem pontos de acesso WiFi estacionários, entre outros.

Justificativa IR-05: Permitir que a informação da senha inicial de redes WiFi seja acessada diretamente a partir da tela do dispositivo ao invés de ser disponibilizada na etiqueta do mesmo, desde que o dispositivo possua um display.

Adicionalmente, esta contribuição possibilita adequar situações nas quais alguns dispositivos definem novas senhas randômicas, diferentes das definidas no momento da produção do dispositivo, quando os mesmos passam por procedimento de reset.

Justificativa IR-06: Seria aceitável que o SSID inicial padrão contivesse o nome do fabricante com a adição de caracteres numéricos randômicos? Caso negativo, seria aceitável que o SSID inicial padrão seja o mesmo para determinado modelo de produto, desde que não contenha o nome do fabricante e produto? Entende-se que a intenção deste requisito seja tornar o SSID não obvio e prover diferenciação entre os produtos do mesmo modelo, o que a primeira pergunta atenderia.

Justificativa VR-04: Este requisito conflita com o requisito da sessão 6.1.6 em relação ao pré-requisito de registro prévio ou possuir uma conta. Entende-se que a sessão 6.1.6 é mais prioritária do que a referencia VR-04 do item 2.5.

Requer esclarecimento e confirmação da Anatel.

Justificativa Subitem 4.4: A definição de prazos de implementação de mudanças em componentes automotivos está sujeito a diversos fatores que são incontroláveis, tais como prazos logísticos, liberação alfandegaria, flutuações de demanda, fila de implementação de modificações de produto em linhas de produção, datas padronizadas de implementação de modificações em linha de produção, entre outros.

As montadoras analisam vulnerabilidades de Segurança Cibernética considerando a segurança dos ocupantes. Os veículos atualmente são redes complexas distribuídas decentralizadas, existem muitas camadas de defesa Cibernética que protegem os ocupantes dos veículos.  Avaliando um passo pra trás, as montadoras definem como requisito as operadoras de telecomunicações a capacidade de cortar conexões com servidores se um incidente é detectado quando uma solução de software/firmware não pode ser desenvolvidas em um período curto o bastante para manter a conectividade e segurança. Esta estratégia pode ser executada quando as alterações de produto levam mais tempo.

Contribuição N°: 44
ID da Contribuição: 92581
Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
Data da Contribuição: 14/05/2020 17:06:55
Contribuição:

A BSA elogia a Anatel por propor uma estrutura que se baseia no auto-atestado como o principal meio para que as empresas demonstrem que tomaram medidas de segurança adequadas. O auto-atestado permite que as empresas forneçam garantias de segurança significativas sem criar requisitos burocráticos que podem causar atrasos na introdução de produtos no mercado.

Conforme discutido abaixo, diferentes tipos de dispositivos terão perfis de risco diferentes, com riscos variando com base no tamanho da superfície de ataque do dispositivo, na complexidade de seus componentes, nos tipos de informações armazenadas e nos processos, nos tipos de funções físicas que ele pode controlar e outras variáveis. A seguir, propomos que os dispositivos sejam classificados em diferentes categorias, a fim de permitir que a personalização dos requisitos de segurança seja arriscada; no entanto, nenhuma quantidade de categorização pode explicar a diversidade de dispositivos de TI e seus modelos de ameaças. Portanto, os padrões de cibersegurança devem permitir diferentes perfis de risco, permitindo que as partes responsáveis & 8203;& 8203;especifiquem, em suas declarações que acompanham os produtos que buscam homologação, os padrões de cibersegurança que eles determinam inaplicáveis & 8203;& 8203;aos seus produtos com base em sua avaliação de risco e expliquem a base de cada determinação . Em suma, deve haver uma opção para os fabricantes de dispositivos identificarem um padrão de segurança cibernética inaplicável aos seus produtos com base em uma avaliação de risco. Na ausência dessa opção, muitos dispositivos estarão sujeitos a requisitos desnecessários e onerosos que podem impedir a inovação.

 

A BSA também aprecia a ênfase da consulta na mitigação de vulnerabilidades. Os membros da BSA acreditam firmemente na responsabilidade dos desenvolvedores de software de trabalhar com seus clientes para identificar, priorizar e mitigar vulnerabilidades para minimizar as interrupções nos riscos de serviço e segurança. No entanto, o gerenciamento de vulnerabilidades é uma disciplina complexa: as vulnerabilidades diferem de acordo com o risco que apresentam, a complexidade do desenvolvimento de soluções e a necessidade de coordenação com outros vendedores. Para alcançar de maneira mais eficaz as metas de mitigação de vulnerabilidades representadas na consulta, a BSA recomenda que a Seção 4.4 (4.4-4.4.3) seja modificada para incorporar um processo para que a Anatel evite delinear um cronograma específico para o desenvolvimento da mitigação e alinhe mais amplamente os requisitos das seções 4, 6 com os padrões internacionais (ISO/IEC 29147,30111) sobre coordenação e tratamento de vulnerabilidades.

A Seção 4.4 supõe que a agência possa prever, antes do processo de desenvolvimento de mitigação (CVD), o cronograma necessário para o desenvolvimento da remediação e, portanto, diverge dos padrões internacionais (ISO / IEC 29147, 30111). Os padrões internacionais e as melhores práticas de CVD adotadas pelo setor reconhecem a complexidade dos processos de CVD e não recomendam cronogramas. Além disso, eles observam que o fabricante deve equilibrar a necessidade de desenvolver a correção o mais rápido possível com a necessidade de garantir a integridade e a eficácia da mitigação proposta. Nós fornecemos comentários detalhados adicionais abaixo.

Propomos que o fabricante desenvolva e emita uma atenuação da vulnerabilidade, se tecnicamente viável, de maneira consistente com os padrões internacionais e as melhores práticas do setor o mais rápido possível e em prazos razoáveis, levando em consideração a integridade e eficácia da atenuação proposta, bem como a gravidade da vulnerabilidade.

Justificativa:

Diferentes tipos de dispositivos terão perfis de risco diferentes, com riscos variando com base no tamanho da superfície de ataque do dispositivo, na complexidade de seus componentes, nos tipos de informações armazenadas e nos processos, nos tipos de funções físicas que ele pode controlar e outras variáveis. Portanto, os padrões de cibersegurança devem permitir diferentes perfis de risco, permitindo que as partes responsáveis & 8203;& 8203;especifiquem, em suas declarações que acompanham os produtos que buscam homologação, os padrões de cibersegurança que eles determinam inaplicáveis & 8203;& 8203;aos seus produtos com base em sua avaliação de risco e expliquem a base de cada determinação.

4.4.1 - 

Este dispositivo pressupõe que a agência possa prever, antes do processo de desenvolvimento de mitigação (CVD), o cronograma necessário para o desenvolvimento da remediação e, portanto, diverge dos padrões internacionais (ISO / IEC 29147, 30111). Os padrões internacionais e as melhores práticas de CVD adotadas pelo setor reconhecem a complexidade dos processos de CVD, inclusive em "ambientes com vários atores", onde é necessária uma colaboração adicional do setor e que as abordagens podem mudar dependendo da tecnologia. Os padrões internacionais não recomendam cronogramas específicos e observam que o fabricante deve equilibrar a necessidade de desenvolver a correção o mais rápido possível com a necessidade de garantir a integridade (teste) e a eficácia da mitigação proposta.

Como pode haver limitações técnicas na mitigação de vulnerabilidades, a consulta deve criar incentivos para a adoção de processos compatíveis com os padrões internacionais. Além disso, se uma “vulnerabilidade relacionada a um ou mais requisitos de cibersegurança” for identificada, a agência deve notificar a parte responsável (proprietário da tecnologia que lidera o desenvolvimento e a coordenação da mitigação) imediatamente, de maneira que seja compatível com os padrões internacionais e com as melhores práticas do setor. 
 

Contribuição N°: 45
ID da Contribuição: 92591
Autor da Contribuição: Wilson Cardoso
Data da Contribuição: 14/05/2020 18:23:07
Contribuição:

Pedimos excluir o item 4.2.1. 

Justificativa:

Conforme manifestação anterior.

Contribuição N°: 46
ID da Contribuição: 92602
Autor da Contribuição: Darles Leandro C. Gomes
Data da Contribuição: 15/05/2020 16:35:30
Contribuição:

O interessado na homologação deve demonstrar conformidade do produto por meio de ensaios mínimos e declaração. 
 

Justificativa:

É mais importante a realização de alguns ensaios  (mínimos) para constatar conformidade do que uma simples declaração.   

Contribuição N°: 47
ID da Contribuição: 92612
Autor da Contribuição: Gilberto Martins de Almeida Filho
Data da Contribuição: 15/05/2020 17:14:53
Contribuição:

Incluir item 4.2.1.1 e seus incisos I, II, III, IV e V.

"4.2.1. Para produtos enquadrados na definição de CPE, a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência 2.5.

4.2.1.1 As definições contidas nos itens MR-03, MR-07, FR-19, IR-05 e IR-06 do documento complementar do item 2.5, aplicam-se conforme descrição abaixo.

I- MR-03: Os mecanismos de gerenciamento e administração, e de atualização remotos DEVEM suportar:

[...]

d. Quando aplicável, a capacidade de escolher a porta de conexão (ou seja, suportar a alteração do número da porta PADRÃO/porta atribuída para o serviço"

II - MR-07: Em relação a verificações de atualizações, o CPE:
a. DEVERIA ter a capacidade de executar verificações periódicas para obter (pull) atualizações de forma automatizada e programada;
c. DEVE suportar as atualizações solicitadas pelo ISP sob demanda (push) [...]

III - FR-19: As senhas NÃO DEVEM ser visíveis em texto claro POR PADRÃO em nenhuma interface de gerenciamento, a menos que a interface de gerenciamento de senhas não esteja disponível na tela inicial. Senhas PODEM tornar-se visíveis quando solicitado pelo usuário. 

IV- IR-05: Quando o WiFi é provido, a(s) rede(s) WiFi DEVE(M) ter uma senha inicial única, NÃO igual ao SSID, e DEVE ser possível identificar a(s) senha(s) inicial(is) visualmente na etiqueta do dispositivo, ou no display, se equipado. A(s) senha(s) DEVERIA(M) ser diferente(s) da senha PADRÃO de administração.

V- IR-06: Quando o WiFi é provido, o(s) valor(es) PADRÃO do(s) Service Set Identifier(s)(SSIDs) NÃO DEVE(M) estar relacionado(s) ao nome do fornecedor nem ao modelo do produto, exceto quando fornecido como equipamento destinado ao uso em veículos, e DEVE(M) ser customizável(eis). Verifique a tabela no Anexo I para valores PADRÃO personalizados pelo ISP9."

Alterar o item 4.4

"4. REQUISITOS GERAIS

4.4. Identificada, no produto homologado, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência notificará o responsável pela homologação a sana-la, indicando prazo adequado para esse fim, considerando-se o grau de risco da vulnerabilidade. A Agência pode aceitar sugestões do responsável pela homologação para avaliar o prazo de mitigação da vulnerabilidade, quando razoável."

Justificativa:

MR-03: Todas as atualizações de software/firmware de segurança para equipamentos de telecomunicações em veículos são automaticamente instalados via ar, através da conexão 4G ou WiFi hotspot. O cliente final não precisa configurar o equipamento para receber atualizações, isso é feito de forma segura e protegida pela montadora. Portanto, a seleção de uma porta de conexão pelo cliente final não é requerida, uma vez executado antecipadamente pela montadora e tendo o ecossistema capacidade de suportar atualizações remotas de nossos veículos.

MR-07: Recomenda-se considerar uma abordagem de DEVERIA ao invés de DEVE para a capacidade de rodar verificações e instalação de atualizações de software/firmware periódicas automáticas, uma vez que isso implica em consumo de dados e aplicações de taxas mediante seu uso, o que depende do plano de acesso de internet do cliente. Por outro lado, quando o fornecedor do equipamento libera uma atualização de software/firmware de segurança, recomenda-se considerar uma abordagem de DEVE ao invés de DEVERIA pois é altamente recomendável que o equipamento receba e passe a operar usando novo software/firmware o quanto antes.

FR-19: Esta contribuição visa adequar algumas condições nas quais as Senhas de acesso não são visíveis na pagina de configuração principal do equipamento e sim disponibilizadas em um ou mais cliques a partir da pagina principal. Alem disso, a funcionalidade de ponto de acesso WiFi é um novo recurso comumente fornecido em veículos mais novos e, considerando que os veículos são uma rede distribuída descentralizada complexa, existem muitas camadas de defesa para proteger seus sistemas, módulos eletrônicos e ocupantes contra ataques cibernéticos, inclusive através da rede WiFi do veículo. Entende-se que a senha para a rede WiFi embarcada pode estar sempre visível, quando em ambiente automotivo, uma vez que opera sob condições restritas, como o proprietário do veículo acessando o veículo com chave válida, verificação durante inicialização dos módulos de rádio e telemática para confirmar que eles pertencem ao veículo específico , supervisão do proprietário do veículo, entre outros. 

IR-05: Permitir que a informação da senha inicial de redes WiFi seja acessada diretamente a partir da tela do dispositivo ao invés de ser disponibilizada na etiqueta do mesmo, desde que o dispositivo possua um display. Adicionalmente, esta contribuição possibilita adequar situações nas quais alguns dispositivos definem novas senhas randômicas, diferentes das definidas no momento da produção do dispositivo, quando os mesmos passam por procedimento de reset.

IR-06: A funcionalidade de ponto de acesso WiFi é um novo recurso comumente fornecido em veículos mais novos e, considerando que os veículos são uma rede distribuída descentralizada complexa, existem muitas camadas de defesa para proteger seus sistemas, módulos eletrônicos e ocupantes contra ataques cibernéticos, inclusive através da rede WiFi do veículo. Entende-se que o WiFi SSID pode estar relacionado ao nome do fabricante ou modelo do produto, quando aplicado em veículos, uma vez que opera sob condições restritas, como o proprietário do veículo acessando o veículo com chave válida, verificação durante inicialização dos módulos de rádio e telemática para confirmar que eles pertencem ao veículo específico , supervisão do proprietário do veículo, entre outros.

Item 4.4: A definição de prazos de implementação de mudanças em componentes automotivos está sujeito a diversos fatores que são incontroláveis, tais como prazos logísticos, liberação alfandegaria, flutuações de demanda, fila de implementação de modificações de produto em linhas de produção, datas padronizadas de implementação de modificações em linha de produção, entre outros.

As montadoras analisam vulnerabilidades de Segurança Cibernética considerando a segurança dos ocupantes. Os veículos atualmente são redes complexas distribuídas decentralizadas, existem muitas camadas de defesa Cibernética que protegem os ocupantes dos veículos.  Avaliando um passo pra trás, as montadoras definem como requisito as operadoras de telecomunicações a capacidade de cortar conexões com servidores se um incidente é detectado quando uma solução de software/firmware não pode ser desenvolvidas em um período curto o bastante para manter a conectividade e segurança. Esta estratégia pode ser executada quando uma falha grave demandar uma alteração de produto que leva mais tempo.

Contribuição N°: 48
ID da Contribuição: 92634
Autor da Contribuição: Mariana Giostri M. Oliveira
Data da Contribuição: 15/05/2020 19:06:36
Contribuição:

a) que o equipamento e seu fornecedor atendem – no momento de homologação - os requisitos contidos neste documento; e

b) estar ciente que este documento essa conformidade estará sujeita a atualizações, decorrente da evolução tecnológica e eventual atualização dos requisitos mínimos definidos pela Agência em regulamentação. O fabricante ou requerente do certificado de homologação da Anatel terá o prazo de 180 dias para se adequar, contados a partir da publicação do ato ou notificação da Agência.

**

Identificada, no produto homologado durante o processo de homologação de um produto, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência notificará e o responsável pela homologação notificarão o fabricante do equipamento, o qual será responsável por sana-la, considerando-se o grau de risco da vulnerabilidade. O prazo fixado pela Anatel para saneamento da vulnerabilidade não será inferior a 180 dias.

**

4.4.1. Decorrido o prazo sem que se verifique as adaptações necessárias ou a justificativa aceita pela Anatel para sua não implementação, a Agência suspenderá o processo de homologação do produto, podendo indicar o recolhimento ou substituição do mesmo no mercado, garantidas as demais previsões regulamentares referentes ao direito do consumidor.

4.4.2. A suspensão do processo de homologação do equipamento será mantida até que as vulnerabilidades apontadas sejam sanadas ou até que o potencial risco à segurança dos serviços para telecomunicações seja mitigado, considerando-se o prazo máximo estabelecido na regulamentação vigente.

4.4.3. Após o prazo máximo determinado para sua suspensão, o processo de homologação será cancelado, caso a vulnerabilidade não seja solucionada.

Justificativa:

O setor das TIC é intrinsecamente disruptivo, onde novas tecnologias, dispositivos e soluções inovadoras são constantemente criados e aprimorados. Portanto, é natural que novas ameaças surjam com esses avanços, e é do próprio interesse das fabricantes  tomar medidas para saná-las.

Dito isto, sugerimos que a demonstração de conformidade e sua respectiva declaração sejam restritas ao âmbito do processo de homologação. Caso contrário, entendemos que a linguagem trazida pelo texto sob consulta, além de aumentar os custos de compliance por parte das empresas, pode exigir delas esforços desproporcionais em relação a algumas vulnerabilidades que não trazem riscos para os usos que o equipamento foi originalmente concebido a realizar, ao mesmo tempo que limita, do ponto de vista técnico e orçamentário, a capacidade de se mitigar vulnerabilidades relevantes.

**

A Brasscom entende que os processos de avaliação e identificação de vulnerabilidades devem ser restritos no âmbito do processo de homologação do produto e não após a sua finalização. Isso porque a Brasscom entende que haverá uma certa dificuldade por parte das fabricantes em incluir internamente rotinas voltadas para processos de pós-venda via atualização do teste de conformidade, bem como daquelas direcionadas a providenciar respostas à Agência fora do processo de homologação.

Além disso, reforçamos aqui nossa sugestão de criação de definição de “vulnerabilidade” para fins deste ato, conforme mencionamos anteriormente, e alertamos para a abrangência de seu conceito, na medida em que se trata de um mecanismo não documentado e acidental, que podem apresentar diferentes níveis de criticidade.

Outro ponto importante é deixar claro que o fabricante do equipamento deve ser o responsável por sanar as eventuais vulnerabilidades identificadas em decorrência do ato fiscalizatório, e não o órgão responsável pela homologação.

Por fim, a sugestão de prazo acima referida é compatível com os prazos de certificação de equipamentos usualmente utilizados pela Agência.

**

Nós entendemos que os processos de avaliação e identificação de vulnerabilidades devem ser restritos ao âmbito do processo de homologação do produto e não após a sua finalização. Os ajustes propostos aqui são para refletir essa premissa que já pontuamos em relação ao item 4.4.

 

Contribuição N°: 49
ID da Contribuição: 92643
Autor da Contribuição: LUCIMARA DESIDERA
Data da Contribuição: 15/05/2020 19:49:16
Contribuição:

Itens 4.1 e 4.2: gostaríamos de sugerir a inclusão de tabelas de conformidade (checklist) como anexo ao documento, onde todo os requisitos sejam elencados e os fornecedores possam declarar o nível de conformidade (parcial, total, nenhum) e descrever como seus produtos implementam o requisito.

 

Sugerimos nova redação para os itens 4.3 e 4.4, de forma a ter somente o item 4.3 a seguir:

4.3. Nas atividades de supervisão de mercado, caso sejam identificadas no produto homologado, por qualquer ator da cadeia, vulnerabilidades relacionadas a um ou mais requisitos de segurança cibernética, a Agência notificará o responsável pela homologação a saná-la, indicando prazo adequado para esse fim, considerando-se o grau de risco da vulnerabilidade.

4.3.1. Decorrido o prazo sem que sejam disponibilizadas as correções necessárias, conforme processos descritos no item 6 deste Anexo, ou a justificativa aceita pela Anatel para a não correção da vulnerabilidade, a Agência suspenderá a homologação do produto, podendo indicar o recolhimento ou substituição do mesmo no mercado, garantidas as demais previsões regulamentares referentes ao direito do consumidor.

4.3.2. A suspensão da homologação do equipamento será mantida até que as vulnerabilidades apontadas sejam sanadas ou até que o potencial risco à segurança dos serviços para telecomunicações seja mitigado, considerando-se o prazo máximo estabelecido na regulamentação vigente.

4.3.3. Após o prazo máximo determinado para sua suspensão, a homologação será cancelada, caso a vulnerabilidade não seja solucionada.

Justificativa:

É importante a existência de uma referência única, item-a-item (checklist) que sirva de guia para os fornecedores avaliarem e descreverem se seus produtos atendem de forma total, parcial, ou não atendem, a cada um dos requisitos e que possam explicar como seus produtos suportam a especificação. Isso facilitaria a avaliação da conformidade, tanto pelos fornecedores, como pelo próprio avaliador. A referência da 2.7. GSMA tem exemplos de tabelas bastante completas, item a item, para declaração de conformidade que poderiam servir de exemplo.

 

Com relação ao item 4.3, cabe ressaltar que equipamentos de rede e dispositivos conectados embora definidos como hardware, dependem intrinsecamente de software para praticamente todas as suas funcionalidades, desde as básicas operacionais (firmware), até os aplicativos e interfaces de usuário. O desenvolvimento desses produtos envolve, em sua maioria, uma complexa cadeia de fornecedores, com a combinação de múltiplos componentes desenvolvidos por organizações distintas, sendo bastante comum que bibliotecas de software, tanto de código aberto como proprietário, sejam licenciadas para composição da solução. A descoberta e tratamento de vulnerabilidades é um processo complexo denominado na Indústria de Software como “Processo de Divulgação de Vulnerabilidades de Forma Coordenada”, conhecido pela sigla CVD (do inglês Coordinated Vulnerability Disclosure). Este processo, que não é centrado em homologação de software, envolve desde centros de pesquisa, a centros de análise de vulnerabilidades, desenvolvedores de software e indústria, desta forma, não existem padrões internacionais que definam melhores práticas para ensaios para avaliação de vulnerabilidades. De forma sucinta, não é possível elaborar um ensaio que prove a inexistência de uma vulnerabilidade em um equipamento. E, exatamente por este motivo, a indústria de software já possui um processo de coordenação no tratamento de vulnerabilidades, por este motivo a sugestão é que, ao invés de envidar esforços para definir metodologias de ensaios, que invariavelmente não conseguirão identificar todas as vulnerabilidades, esta Agência direcione esforços para engajar os fornecedores de equipamentos de telecomunicações a adotarem o padrão de mercado de software, que é o processo de CVD. Desta forma, instando que eles possuam processos bem definidos para atualização de software e atuem de forma célere para disponibilizar correções, por isto a importância do item 6 deste Anexo prever mecanismos de CVD. Adicionalmente, gostaríamos de reforçar que são muitos os desafios desse processo, que vão muito além de um ensaio em laboratório, pois demandam que todos os atores da cadeia definam critérios e políticas, passando pela estruturação de processos de gestão de vulnerabilidades, a designação dos atores responsáveis e criação de mecanismos de comunicação apropriados com as partes envolvidas (fornecedores da cadeia de suprimentos, pesquisadores, desenvolvedores, clientes, etc), a fim de se produzir correções efetivas e informação clara em tempo adequado. Vários cenários e orientações acerca de Coordinated Vulnerability Disclosure encontram-se detalhados em:

https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1

https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=503330

https://www.enisa.europa.eu/news/member-states/WEB_115207_BrochureNCSC_EN_A4.pdf

CVD é também recomendada pelas boas práticas recomendadas na referência 2.6 (itens 4.2.1 e 4.2.3).

Contribuição N°: 50
ID da Contribuição: 92656
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:06:37
Contribuição:
Justificativa:
Contribuição N°: 51
ID da Contribuição: 92670
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:16:12
Contribuição:

 

4.x. Nas atividades de avaliação da conformidade referente a declaração do solicitante  e da validação de relatórios de ensaios  de produtos para telecomunicações e segurança cibernética  devem ser usados os Organismos de Certificação  Designados – OCD e os Laboratórios de Ensaio tecnicamente capacitados e devidamente habilitados. Acrescentando qualificação para as atividades de segurança cibernética - Art. 6º Resolução 715

  

Justificativa:

 

(Acréscimo de novo item – Justificativa: Dada a complexidade da avaliação das características relativas a Ciber Security em conjunto com  a necessidade de ser uma ação preventiva anterior a homologação do produto, é primordial a OCD e laboratório como agentes para dar o devido dinamismo ao processo sem comprometimento temporal da disponibilização das soluções.)

  

Contribuição N°: 52
ID da Contribuição: 92679
Autor da Contribuição: EMILIO CARLOS REBOUCAS SANTANA LOURES
Data da Contribuição: 16/05/2020 19:47:28
Contribuição:

Ao invés de delinear requisitos de projeto específicos, que podem se tornar desatualizados, a legislação pode fornecer incentivos para que os fabricantes optem voluntariamente por um programa que exigiria uma avaliação dos riscos dos dispositivos em questão para determinar os recursos de segurança relevantes / necessários; e implementar e auto-atestar ainda mais os recursos de segurança relevantes / necessários, consistentes com aqueles estabelecidos nas normas / melhores práticas internacionais amplamente adotadas (promulgadas por organizações de desenvolvimento de padrões globais reconhecidas pelo setor), como ISO / IEC. Esta disposição pode abordar as preocupações de divulgação coordenada de vulnerabilidades e os requisitos mínimos de segurança .

De acordo com esta recomendação, seria suficiente (sob a seção 4.1.a e a declaração de conformidade, seção 4.2) propor que o fabricante do equipamento declare que o equipamento atende aos requisitos descritos em um padrão internacional amplamente adotado (com flexibilidade para escolher entre padrões estabelecidos aceitáveis), conforme aplicado de maneira apropriada à avaliação de riscos. Ver também comentários gerais sobre este tópico e as Seção 5 e 6 (Requisitos de segurança cibernética).

Também o conceito de avaliação de riscos precisa ser melhor elucidado, e esse esclarecimento pode ser baseado nos processos de avaliação de riscos descritos nas práticas internacionais e nas melhores práticas do setor.

Propomos em 4.4.1. que o fabricante desenvolva e emita uma atenuação da vulnerabilidade, se tecnicamente viável, de maneira consistente com os padrões internacionais e as melhores práticas do setor o mais rápido possível e em prazos razoáveis, levando em consideração a integridade e eficácia da atenuação proposta, bem como a gravidade da vulnerabilidade.

Como geralmente pode haver limitações técnicas na redução de vulnerabilidades, os Requisitos devem criar incentivos para a adoção de processos compatíveis com os padrões internacionais.

Além disso, se for identificada a “vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética”, a agência deve notificar imediatamente a parte responsável (proprietária da tecnologia que lidera o desenvolvimento e a coordenação da mitigação), de maneira que seja compatível com os padrões internacionais e as melhores práticas do setor.

Justificativa:

Em 4.4.1. - De acordo com os requisitos propostos, se for identificada qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a agência notificará a parte responsável e indicará um termo adequado para esse fim.

Esta disposição pressupõe que a agência possa prever, antes do processo de desenvolvimento de mitigação (CVD), o cronograma necessário para o desenvolvimento da remediação e, portanto, pode divergir dos padrões internacionais (ISO / IEC 29147 (2018) , 30111 (2019) ).

Os padrões internacionais e as melhores práticas de CVD adotadas pelo setor reconhecem a complexidade dos processos de CVD, inclusive em “ambientes com várias partes” ( podem incluir sistemas e hardware incorporados) podem exigir colaboração do setor para desenvolver e testar a mitigação em diferentes ambientes , e que o tempo necessário para desenvolver a mitigação difere de acordo com a tecnologia em questão . [5] Como tal, eles não recomendam um cronograma específico, mas instruem os fornecedores a equilibrar a necessidade de desenvolver a correção o mais rápido possível & 39;com o teste geral necessário para garantir que a correção não afete negativamente os usuários afetados devido à qualidade. ", ou seja, a integridade e a eficácia da mitigação proposta. [6]

[5] O Center for Cybersecurity Policy and Law, aprimorando a divulgação de vulnerabilidades de componentes de hardware, https://static1.squarespace.com/static/5acbb666f407b432519ab15e/t/5cc86f37c830251f28d258fc/1556639544235/The+Center+for+CybersecurityLogic + Hardware + Componente + Vulnerabilidade + Divulgação_Abril + 2019.pdf .

[6] Consulte a ISO / IEC 30111 (2013), Seção 7.2.4 (Desenvolvimento de soluções): & 39;Ao determinar a melhor solução, o fornecedor deve tentar equilibrar a necessidade de criar uma solução rapidamente, com os testes gerais necessários para garantir a a correção não afeta negativamente os usuários afetados devido a problemas de qualidade. & 39; Consulte também a Seção 7.3 , monitoramento de fases de manipulação de vulnerabilidades.

Contribuição N°: 53
ID da Contribuição: 92683
Autor da Contribuição: Karla Menandro Pacheco da Silva
Data da Contribuição: 17/05/2020 10:37:41
Contribuição:

Caso não seja possível excluir os componentes veiculares do escopo da certificação, sugerimos incluir subitem 4.2.1.1

4.2.1.1 As definições contidas nos itens MR-03, MR-07, FR-19, IR-05 e IR-06 do documento complementar do item 2.5, aplicam-se conforme descrição abaixo.

I- "MR-03: Os mecanismos de gerenciamento e administração, e de atualização remotos DEVEM suportar:
d. Quando aplicável, a capacidade de escolher a porta de conexão (ou seja, suportar a alteração do número da porta PADRÃO/porta atribuída para o serviço"

II- "MR-07: Em relação a verificações de atualizações, o CPE:
a. DEVERIA ter a capacidade de executar verificações periódicas para obter (pull) atualizações de forma automatizada e programada;
c. DEVE suportar as atualizações solicitadas pelo ISP sob demanda (push).."

III- "FR-19: As senhas NÃO DEVEM ser visíveis em texto claro POR PADRÃO em nenhuma interface de gerenciamento, a menos que a interface de gerenciamento de senhas não esteja disponível na tela inicial. Senhas PODEM tornar-se visíveis quando solicitado pelo usuário. 

IV- "IR-05: Quando o WiFi é provido, a(s) rede(s) WiFi DEVE(M) ter uma senha inicial única, NÃO igual ao SSID, e DEVE ser possível identificar a(s) senha(s) inicial(is) visualmente na etiqueta do dispositivo, ou no display, se equipado. A(s) senha(s) DEVERIA(M) ser diferente(s) da senha PADRÃO de administração."

V- "IR-06: Quando o WiFi é provido, o(s) valor(es) PADRÃO do(s) Service Set Identifier(s)(SSIDs) NÃO DEVE(M) estar relacionado(s) ao nome do fornecedor nem ao modelo do produto, exceto quando fornecido como equipamento destinado ao uso em veículos, e DEVE(M) ser customizável(eis). Verifique a tabela no Anexo I para valores PADRÃO personalizados pelo ISP9."

4. REQUISITOS GERAIS

4.4. Identificada, no produto homologado, qualquer vulnerabilidade relacionada a um ou mais requisitos de segurança cibernética, a Agência notificará o responsável pela homologação a sana-la, indicando prazo adequado para esse fim, considerando-se o grau de risco da vulnerabilidade. A Agência pode aceitar sugestões do responsável pela homologação para avaliar o prazo de mitigação da vulnerabilidade, quando razoável. 

 

 

 

Justificativa:

I- Todas as atualizações de software/firmware de segurança para equipamentos de telecomunicações em veículos são automaticamente instalados via ar, através da conexão 4G ou WiFi hotspot. O cliente final não precisa configurar o equipamento para receber atualizações, isso é feito de forma segura e protegida pela montadora. Portanto, a seleção de uma porta de conexão pelo cliente final não é requerida, uma vez executado antecipadamente pela montadora e tendo o ecossistema capacidade de suportar atualizações remotas de nossos veículos.

II- Recomenda-se considerar uma abordagem de DEVERIA ao invés de DEVE para a capacidade de rodar verificações e instalação de atualizações de software/firmware periódicas automáticas, uma vez que isso implica em consumo de dados e aplicações de taxas mediante seu uso, o que depende do plano de acesso de internet do cliente.
Por outro lado, quando o fornecedor do equipamento libera uma atualização de software/firmware de segurança, recomenda-se considerar uma abordagem de DEVE ao invés de DEVERIA pois é altamente recomendável que o equipamento receba e passe a operar usando novo software/firmware o quanto antes.

III- Esta contribuição visa adequar algumas condições nas quais as Senhas de acesso não são visíveis na pagina de configuração principal do equipamento e sim disponibilizadas em um ou mais cliques a partir da pagina principal.  
Alem disso, a funcionalidade de ponto de acesso WiFi é um novo recurso comumente fornecido em veículos mais novos e, considerando que os veículos são uma rede distribuída descentralizada complexa, existem muitas camadas de defesa para proteger seus sistemas, módulos eletrônicos e ocupantes contra ataques cibernéticos, inclusive através da rede WiFi do veículo.
Entende-se que a senha para a rede WiFi embarcada pode estar sempre visível, quando em ambiente automotivo, uma vez que opera sob condições restritas, como o proprietário do veículo acessando o veículo com chave válida, verificação durante inicialização dos módulos de rádio e telemática para confirmar que eles pertencem ao veículo específico , supervisão do proprietário do veículo, entre outros.

IV - Permitir que a informação da senha inicial de redes WiFi seja acessada diretamente a partir da tela do dispositivo ao invés de ser disponibilizada na etiqueta do mesmo, desde que o dispositivo possua um display.
Adicionalmente, esta contribuição possibilita adequar situações nas quais alguns dispositivos definem novas senhas randômicas, diferentes das definidas no momento da produção do dispositivo, quando os mesmos passam por procedimento de reset.

V - A funcionalidade de ponto de acesso WiFi é um novo recurso comumente fornecido em veículos mais novos e, considerando que os veículos são uma rede distribuída descentralizada complexa, existem muitas camadas de defesa para proteger seus sistemas, módulos eletrônicos e ocupantes contra ataques cibernéticos, inclusive através da rede WiFi do veículo.
Entende-se que o WiFi SSID pode estar relacionado ao nome do fabricante ou modelo do produto, quando aplicado em veículos, uma vez que opera sob condições restritas, como o proprietário do veículo acessando o veículo com chave válida, verificação durante inicialização dos módulos de rádio e telemática para confirmar que eles pertencem ao veículo específico , supervisão do proprietário do veículo, entre outros.

 

4.4 - A definição de prazos de implementação de mudanças em componentes automotivos está sujeito a diversos fatores que são incontroláveis, tais como prazos logísticos, liberação alfandegaria, flutuações de demanda, fila de implementação de modificações de produto em linhas de produção, datas padronizadas de implementação de modificações em linha de produção, entre outros.

As montadoras analisam vulnerabilidades de Segurança Cibernética considerando a segurança dos ocupantes. Os veículos atualmente são redes complexas distribuídas decentralizadas, existem muitas camadas de defesa Cibernética que protegem os ocupantes dos veículos.  Avaliando um passo pra trás, as montadoras definem como requisito as operadoras de telecomunicações a capacidade de cortar conexões com servidores se um incidente é detectado quando uma solução de software/firmware não pode ser desenvolvidas em um período curto o bastante para manter a conectividade e segurança. Esta estratégia pode ser executada quando uma falha grave demandar uma alteração de produto que leva mais tempo. 

 

Contribuição N°: 54
ID da Contribuição: 92697
Autor da Contribuição: WILLIAM GARCIA PIRES
Data da Contribuição: 17/05/2020 19:23:25
Contribuição:

 

Acreditamos que os requisitos mínimos de segurança cibernética para um produto de telecomunicações possam passar por testes em um laboratório de ensaio, um organismo certificador e consequentemente pela aprovação da Agência Anatel.

 

A forma como sugerida nesta Consulta N° 13, declarada pelo fabricante, não trará evidências condizentes de propriedade da segurança cibernética do produto, tornando-se assim um processo de certificação ineficaz.

 

Acreditamos que através de um estudo diante da ajuda das classes/entidades, possamos identificar os testes mínimos para os produtos, visando manter a celeridade do processo de certificação não onerando aos fabricantes/requerentes da homologação.

 

Neste primeiro momento, sugerimos testes de segurança cibernética baseado em um dos pilares abaixo ou nos 4 pilares da segurança para os produtos de telecomunicações, passando pelos laboratórios acreditados pela Agência:

 

1 – (BOOT) - Garantir que somente o software certificado pelo fabricante possa ser iniciado pelo produto. A finalidade deste teste é garantir que um invasor não poderá alterar o certificado ou o carregador de inicialização (boot loader), a fim de iniciar um firmware manipulado ou falso.

 

2 – (Elemento Seguro) - componente de hardware separado (chip – memória flash) que armazena todas as senhas, chaves e certificados. Durante as verificações, só responde com “sim” ou “não”. Ou seja, uma solicitação é feita através de uma senha com hash (hashed password) e, se estiver correta, o dispositivo responderá com um “sim”. Somente nesse caso, o repositório de segurança com os dados do usuário é liberado com a chave.

 

3 – (Firmware Seguro) – Depende da aplicação do produto e quais aplicativos estão integrados ao firmware do produto. Logo um aplicativo deve seguir os recursos de segurança que devem estar ativados por padrão. Nas interfaces da Web, como exemplo, o HTTPS deve estar ativado em lugar do HTTP. Da mesma forma, não devem ser usadas as senhas padrão. É preferível fornecer para cada dispositivo uma senha gerada aleatoriamente.

 

4 – (Gerenciamento de Correções) – Garantir que o produto possa ter atualizações contínuas do firmware de modo que, a decisão final seja feita por um humano. A importância de todo esse processo, até o momento da implantação (distribuição do firmware), seja compulsoriamente especificada e executada.

  

Justificativa:

 

Dessa forma, poderia ser criado pela Agência o uso da modalidade por etiquetagem (facultativo) já previsto pela Resolução 715 e não por declaração, como sugerido pela Consulta N° 13.

 

Dessa forma, haverá no mercado uma vantagem pelos fabricantes que aderirem a essa etiquetagem, diante de outros fabricantes que não aderirem. Outra vantagem, os usuários finais selecionarão os produtos adquiridos com um fator maior de segurança, e isso poderá levar os demais fabricantes a aderirem aos testes e ao processo de etiquetagem.

  

Contribuição N°: 55
ID da Contribuição: 92707
Autor da Contribuição: Sergio Mauro da Silva Maia
Data da Contribuição: 17/05/2020 20:30:44
Contribuição:

Item 4.1 a -Contribuição: Discordamos pois o texto desta Consulta Pública considera a aplicação destes requisitos de forma muito abrangente aos produtos que permitem acesso à internet. Sugerimos uma análise mais detalhada quanto à aplicabilidade destes requisitos em setores específicos, tais como, equipamentos terminais para acesso a banda larga via satélite. Citamos por exemplo que a permissão ao usuário para atualização de versão de software não é aplicável, sob risco de interrupção do serviço, e portanto não deve constar em tal declaração.

Item 4.2.1 -Contribuição: Embora a recomendação citada tenha conteúdo pertinente à esta proposta de Consulta Pública, entendemos que o atendimento a esta deve ser facultativo, e não obrigatório. Ressaltamos que a maioria dos produtos de telecomunicações em operação no Brasil são provinientes de fabricantes localizados em vários outros continentes e não somente na América Latina e Caribe, como consta na recomendaçao supracitada. As boas práticas adotadas pelos fabricantes de produtos de telecomunicações foram bem sucedidas até agora.  Item 4.3- Contribuição: Apoiamos este item. Recomendamos também  que a Agência  aceite    outras certificações internacionais   para equipamentos de telecomunicações a serem utilizados no Brasil  que atendam aos  requisitos  mínimos  desta  Consulta Pública.

Item 4.4.1 - Contribuição: Dentre as adaptações citadas acima, sugerimos a possibilidade de utilização do produto em questão em conjunto com outro dispositivo assessório que possua tais funções de segurança já implementadas. Deste modo a solução final apresentada ao usuário poderia ser composta de dois elementos, onde um complementa o outro. Como exemplo, citamos uma base de milhares de modens já instalados nas dependências do usuários e que não contemplem todos os requisitos desta CP. A adição de um equipamento assessório de baixo custo, que contemple as funções objeto desta CP, poderia viabilizar os critérios de segurança cibernética, mantendo o  usuário e evitando altos custos para a prestadora.

Item 4.4.3- Contribuição: Discordamos destas penalidades. Entendemos que tais regras só devam ser aplicadas aos produtos que forem certificados após a entrada em vigor desta nova resolução da Anatel referente à requisitos de segurança cibernética.

Justificativa:

Justificativa - Item 4.1.a:  Necessidade de uma analise mais detalhada quanto à aplicabilidade e escopo dos requisitos propostos  para a adoção de regras baseadas em fatos.

Justificativa - Item 4.2.1: A obrigatoriedade deste item geraria um custo significativo nas linhas de produção e possivelmente redundância em vários quesitos já contemplados por outros padrões de boas práticas (ex: Serie  ISO 2700X).

Justificativa - Item 4.3-  Maior flexibilidade e agilidade de entrada de produtos de telecomunicações no mercado.

Justificativa - Item 4.41 - Maior flexibilização de soluções alternativas.

Justificativa- Item 4.4.3- Evitar procedimentos anti-operacionais e altos custos para as prestadoras.

 Item:  5. REQUISITOS DE SEGURANÇA CIBERNÉTICA DOS EQUIPAMENTOS PARA TELECOMUNICAÇÕES

5.1.Equipamentos terminais que se conectam à Internet e equipamentos de infraestrutura de redes de telecomunicações, em suas versões finais destinadas à comercialização, devem:

Contribuição N°: 56
ID da Contribuição: 92543
Autor da Contribuição: Grace Kelly de Cassia Caporalli
Data da Contribuição: 13/05/2020 11:55:12
Contribuição:

MANIFESTAÇÃO: Revisar texto do item 5.1.

“Equipamentos de infraestrutura de redes de telecomunicações, em suas versões finais destinadas à comercialização, devem:”

Justificativa:

JUSTIFICATIVA: Alguns dos diversos requisitos listados abaixo são inviáveis de serem aplicados a todas as camadas da rede de telecomunicações, conforme expomos na justificativa ao item 1. Dispositivos de IoT e equipamentos com interfaces mais simples, devido seu propósito único e/ou recursos limitados, não dispõem de uma granularidade que possibilite os usuários finais a mexer em sua interface. Abaixo exploraremos mais detalhamento esses pontos, levando em consideração que essa sugestão será acatada.

 

Contribuição N°: 57
ID da Contribuição: 92592
Autor da Contribuição: Wilson Cardoso
Data da Contribuição: 14/05/2020 18:27:06
Contribuição:

Pedimos alterar o texto para : Equipamentos de infraestrutura de redes de telecomunicações, em suas versões finais destinadas à comercialização, devem....

Justificativa:

Pedimos ver manifestação anterior

Contribuição N°: 58
ID da Contribuição: 92635
Autor da Contribuição: Mariana Giostri M. Oliveira
Data da Contribuição: 15/05/2020 19:07:29
Contribuição:

Equipamentos terminais que se conectam à Internet e equipamentos de infraestrutura de redes de telecomunicações, em suas versões finais destinadas à comercialização, devem:

Justificativa:

Alguns dos diversos requisitos listados abaixo são inviáveis de serem aplicados a todas as camadas da rede de telecomunicações. Dispositivos de IoT e equipamentos com interfaces mais simples, devido seu propósito único e/ou recursos limitados, não dispõem de uma granularidade que possibilite os usuários finais a mexer em sua interface, por exemplo.

Contribuição N°: 59
ID da Contribuição: 92645
Autor da Contribuição: LUCIMARA DESIDERA
Data da Contribuição: 15/05/2020 19:50:38
Contribuição:

Gostaríamos de sugerir que, além de uma lista única genérica de requisitos comuns a todos os dispositivos, o documento inclua sessões específicas para as diferentes categorias, como endpoints de alta complexidade, gateways e CPEs e equipamentos de infraestrutura de redes (core), a fim de elevar o patamar de exigências de segurança onde for necessário e os recursos computacionais permitirem, e para esclarecer a aplicabilidade.

Justificativa:

Ainda que a proposta descreva que a aplicação de cada requisito deve levar em consideração diferentes características técnicas (quantidade de memória, capacidade de processamento de dados, interfaces para usuário, interfaces de comunicação, etc.) do equipamento, e os fins a que se destinam, é importante considerar que determinadas classes de dispositivos podem demandar requisitos mais específicos. Por exemplo, equipamentos que fazem parte da infraestrutura do provedor de conectividade e os que são instalados pelo provedor de serviço nas residências de assinantes, devem permitir não apenas a atualização de software/firmware, mas requer também capacidade de gerência remota segura, permitindo ao provedor de serviços coletar informações de log, alterar parâmetros de configurações, ou mesmo intervenções necessárias à mitigação de riscos de segurança, entre outras.

Contribuição N°: 60
ID da Contribuição: 92663
Autor da Contribuição: Telma do Carmo Canotilho
Data da Contribuição: 16/05/2020 10:06:37
Contribuição:
Justificativa:
Contribuição N°: 61
ID da Contribuição: 92695
Autor da Contribuição: Tiago Brocardo Machado
Data da Contribuição: 17/05/2020 17:42:04
Contribuição:

 A Ericsson entende  a preocupação da ANATEL com o tema de cibersegurança visto que em uma sociedade cada vez mais digital a proteção dos dispositivos e da infraestrutura de rede de telecomunicações torna-se cada vez mais importante para a manutenção da operação  e confiabilidade do setor de Tecnologia da Informação e Comunicação. Entretanto, sugere-se detalhar e segmenter a aplicabilidade desta consulta pública aos diferentes setores da indústria de telecomunicações segmentando-a na seguinte estruturação: Infraestrutura de acesso e transporte, Core e por fim, dispositivos destinados ao consumidor final (Devices, smartphones, CPE’s, IoT, etc). Desta forma sugere-se a remoção dos seguintes itens do texto final da consulta afim de enquadrar o objetivo desta consulta pública com o ambiente de desenvolvimento tecnológico e o alinhamento as tendências globais de segurança cibernética:  5.1.2: b), c) e d) ; 5.1.3: a) e g);  5.1.4 d); 5.1.5 b); 5.1.6: a) e b).

Justificativa:

A Ericsson recomenda a ANATEL a segmentar a aplicação dos requisitos mínimos de segurança cibernética para os equipamentos de infraestrutura de telecomunicações de acesso e transporte, Core e dispositivos destinados ao usuário final (Devices, Smartphones, CPE, etc) visto que existem diferentes graus de complexidade e diversidade existente entre os equipamentos fornecidos pela indústria. Para exemplificar a preocupação que identificamos acima, vários dos requisitos listados no Item 5 da regra proposta pela ANATEL só poderiam ser aplicados aos elementos principais de Smartphones/ IoT / CPEs e seria impossível, devido a criticidade da operação, interface e configuração, serem aplicáveis a uma instância de Core, como observa-se no item 5.1.2 c) ou 5.1.6.a).

 

Segundo o mais recente Ericsson Mobility report, que pode ser encontrado no seguinte link: https://www.ericsson.com/en/mobility-report, estudo global no qual a Ericsson levanta informações do setor de telecomunicações de diferentes países incluindo o Brasil,  o número de subscrições de telefonia móvel no fim de 2019 atingiu 9 bilhões de conexões e estima-se que o número de dispositivos IoT até 2024 deva atingir 5 bilhões de conexões, o que em si retrata a diversidade de conexões com diferentes necessidade e requisitos de dispositivos conectados à rede. Com essa percepção de pluralidade de requisitos nota-se que a definição de procedimentos fixos de operação pode engessar o avanço tecnológico do setor e assim sugere-se a migração dos itens 5.1.3 a),  5.1.4 d) e 5.1.5 b) para consulta pública a ser destinada exclusivamente a ciber segurança de dispositivos, CPEs e equipamentos que se enquadrem nas definições de dispositivos / IoT.

O setor de Telecomunicações produz tecnologias inovadoras que estão crescendo e evoluindo continuamente. À medida que novos modelos de prestação de serviços e negócios são desenvolvidos rapidamente, os existentes são constantemente atualizados. As soluções e os esforços de segurança cibernética devem ser igualmente dinâmicos, altamente interoperáveis & 8203;& 8203;e adaptáveis & 8203;& 8203;para lidar com as ameaças em constante mudança impostas a essas novas tecnologias. Com bilhões de dispositivos conectados, variando de objetos onipresentes a infraestrutura crítica, agora suscetíveis a ameaças cibernéticas, a adaptabilidade e a cibersegurança estão intrinsecamente ligadas. Portanto, ao considerar um conjunto mínimo de requisitos para a rede de telecomunicações, a Ericsson recomenda à ANATEL que atenda à necessidade de uma regulamentação baseada em princípios, flexível o suficiente para manter-se atualizado com os recentes ciclos de desenvolvimento e inovação da tecnologia a níveis globais de padronização.

 Item:  5.1.1.Quanto à atualização de software/firmware:

a) Possuir mecanismos periódicos, seguros e automatizados para atualização de software/firmware que empregam métodos adequados de criptografia, autenticação e integridade.

b) Permitir que os usuários verifiquem, de forma não automatizada, a disponibilidade de atualizações de software/firmware.

Contribuição N°: 62
ID da Contribuição: 92259
Autor da Contribuição: Henrique Mendonça Castelar Campos
Data da Contribuição: 04/05/2020 11:06:18
Contribuição:

c) Informar aos usuários o fim de vida das atualizações de software/frimware de segurança do produto.

d) Permitir que os usuários tenham conhecimento das mudanças feitas no software/frimware após a atualização de software por meio do changelog (descrição das mudanças no softwre/frimware do produto).

Justificativa:

c) Os fabricantes não vão fornecer atualizações de software/frimware para sempre, pois manter um software/frimware de um equipamento tem um custo. Por isso, acredito que os fabricantes deveriam informar ao usuário até quando o equipamento dele receberá atualizações de segurança, para que assim ele possa preparar para trocar o equipamento assim que ele ficar vulnerável.

d) É importante que os usuários possam saber o porquê de uma atualização de software, para que assim não haja desconfiança por parte do usuário.

Contribuição N°: 63
ID da Contribuição: 92544
Autor da Contribuição: Grace Kelly de Cassia Caporalli
Data da Contribuição: 13/05/2020 13:17:05
Contribuição:

MANIFESTAÇÃO: Retirar “automatizados” do texto.

Justificativa:

JUSTIFICATIVA: Em redes de grande porte, corporativas e de missão crítica um procedimento atualização automatizada pode paralisar por um tempo considerável os recursos da rede, e uma atualização de vários dispositivos simultaneamente também pode causar um colapso da mesma. Os administradores destas redes não esperam (ou não querem) atualizações automatizadas, a atualização de software neste tipo de rede deve ocorrer apenas por determinação dos administradores de forma coordenada e muito bem programada, de modo a manter a integridade da rede e dos serviços que por ela trafegam. Estas redes são instaladas e mantidas por pessoal altamente treinado, inclusive em requisitos de segurança cibernética.

Contribuição N°: 64
ID da Contribuição: 92605
Autor da Contribuição: Darles Leandro C. Gomes
Data da Contribuição: 15/05/2020 16:41:01
Contribuição:

Tais mecanismos devem ser avaliados, primeiramente, por um laboratório acreditado. 

Justificativa:

Pelo menos na certificação inicial do equipamento, deveria ter uma avaliação, de um laboratório acreditado, da criptografia utilizada no equipamento. 

Contribuição N°: 65
ID da Contribuição: 92613
Autor da Contribuição: Gilberto Martins de Almeida Filho
Data da Contribuição: 15/05/2020 17:14:53
Contribuição:

Alterar a letra a) do item 5.1.1

"5.1.1.Quanto à atualização de software/firmware:

a) Quando aplicável, possuir mecanismos periódicos, seguros e automatizados para atualização de software/firmware que empregam métodos adequados de criptografia, autenticação e integridade.

b) Permitir que os usuários verifiquem, de forma não automatizada, a disponibilidade de atualizações de software/firmware."

Justificativa:

Permitir que fornecedores de equipamentos forneçam atualizações de segurança sem um cronograma predeterminado, em vez disso, que disponibilizem as atualizações para os usuários finais assim que as vulnerabilidades forem resolvidas e estiverem prontas para serem instaladas.
Além disso, na maioria dos casos , o segmento automotivo, a atualização é realizada pela concessionária, e muitas vezes, o equipamento é trocado ao invés de atualizado.

Questionamento ANATEL: De quais formas não automatizadas o usuário final poderá verificar se há uma nova atualização?

Contribuição N°: 66
ID da Contribuição: 92646
Autor da Contribuição: LUCIMARA DESIDERA
Data da Contribuição: 15/05/2020 19:52:37
Contribuição:
  • Sugerimos renomear o título para “Quanto à atualização de software/firmware e gerenciamento remoto” e incluir uma funcionalidade adicional, para gateways/CPE e equipamentos de infraestrutura, referente a gerenciamento e administração remotos usando um protocolo de criptografia apropriado. Adicionalmente, tais funcionalidades devem suportar que se restrinja o acesso a partir de origens específicas.
  • Sugerimos acrescentar um tópico que requeira que as configurações existentes sejam preservadas nos processos de atualização.
  • Justificativa:
  • Ter a capacidade de gerenciar dispositivos remotamente, e de forma segura, é fundamental para o prestador de serviço de internet. Sem um mecanismo apropriado, os prestadores de serviço não são capazes de acessar equipamentos instalados em localidades remotas para, por exemplo, alterar configurações inseguras, implementar medidas de mitigação de alguma vulnerabilidade, coletar logs para análise, alterar senhas, etc. Adicionalmente, tal funcionalidade não deve estar acessível de maneira irrestrita, devendo ser possível limitar seu acesso, por exemplo, a redes de gerência.
  • As configurações de segurança anteriormente realizadas devem ser preservadas.
  • Contribuição N°: 67
    ID da Contribuição: 92657
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:
    Justificativa:
    Contribuição N°: 68
    ID da Contribuição: 92671
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:17:14
    Contribuição:

     

    c) Possuir mecanismos para identificar se o software/firmware foi atualizado de acordo com as recomendações do fabricante, evitando atualização que possam incluir backdoors

     

    d) Possuir mecanismos para permitir retornar as configurações anteriores em caso de detecção de não conformidade com as configurações do fabricante.

     

    e) Possuir mecanismos de informar notificações sobre alterações de segurança devido às atualizações.

     

    f) Se identificado uma vulnerabilidade no software/firmware garantir que o equipamento seja atualizado.

     

    g) Possuir os mesmos mecanismos de segurança para softwares/firmwares em modelo Beta ou versão não final.

      

    Justificativa:

     

    Acréscimo de novas alíneas Justificativa: Funcionalidades relevantes referente a atualização)

      

    Contribuição N°: 69
    ID da Contribuição: 92684
    Autor da Contribuição: Karla Menandro Pacheco da Silva
    Data da Contribuição: 17/05/2020 10:40:21
    Contribuição:

    Caso não seja possível excluir os componentes veiculares do escopo da certificação sugerimos:

    Alterar a letra a) do item 5.1.1


    a) Quando aplicável, possuir mecanismos, seguros e automatizados para atualização de software/firmware que empregam métodos adequados de criptografia, autenticação e integridade. 

    Justificativa:

    Permitir que fornecedores de equipamentos forneçam atualizações de segurança sem um cronograma predeterminado, em vez disso, que disponibilizem as atualizações para os usuários finais assim que as vulnerabilidades forem resolvidas e estiverem prontas para serem instaladas.
    Além disso, na maioria dos casos , o segmento automotivo, a atualização é realizada pela concessionária, e muitas vezes, o equipamento é trocado ao invés de atualizado. 

    Contribuição N°: 70
    ID da Contribuição: 92698
    Autor da Contribuição: Paulo Cesar Valete
    Data da Contribuição: 17/05/2020 19:43:57
    Contribuição:

    Incluir a alínea “c” conforme segue:

    Permitir ativar/desativar a atualização automática de software/firmware, inclusive de forma remota.

    Justificativa:

    A Telefônica Brasil S.A. entende que essa facilidade é fundamental, tanto para o Usuário como para a Prestadora, pois permite o controle das versões de software/firmware impedindo que versões não homologadas sejam instaladas inadvertidamente. Além disso, o próprio mecanismo de atualização automática pode vir a ser porta de entrada para ataques cibernéticos. Nesse caso, é fundamental a desativação imediata do próprio mecanismo.

    Contribuição N°: 71
    ID da Contribuição: 92708
    Autor da Contribuição: Sergio Mauro da Silva Maia
    Data da Contribuição: 17/05/2020 20:41:12
    Contribuição:

    Contribuição: Para o caput acima, sugerimos a substituição da expressão “comercialização”, pela palavra “venda”, conforme abaixo.

    “5.1.Equipamentos terminais que se conectam à Internet e equipamentos de infraestrutura de redes de telecomunicações, em suas versões finais destinadas venda , devem:

    Justificativa:

    Justificativa:  Para setores específicos, tais como Serviço de Internet Banda larga via satélite,  a maior parte dos equipamentos instalados é em regime de comodato, onde a prestadora se encarrega de fazer as adequações do software de forma remota. Logo, o texto não se aplica a este setor de mercado.

     Item:  5.1.2.Quanto à instalação e à operação:

    a) Implementar rotinas simplificadas para sua instalação e configuração, evitando potenciais falhas de segurança não intencionais.

    b) Realizar verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade.

    c) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado.

    d) Implementar ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários, alteração de configurações do sistema e funcionamento do sistema.

    e) Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado.

    Contribuição N°: 72
    ID da Contribuição: 92545
    Autor da Contribuição: Grace Kelly de Cassia Caporalli
    Data da Contribuição: 13/05/2020 13:24:44
    Contribuição:

    MANIFESTAÇÃO 1- item a : Revisar texto do subitem 5.1.2. a)

    a)   Implementar rotinas  ADEQUADAS para sua instalação e configuração, evitando potenciais falhas de segurança não intencionais.

    MANIFESTAÇÃO 2- item c : Exclusão do item c) do 5.1.2.

    MANIFESTAÇÃO 3-item d : Exclusão do subitem d) do 5.1.2.

    Justificativa:

    JUSTIFICATIVA 1 - item a: Por questões de responsabilidade e prestação de contas, as empresas de TIC já implementam rotinas internas que prezem pela segurança e integridade das informações, conforme as necessidades. Além disso, em virtude da complexidade da arquitetura das redes e CPEs, uma abordagem simplificada poderá, muitas vezes, comprometer a própria segurança cibernética que está se buscando garantir.

    JUSTIFICATIVA 2- item c: Exclusão do requisito em virtude do alto custo para implementação desse requisito, além de sua incompatibilidade com a classe e sofisticação de equipamentos CPE. Esse requisito deve existir exclusivamente em camadas mais avançadas da infraestrutura, e não na ponta da rede.

    JUSTIFICATIVA 3- item d : O fabricante do equipamento não tem controle nem visibilidade de como o usuário de seus equipamentos os utiliza, de modo que não caberia ao fabricante o registro de logs de seu uso. Eventual obrigação regulatória nesse sentido, poderia, inclusive, levar questionamento quanto ao descumprimento pelo fabricante do Marco Civil da Internet aprovado pela Lei nº 12.965/2014. Nesse sentido, sugerimos que o texto seja excluído ou que esclareça a natureza do log que se deseja seja mantido.

    Contribuição N°: 73
    ID da Contribuição: 92573
    Autor da Contribuição: LUIZ GUSTAVO DE MORAIS
    Data da Contribuição: 14/05/2020 14:46:35
    Contribuição:

    5.1.2. Quanto à instalação e à operação:

      e) Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado.

    Justificativa:

    Entende-se que o requisito de considerar o nome, versão e data de lançamento do software/firmware na documentação fornecida em forma de Manual de Proprietário não seria relevante pois os terminais que se conectam a internet podem ter seu software/firmware atualizados tornando a documentação inicial desatualizada, além de desnecessária e ate mesmo pode causar conflitos de entendimento.

    Contribuição N°: 74
    ID da Contribuição: 92582
    Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
    Data da Contribuição: 14/05/2020 17:08:51
    Contribuição:

    5.1.2.c - Esse requisito pode ser inadequado para dispositivos básicos de IoT de consumidor com interface de usuário limitada

    5.1.2.d - Para dispositivos IoT pequenos ou pouco sofisticados, pode haver capacidade de programação ou armazenamento residente inadequado no dispositivo para implementar e / ou armazenar logs no dispositivo; esse requisito pode precisar fazer provisões para soluções de log externas.

    Justificativa:

    A BSA acredita que os padrões de cibersegurança propostos na consulta podem ser mais eficazes se estiverem alinhados com os padrões reconhecidos internacionalmente. Esses padrões fornecem orientações específicas para desenvolvedores e fabricantes sobre como implementar certos requisitos. Os padrões de cibersegurança propostos devem ser atualizados com referências a padrões apropriados onde quer que existam. Além disso, alguns padrões não são universalmente aplicáveis & 8203;& 8203;ao amplo escopo de dispositivos cobertos pela consulta.

    Contribuição N°: 75
    ID da Contribuição: 92597
    Autor da Contribuição: Mateus de Faria Pereira
    Data da Contribuição: 15/05/2020 15:12:06
    Contribuição:

    c) Caso haja mais de um modelo de Segurança Operacional aceitável disponível no equipamento este deve primeiro por padrão utilizar sempre o modelo mais seguro.

    Justificativa:

    Caso haja mais de um modelo de Segurança Operacional disponível no equipamento, ele deve primeiro por padrão utilizar o mais seguro.

    Por exemplo: Quando um dipositivo móvel deseja se conectar a um Wifi Access Point ele deve possuir ao menos 3 modelos de segurança aplicados. Primeiramente o dispositivo móvel deve por questões de segurança utilizar do modelo mais seguro WPA3 e caso não tiver sucesso tentar outros modelos. Esta ação faz com que o equipamento opere sempre da forma mais segura possível. 

    Contribuição N°: 76
    ID da Contribuição: 92606
    Autor da Contribuição: Darles Leandro C. Gomes
    Data da Contribuição: 15/05/2020 16:47:41
    Contribuição:

    Tais itens devem passar sob a avaliação de um laboratório acreditado e não somente declaração.  

    Justificativa:

    Por se tratar de segurança de dados de usuários e evitar acessos indevidos ao equipamento há necessidade de uma avaliação mais rigorosa do equipamento no aspecto de segurança cibernética. 

    Contribuição N°: 77
    ID da Contribuição: 92614
    Autor da Contribuição: Gilberto Martins de Almeida Filho
    Data da Contribuição: 15/05/2020 17:14:53
    Contribuição:

    Excluir a letra d) e alterar as letras a) e e) do item 5.1.2

    "5.1.2.Quanto à instalação e à operação:

    a) Implementar rotinas simplificadas para sua de instalação e configuração, evitando potenciais falhas de segurança não intencionais.
    b) Realizar verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade.
    c) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado.
    d) Implementar ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários, alteração de configurações do sistema e funcionamento do sistema.
    e) Quando fornecido com documentação, esta
    Deverá ser possível consultar as informações referentes a: nome, versão, data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado."

    Justificativa:

    a) Anfavea gostaria de uma definição para o termo "simplificada".

    d) Não há necessidade de haver um registro de atividades do usuário, considerando que o acesso aos sistemas embarcados no veículo somente são acessíveis ao uso do controle de acesso do próprio veículo (Chave, sistema de alarme, etc..)

    e) Se as informações estiverem na documentação, a cada nova atualização ou alteração do software/firmware a documentação deverá ser retrabalhada.

    Contribuição N°: 78
    ID da Contribuição: 92620
    Autor da Contribuição: JOAO LUIZ FREIRE DA COSTA BEZERRA
    Data da Contribuição: 15/05/2020 17:36:49
    Contribuição:

    "c) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado."

    Não se considera adequado exigir que o equipamento seja reinicializado automaticamente.

    Justificativa:

    Essa ação pode comprometer o funcionamento sistêmico do dispositivo, dependendo da tarefa que estiver sendo realizada, podendo até comprometer a segurança física de uma atividade operacional.

    Contribuição N°: 79
    ID da Contribuição: 92636
    Autor da Contribuição: Mariana Giostri M. Oliveira
    Data da Contribuição: 15/05/2020 19:10:12
    Contribuição:

    Implementar rotinas simplificadas adequadas para sua instalação e configuração, evitando potenciais falhas de segurança não intencionais.

    **

    Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado.

    **

    Implementar ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários, alteração de configurações do sistema e funcionamento do sistema.

    **

    Não utilizar credenciais e senhas iniciais para acesso às suas configurações que sejam iguais entre todos os dispositivos produzidos.

    Justificativa:

    Em virtude da complexidade da arquitetura das redes e CPEs, uma abordagem simplificada poderá, muitas vezes, comprometer a própria segurança cibernética que está se buscando garantir. Vale pontuar que as empresas de TIC têm cada vez mais se comprometido a implementar rotinas e estruturas que prezam pela segurança e integridades de seus equipamentos, bem como de suas informações.

    **

    O requisito disposto acima é incompatível com a classe e sofisticação dos equipamentos CPE.

    Além disso, o alto custo atrelado à sua implementação faz com que nos pareça ser um requisito que deva ser exclusivamente estabelecido para equipamentos que compõem as camadas mais avançadas da infraestrutura de rede, e não na sua ponta.

    **

    A Brasscom sugere a exclusão desse dispositivo por dois motivos, sendo um técnico e outro jurídico:

  • Técnico - Na medida em que o fabricante do equipamento não tem controle nem visibilidade de como o usuário de seus equipamentos os utiliza, não caberia a ele registrar os logs de seu uso.
  • Jurídico - Eventual obrigação regulatória nesse sentido pode inclusive levar a questionamentos legais quanto ao descumprimento pelo fabricante do disposto no Marco Civil da Internet aprovado pela Lei nº 12.965/2014.
  • Caso a preocupação da Anatel esteja voltada para o mapeamento de performance da máquina, para fins de identificação de vulnerabilidades em seu funcionamento, sugerimos que sejam feitas alterações na redação para limitar esse registro a comportamentos críticos da performance do equipamento e de seus softwares embutidos, com a anonimização de quaisquer dados pessoais.

    **

    Equipamentos de baixo custo normalmente vêm com senha padrão comum a todos. Sugerimos a exclusão desse item, visto que o subitem c) já estabelece que seja forçada a alteração da senha de acesso à configuração do equipamento na primeira utilização.

    Contribuição N°: 80
    ID da Contribuição: 92647
    Autor da Contribuição: LUCIMARA DESIDERA
    Data da Contribuição: 15/05/2020 19:53:31
    Contribuição:

    Quanto ao item 5.1.2.a: sugerimos que o requisito acrescente, de forma explícita, que os procedimentos de instalação e que as configurações padrão de fábrica devem seguir o princípio da segurança por padrão (by default).

     

    Quanto ao item 5.1.2.e sugerimos que seja requisito obrigatório o fornecimento de documentação detalhada, ainda que em formato somente digital, referente ao equipamento e software básico, assim como outros softwares de terceiros utilizados na elaboração do produto.

     

    Justificativa:

    Em relação ao item 5.1.2.a: considerando o pouco conhecimento da grande maioria dos usuários no que tange às opções seguras na configuração dos dispositivos, levando-os a utilizarem os dispositivos sem alterar as configurações padrão de fábrica, torna-se essencial adotar no desenvolvimento dos equipamentos, práticas que suportem o paradigma da segurança por padrão (by default). Neste sentido, sugerimos que o requisito acrescente, de forma explícita, que as a escolha dos parâmetros para configurações padrão de fábrica seja guiada por opções nativamente seguras, a fim de evitar uma configuração inicial vulnerável.

     

    Em relação ao item 5.1.2.e: grande parte dos dispositivos de rede são desenvolvidos a partir de diversos componentes de diferentes organizações. Se alguma vulnerabilidade é descoberta em algum componente, por exemplo uma biblioteca de software, é muito provável que diversos produtos que se utilizam daquele componente serão afetados por tal vulnerabilidade. A complexidade das cadeias de fornecimento, assim como questões de distribuições OEM (Original Equipment Manufacturer), podem camuflar a identidade de componentes e dificultar o rastreamento de produtos afetados. Por esta razão, é fundamental que se requeira documentação detalhada sobre o produto e seus componentes, inclusive com suas versões, ainda que em formato exclusivamente digital, para que seja possível mapear o potencial impacto de componentes vulneráveis sobre o produto final, e então buscar sua correção.

    Contribuição N°: 81
    ID da Contribuição: 92658
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:
    Justificativa:
    Contribuição N°: 82
    ID da Contribuição: 92672
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:18:09
    Contribuição:

     

    f) Realizar verificação da integridade do software/firmware durante a inicialização do sistema, sendo capaz de alertar ao usuário nos casos de comprometimento de sua integridade e em caso de versões beta e versões não final, alertar sobre o modelo atual.

     

    g) Possuir mecanismo de monitoramento de comportamentos não usuais do software/firmware, alertando o usuário ou reiniciando-se automaticamente caso um comportamento suspeito seja detectado e permitindo o usuário a escolha de uma inicialização com os parâmetros de segurança de fábrica.

     

    h) Quando fornecido com documentação, esta deverá conter o nome, a versão, a data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado e também as release Betas ou versões não finais.

     

    i) Permitir rastrear todo o tráfego da rede e realizar o controle de acessos para que pessoas má intencionadas não tenham acesso a dados confidencias  (acesso baseada em confiança zero),

     

    j) Permitir a re-autenticação do dispositivo quando ele se mover entre diferentes redes de acesso, com a implementação do SEAF ( SECURITY ANCHOR FUNCTION).

     

    l) Permitir a utilização de identificação oculta até que o equipamento que faz acesso a rede seja autenticado, garantindo que depois dessa operação seja divulgada a identificação do usuário

      

    Justificativa:

     

    (Acréscimo de novas alíneas – Justificativa: acréscimo de funcionalidades consideradas relevantes)

      

    Contribuição N°: 83
    ID da Contribuição: 92685
    Autor da Contribuição: Karla Menandro Pacheco da Silva
    Data da Contribuição: 17/05/2020 10:43:58
    Contribuição:

    Caso não seja possível excluir os componentes veiculares do escopo da certificação, sugerimos:

    Alterar as letras a), e e) do item 5.1.2 e excluir a letra d) 

    a) Implementar rotinas de instalação e configuração, evitando potenciais falhas de segurança não intencionais.]

    d) Implementar ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários, alteração de configurações do sistema e funcionamento do sistema.

    e)  Deverá ser possível consultar as informações referentes a: nome, versão, data de lançamento e as funcionalidades do software/firmware e/ou sistema operacional utilizado. 

    Justificativa:

    a) Gostariamos de uma definição para o termo "simplificada".

    d) Não há necessidade de haver um registro de atividades do usuário, considerando que o acesso aos sistemas embarcados no veículo somente são acessíveis ao uso do controle de acesso do próprio veículo (Chave, sistema de alarme, etc..)

    e) Se as informações estiverem na documentação, a cada nova atualização ou alteração do software/firmware a documentação deverá ser retrabalhada. 

    Contribuição N°: 84
    ID da Contribuição: 92699
    Autor da Contribuição: Paulo Cesar Valete
    Data da Contribuição: 17/05/2020 19:48:44
    Contribuição:

    Dar nova redação à alínea “d” conforme segue:

    Implementar ferramenta de registro de atividades (logs) relacionadas à autenticação de usuários, alteração de configurações, funcionamento geral do sistema, bem como do mecanismo de monitoramento de comportamentos não usuais, em especial no caso de haver alguma ação automática devido a comportamento suspeito nos Roteadores de Rede.

    Justificativa:

    A Telefônica Brasil S.A. esclarece que os reinícios automáticos de equipamentos de telecomunicações, e.g. Roteadores de Rede, podem significar questões relevantes do ponto de vista da segurança cibernética. Assim, precisam ser mais bem detalhados, em termos de log, para subsídio da equipe técnica de suporte.

    Contribuição N°: 85
    ID da Contribuição: 92709
    Autor da Contribuição: Sergio Mauro da Silva Maia
    Data da Contribuição: 17/05/2020 20:45:47
    Contribuição:

    Item 5.1.2.c - Contribuição: Discordamos  da  aplicabilidade dessa funcionalidade emcarcada no terminal do usuário   para o  serviço de banda larga via satélite. Neste serviço , todos os terminais se comunicam com a estação de controle , também chamada de estação Gateway que tem a inteligência incorporada para reiniciar o terminal do usuário em casos de  condições anormais.

    Justificativa:

    Justificativa: Esta inteligência é aplicada às Centrais de trafego, ou Gateways via satélite.

     

     Item:  5.1.3.Quanto ao acesso ao equipamento:

    a) Não utilizar credenciais e senhas iniciais para acesso às suas configurações que sejam iguais entre todos os dispositivos produzidos.

    b) Não utilizar senhas que sejam derivadas de informações de fácil obtenção por métodos de escaneamento de tráfego de dados em rede, tal com endereços MAC - Media Access Control.

    c) Forçar, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.

    d) Não permitir o uso de senhas em branco ou senhas fracas.

    e) Possuir mecanismos de defesa contra tentativas exaustivas de acesso não autorizado (ataques de autenticação por força bruta).

    f) Garantir que os mecanismos de recuperação de senha sejam robustos contra tentativas de roubo de credenciais.

    g) Não utilizar credenciais e senhas definidas no próprio código fonte do software/firmware e que não podem ser alteradas (hard-coded).

    h) Proteger senhas, chaves de acesso e credenciais armazenadas ou transmitidas utilizando métodos adequados de criptografia ou hashing.

    Contribuição N°: 86
    ID da Contribuição: 92574
    Autor da Contribuição: LUIZ GUSTAVO DE MORAIS
    Data da Contribuição: 14/05/2020 14:53:29
    Contribuição:

     

      5.1.3 Quanto ao acesso do usuário final ao equipamento:

      Todos os subitens.

    d) Não permitir o uso de senhas em branco ou senhas fracas.

    Justificativa:

    Justificativa Todos os Subitems: Existem diferenças entre as credenciais do usuário necessárias para acessar a configuração do equipamento e as credenciais usadas pelo equipamento para acessar a Internet ou a infraestrutura de rede do provedor do serviço. Para o escopo deste requisito, entende-se que ele se refere ao acesso do Usuário Final ao equipamento para fins de configuração e não do uso regular do equipamento. Sugere-se deixar claro, incluindo o uso do termo "usuário final" na seção 5.1.3

    Justificativa item d) As senhas iniciais de acesso do usuário final ao equipamento são definidas seguindo procedimentos da indústria em relação a Segurança Cibernética em termos de quantidade de caracteres e uso de caracteres maiúsculos e minúsculos.

    Algumas senhas de acesso podem ser definidas pelo usuário com menor nível de complexidade em alguns casos, como acesso de WiFi hotspot, porem ainda não permitindo que seja definida senhas em branco.

    Contribuição N°: 87
    ID da Contribuição: 92583
    Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
    Data da Contribuição: 14/05/2020 17:09:47
    Contribuição:

    5.1.3 - As senhas não são necessárias para todos os dispositivos; dependendo da função, os dispositivos IoT podem não precisar de nenhuma proteção por senha. Ao mesmo tempo, dispositivos mais sensíveis devem adotar abordagens mais sofisticadas ao gerenciamento de identidades, incluindo autenticação multifatorial, tecnologias de logon único e / ou autenticação biométrica ou baseada em contexto. Esta seção completa (5.1.3.a-h) deve ser desagregada em orientações separadas para diferentes classes de dispositivos; como alternativa, deve ficar claro que os requisitos de gerenciamento de senha e identidade não se aplicam a dispositivos que não exigem gerenciamento de identidade ou controles de acesso.

    Justificativa:

    A BSA acredita que os padrões de cibersegurança propostos na consulta podem ser mais eficazes se estiverem alinhados com os padrões reconhecidos internacionalmente. Esses padrões fornecem orientações específicas para desenvolvedores e fabricantes sobre como implementar certos requisitos. Os padrões de cibersegurança propostos devem ser atualizados com referências a padrões apropriados onde quer que existam. Além disso, alguns padrões não são universalmente aplicáveis & 8203;& 8203;ao amplo escopo de dispositivos cobertos pela consulta.


     

    Contribuição N°: 88
    ID da Contribuição: 92598
    Autor da Contribuição: Mateus de Faria Pereira
    Data da Contribuição: 15/05/2020 15:22:49
    Contribuição:

    i) O fornecedor deve empregar o modelo de acesso Role Based Access Control (RBAC), correlacionando tipos de usuários aos domínios e funções.

    j) Timeout de Sessão Inativa

    Justificativa:

    i) modelo recomendado pela 3GPP 3GPP TS 33.117 V16.4.1 -  Catalogue of general security assurance requirements - seção 4.2.3.4.6.2 - Authorization and access control

    j) modelo recomendado pela 3GPP 3GPP TS 33.117 V16.4.1 -  Catalogue of general security assurance requirements - seção 4.2.3.5.2 - Protecting sessions

    Contribuição N°: 89
    ID da Contribuição: 92615
    Autor da Contribuição: Gilberto Martins de Almeida Filho
    Data da Contribuição: 15/05/2020 17:14:53
    Contribuição:

    Alterar o item 5.1.3 e excluir as letras c) e d)

    "5.1.3 Quanto ao acesso do usuário final ao equipamento: 

    c) Forçar, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.
    d) Não permitir o uso de senhas em branco ou senhas fracas."

    Justificativa:

    Existem diferenças entre as credenciais do usuário necessárias para acessar a configuração do equipamento e as credenciais usadas pelo equipamento para acessar a Internet ou a infraestrutura de rede do provedor do serviço. Para o escopo deste requisito, entende-se que ele se refere ao acesso do Usuário Final ao equipamento para fins de configuração. Sugere-se deixar claro, incluindo o uso do termo "usuário final" na seção 5.1.3.

    Para requisitos de instalação e operação, equipamentos de infraestrutura e equipamentos terminais devem ter procedimentos distintos, dado a diferença de criticidade de ambos.

    Contribuição N°: 90
    ID da Contribuição: 92648
    Autor da Contribuição: LUCIMARA DESIDERA
    Data da Contribuição: 15/05/2020 19:54:39
    Contribuição:

    Quanto ao 5.1.3.g tal requisito deve ser aplicável também para chaves criptográficas

    Adicionalmente, sugerimos que chaves criptográficas não venham geradas de fábrica, mas sim na primeira inicialização do serviço.

    Justificativa:

    Da mesma forma que o uso de senhas comuns a todos os dispositivos e hard-coded pode ser abusado para acesso indevido, o mesmo se aplica a chaves criptográficas para uso, por exemplo, em SSH. É importante evitar situações como a descrita em

    https://news.softpedia.com/news/Over-250-000-Home-Routers-Found-with-Duplicate-SSH-Keys-473651.shtml

     

    Contribuição N°: 91
    ID da Contribuição: 92659
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:
    Justificativa:
    Contribuição N°: 92
    ID da Contribuição: 92673
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:18:58
    Contribuição:

     

    i) Garantir todos os itens mencionados acima para qualquer versão de software/firmware (beta e versões não final) 

      

    Justificativa:

     

    (Acréscimo de nova alínea – Justificativa: Para enfatizar que são características para todas versões)

      

    Contribuição N°: 93
    ID da Contribuição: 92686
    Autor da Contribuição: Karla Menandro Pacheco da Silva
    Data da Contribuição: 17/05/2020 10:46:10
    Contribuição:

    Caso não seja possível excluir os componenets automotivos do escopod a certificação, sugerimos:

    Alterar o item 5.1.3 e excluir as letras c) e d)

    5.1.3 Quanto ao acesso do usuário final ao equipamento: 

    c) Forçar, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.
    d) Não permitir o uso de senhas em branco ou senhas fracas. 

    Justificativa:

    Existem diferenças entre as credenciais do usuário necessárias para acessar a configuração do equipamento e as credenciais usadas pelo equipamento para acessar a Internet ou a infraestrutura de rede do provedor do serviço. Para o escopo deste requisito, entende-se que ele se refere ao acesso do Usuário Final ao equipamento para fins de configuração. Sugere-se deixar claro, incluindo o uso do termo "usuário final" na seção 5.1.3.

    Para requisitos de instalação e operação, equipamentos de infraestrutura e equipamentos terminais devem ter procedimentos distintos, dado a diferença de criticidade de ambos. 

    Contribuição N°: 94
    ID da Contribuição: 92700
    Autor da Contribuição: Paulo Cesar Valete
    Data da Contribuição: 17/05/2020 19:53:26
    Contribuição:

    Contribuição 1:  Dar nova redação à alínea “c” conforme segue:

    Forçar, na primeira utilização, a alteração da senha de acesso à configuração do equipamento.  Este requisito é opcional para equipamentos Gateways e/ou Roteadores do segmento residencial.  

    Contribuição 2: Incluir a alínea “i” conforme segue:

    Suportar o mecanismo AAA - Autenticação, Autorização e Accounting quando for usado servidor remoto de acesso com protocolo TACACS - Terminal Access Controller Access Control System (IETF - RFC 1492). Este requisito é opcional para equipamentos Gateways e/ou Roteadores do segmento residencial de uso doméstico.

    Justificativa:

    Contribuição 1

    A Telefônica Brasil S.A. acredita que no uso doméstico a alteração forçada de senha de administrator do dispositivo pode causar efeito indesejado, pois é natural os Usuários alterarem e não lembrarem a nova senha por eles criada (o acesso como administrador é esporádico nesse caso).  Em situações como essa, a solução recomendada é o reset físico para o reestabelecimento do usuário e senha de administrador de fábrica. Adotando-se esse procedimento, diversas configurações feitas pelo próprio Usuário, em especial aquelas realizadas com o auxílio do técnico da instalação, vão se perder gerando uma nova situação indesejada.  Seguramente as equipes de Atendimento, Operação e o próprio Usuário, serão severamente impactados caso esse requisito seja mantido para os Gateways e/ou Roteadores residenciais.

    Por fim, esta prestadora entende ainda que basta haver a senha exclusiva, sem derivação de informações do dispositivo, conforme alíneas a e b, para que seja garantido o mínimo de segurança e operacionalidade da instalação.

    Contribuição 2

    A Telefônica Brasil S.A. destaca que o mecanismo AAA permite o controle centralizado e ampla rastreabilidade relacionada ao acesso e às mudanças de configuração do equipamento.  Portanto, se configura como importante ferramenta para o suporte e controle da rede, em especial os elementos críticos. Para Gateways e/ou Roteadores do segmento residencial o item não se aplica, pois o acesso como administrador é de responsabilidade do Usuário.

     Item:  5.1.4.Quanto às interfaces/portas de comunicação:

    a) Estar desprovido de qualquer ferramenta de teste ou backdoor intencional utilizados nos processos de desenvolvimento do produto e desnecessários à sua operação usual.

    b) Estar desprovido de qualquer forma de comunicação intencional não documentada, incluindo aquelas para envio de informações de perfil de uso do equipamento para fabricantes ou para terceiros.

    c) Ser fornecidos com serviços de transmissão de dados (portas de comunicação) não essenciais desabilitados, reduzindo sua superfície de ataque.

    d) Facultar ao usuário a possibilidade de desabilitar funcionalidades, serviços e portas de comunicação não essenciais à operação ou ao gerenciamento do equipamento.

    Contribuição N°: 95
    ID da Contribuição: 92546
    Autor da Contribuição: Grace Kelly de Cassia Caporalli
    Data da Contribuição: 13/05/2020 13:26:46
    Contribuição:

    MANIFESTAÇÃO: Revisar subitem c) do 5.1.4.

    Ser fornecidos com serviços de transmissão de dados (portas de comunicação) não essenciais desabilitados documentados, reduzindo sua superfície de ataque.

    Justificativa:

    JUSTIFICATIVA: Entendemos que o termo “essenciais” nesse contexto é preocupante devido a sua subjetividade. Portanto, sugerimos o uso do termo “documentado” como um critério mais objetivo para cumprimento da obrigação regulatória.

    Contribuição N°: 96
    ID da Contribuição: 92584
    Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
    Data da Contribuição: 14/05/2020 17:10:39
    Contribuição:

    5.1.4.d - Esse requisito pode ser inadequado para dispositivos básicos de IoT de consumidor com interface de usuário limitada.

    Justificativa:

    A BSA acredita que os padrões de cibersegurança propostos na consulta podem ser mais eficazes se estiverem alinhados com os padrões reconhecidos internacionalmente. Esses padrões fornecem orientações específicas para desenvolvedores e fabricantes sobre como implementar certos requisitos. Os padrões de cibersegurança propostos devem ser atualizados com referências a padrões apropriados onde quer que existam. Além disso, alguns padrões não são universalmente aplicáveis & 8203;& 8203;ao amplo escopo de dispositivos cobertos pela consulta.

    Contribuição N°: 97
    ID da Contribuição: 92608
    Autor da Contribuição: Darles Leandro C. Gomes
    Data da Contribuição: 15/05/2020 16:50:45
    Contribuição:

    Tais itens devem passar sob a avaliação de um laboratório acreditado e não somente declaração.

    Justificativa:

    Por se tratar de segurança de dados de usuários e evitar acessos indevidos ao equipamento há necessidade de uma avaliação mais rigorosa do equipamento no aspecto de segurança cibernética

    Contribuição N°: 98
    ID da Contribuição: 92621
    Autor da Contribuição: JOAO LUIZ FREIRE DA COSTA BEZERRA
    Data da Contribuição: 15/05/2020 17:42:48
    Contribuição:

    Sugestão de alteração da letra c, conforme a seguir:

    De: Ser fornecidos com serviços de transmissão de dados (portas de comunicação) não essenciais desabilitados, reduzindo sua superfície de ataque.

    Para: Ser fornecidos com serviços de transmissão de dados (portas de comunicação) não essenciais desabilitados, sempre que possível, reduzindo sua superfície de ataque.

    Justificativa:

    Existem situações que a montagem dos circuitos ou configuração das placas não permitem o bloqueio da transmissão de dados. Neste caso o fornecedor deve informar, claramente, ao usuário quanto a essa impossibilidade.

    Contribuição N°: 99
    ID da Contribuição: 92649
    Autor da Contribuição: LUCIMARA DESIDERA
    Data da Contribuição: 15/05/2020 19:55:32
    Contribuição:

    O texto não deixa claro se está falando de interface física, portas de serviço TCP/UDP ou interface com usuário. Sugerimos esclarecer, em cada item, o contexto a que se aplica.

     

    Para os itens 5.1.4.a e 5.1.4.b sugerimos remover a palavra "intencional".

    Justificativa:

    Referente aos itens itens 5.1.4.a e 5.1.4.b Sugerimos que seja removida a palavra “intencional” deixando o requisito mais abrangente, especialmente para fomentar que os fornecedores adotem boas práticas de desenvolvimento seguro de código, a fim de evitar backdoors não intencionais decorrentes de erros de programação, o quais podem ser explorados por atacantes.

    Contribuição N°: 100
    ID da Contribuição: 92664
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:
    Justificativa:
    Contribuição N°: 101
    ID da Contribuição: 92701
    Autor da Contribuição: Paulo Cesar Valete
    Data da Contribuição: 17/05/2020 19:55:01
    Contribuição:

    Dar nova redação à alínea “b” conforme segue:

    Deve ser possível ao Usuário ativar/desativar qualquer forma de comunicação intencional, documentada ou não, incluindo aquelas para envio de informações de perfil de uso do equipamento para fabricantes ou para terceiros. 

    Justificativa:

    A Telefônica Brasil S.A. acredita que deve ser facultado ao usuário permitir ou não, por meio de configuração no dispositivo, o compartilhamento de informações sensíveis.  Tais informações podem ser valiosas para análise da vulnerabilidade e aplicação da solução de segurança. 

    Contribuição N°: 102
    ID da Contribuição: 92710
    Autor da Contribuição: Sergio Mauro da Silva Maia
    Data da Contribuição: 17/05/2020 20:53:29
    Contribuição:

    Item 5.1.4.c- Contribuição: Discordamos desta exigência conforme justificativa abaixo.

    item 5.1.4.d- Contribuição: Não aplicável para equipamentos de serviços de comunicação via satélite.

    Justificativa:

    Item 5.1.4.c - Justificativa:  As empresas podem usar essa exigência como diferencial em seus produtos na comercialização perante o usuário, ou vender o equipamento e  tornar  portas  de firmware abertas como um  objeto de venda. Em outros casos, os equipamentos podem ser enviados   para o  usuário com portas não essenciais habilitadas, a fim de facilitar a configuração  dos  instaladores  e  ativar serviço ,  diminuindo a necessidade de uma assistência extra do suporte técnico. Entendemos que uma vez configurado o equipamento, o usuário  pode optar  em desabilitar  as portas não essenciais.

    Item 5.1.4.d - Justificativa:  Para equipamentos satelite,  a configuração  vem de  fábrica e é muito específica. Permitir que o usuário a troque     pode  incorrer  no risco de interrupção do serviço e custos de envio de técnicos à  campo para manutenções devido ao indevido pelo usuário

     Item:  5.1.5.Quanto aos dados sensíveis e informações pessoais:

    a) Possibilitar a utilização de métodos adequados de criptografia para transmissão e armazenamento de dados sensíveis, incluindo informações pessoais.

    b) Permitir que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais.

    Contribuição N°: 103
    ID da Contribuição: 92547
    Autor da Contribuição: Grace Kelly de Cassia Caporalli
    Data da Contribuição: 13/05/2020 13:28:37
    Contribuição:

    MANIFESTAÇÃO: Exclusão do item 5.1.5

    Justificativa:

    JUSTIFICATIVA: A Lei Geral de Proteção de Dados (LGPD) já apresenta todos os balizadores referentes ao tratamento de dados pessoais, inclusive dos considerados sensíveis, e estabelece a Autoridade Nacional de Proteção de Dados como o órgão responsável pela aplicação da lei. Na medida em que os fabricantes de equipamentos já estão sujeitos a todas as regras estabelecidas na LGPD, sugerimos que esse item seja excluído do ato para evitar a duplicação de regras que potencialmente trariam insegurança jurídica.

     

     

    Contribuição N°: 104
    ID da Contribuição: 92575
    Autor da Contribuição: LUIZ GUSTAVO DE MORAIS
    Data da Contribuição: 14/05/2020 14:52:13
    Contribuição:

    5.1.5. Quanto aos dados sensíveis e informações pessoais:

      Todos os subitens.

      Definir “Dados Sensíveis e Informações Pessoais” na seção 3 de Definições, fornecendo uma lista das informações consideradas sensíveis e pessoais

     Excluir   b) Permitir que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais.

    Justificativa:

    Busca-se obter esclarecimento para este requisito e evitar interpretações incorretas durante futuros processos de homologação de produtos.

    Justificativa item b) Entende-se que as tratativas relacionadas a proteção de dados, assim como a deleção dos mesmos, devem estar sob o escopo da Lei Geral de Proteção de Dados 13.709/2018.

    Sendo assim, tendo em vista evitar requisitos conflitantes no futuro, sugere-se eliminar o item b da sessão 5.1.5 e permitir que tais aspectos sejam legislados pela Lei 13.709/2018.

    Contribuição N°: 105
    ID da Contribuição: 92585
    Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
    Data da Contribuição: 14/05/2020 17:11:34
    Contribuição:

    5.1.5.a - Esse requisito deve especificar que “métodos de criptografia apropriados” podem incluir o uso de nenhuma criptografia, caso o dispositivo não armazene ou processe informações confidenciais, incluindo credenciais.

    Justificativa:

    A BSA acredita que os padrões de cibersegurança propostos na consulta podem ser mais eficazes se estiverem alinhados com os padrões reconhecidos internacionalmente. Esses padrões fornecem orientações específicas para desenvolvedores e fabricantes sobre como implementar certos requisitos. Os padrões de cibersegurança propostos devem ser atualizados com referências a padrões apropriados onde quer que existam. Além disso, alguns padrões não são universalmente aplicáveis & 8203;& 8203;ao amplo escopo de dispositivos cobertos pela consulta

    Contribuição N°: 106
    ID da Contribuição: 92599
    Autor da Contribuição: Mateus de Faria Pereira
    Data da Contribuição: 15/05/2020 15:28:56
    Contribuição:

    c) O fornecedor deve informar ao usuário quais tipos de dados sensíveis o equipamento armazena ou utiliza.

    Justificativa:

    Boas práticas de Gerenciamento de dados sensiveis

    Contribuição N°: 107
    ID da Contribuição: 92607
    Autor da Contribuição: Darles Leandro C. Gomes
    Data da Contribuição: 15/05/2020 16:48:55
    Contribuição:

    Tais itens devem passar sob a avaliação de um laboratório acreditado e não somente declaração.

    Justificativa:

    Por se tratar de segurança de dados de usuários e evitar acessos indevidos ao equipamento há necessidade de uma avaliação mais rigorosa do equipamento no aspecto de segurança cibernética

    Contribuição N°: 108
    ID da Contribuição: 92616
    Autor da Contribuição: Gilberto Martins de Almeida Filho
    Data da Contribuição: 15/05/2020 17:14:53
    Contribuição:

    Excluir o item 5.1.5 e seus subitens.

    "5.1.5. Quanto aos dados sensíveis e informações pessoais:

    a) Possibilitar a utilização de métodos adequados de criptografia para transmissão e armazenamento de dados sensíveis, incluindo informações pessoais.

    b) Permitir que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais."

    Justificativa:

    Anfavea propõe a retirada do item 5.1.5, pois a LGPD (Lei nº 13.709/2018, Art. 46.) já é responsável pela proteção dos dados sensíveis e das informações pessoais do usuário.

    Contribuição N°: 109
    ID da Contribuição: 92637
    Autor da Contribuição: Mariana Giostri M. Oliveira
    Data da Contribuição: 15/05/2020 19:11:41
    Contribuição:

    Quanto aos dados sensíveis e informações pessoais:

    a)         Possibilitar a utilização de métodos adequados de criptografia para transmissão e armazenamento de dados sensíveis, incluindo informações pessoais.

    b)        Permitir que os usuários deletem facilmente seus dados pessoais armazenados, possibilitando o descarte ou a substituição do equipamento sem riscos de exposição de informações pessoais.

    Justificativa:

    A Lei Geral de Proteção de Dados (LGPD), aprovada em agosto de 2018, já traz todos os balizadores referentes ao tratamento de dados pessoais, inclusive dos considerados sensíveis, e estabelece a Autoridade Nacional de Proteção de Dados como o órgão responsável pela aplicação da lei. Na medida em que os fabricantes de equipamentos já estão sujeitos a todas as regras estabelecidas na LGPD, sugerimos que esse item seja excluído do ato para evitar a duplicação de regras que potencialmente trariam insegurança jurídica a todos os players da cadeia.

    Contribuição N°: 110
    ID da Contribuição: 92665
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:
    Justificativa:
    Contribuição N°: 111
    ID da Contribuição: 92687
    Autor da Contribuição: Karla Menandro Pacheco da Silva
    Data da Contribuição: 17/05/2020 10:47:34
    Contribuição:

    Excluir o item 5.1.5 

    Justificativa:

    A Lei geral de proteção de dados (Lei nº 13.709/2018, Art. 46.) já é responsável pela proteção dos dados sensíveis e das informações pessoais do usuário. 

    Contribuição N°: 112
    ID da Contribuição: 92711
    Autor da Contribuição: Sergio Mauro da Silva Maia
    Data da Contribuição: 17/05/2020 20:56:19
    Contribuição:

    Item 5.1.5.b - Contribuição: Não aplicável para equipamentos de usuário em serviços de comunicação via satélite.

    Justificativa:

    Item 5.1.5.b - Justificativa: Todos os dados pessoais do usuário são tratados em base de dados gerenciada pela centro de controle da prestadora e não ficam armazenados no terminal.

     Item:  5.1.6.Quanto à capacidade de mitigar ataques:

    a) Possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos ou sistemas (ataque de negação de serviço).

    b) Ser projetados para mitigar os efeitos de ataques de negação de serviço em andamento, sendo resistentes a um número excessivo de tentativas de autenticação, por meio de, por exemplo: priorização de sua capacidade de processamento às sessões de comunicação já estabelecidas e autenticadas; e limitação do número de sessões de autenticação concorrentes, descartando tentativas de estabelecimento de novas sessões quando superado limite estabelecido.

    Contribuição N°: 113
    ID da Contribuição: 92548
    Autor da Contribuição: Grace Kelly de Cassia Caporalli
    Data da Contribuição: 13/05/2020 13:30:34
    Contribuição:

    MANIFESTAÇÃO: Esse dispositivo reforça o nosso posicionamento de que os requisitos mínimos previstos nesse ato devem ser aplicáveis exclusivamente a equipamentos de infraestrutura de redes de telecomunicações.

    Justificativa:

    JUSTIFICATIVA: Isso porque, tecnicamente falando, esses requisitos são apenas viavelmente aplicáveis para monitorar a camada de infraestrutura das redes de telecomunicações, enquanto que se configura como infactível implementá-las na ponta. Nesse último caso, existem aplicações disponibilizadas por criadores de conteúdo que podem suprir essa necessidade.

    Alguns produtos não são desenvolvidos para conter este tipo de mecanismo de segurança para não comprometer seu desempenho em sua função principal ou seu projeto em relação aos custos envolvidos. Por exemplo, em uma rede corporativa de grande porte há elementos isolados dedicados especificamente à segurança das redes. Desta forma, em muitos casos os requisitos de segurança devem ser avaliados em nível de sistema.

    Contribuição N°: 114
    ID da Contribuição: 92576
    Autor da Contribuição: LUIZ GUSTAVO DE MORAIS
    Data da Contribuição: 14/05/2020 14:49:52
    Contribuição:

    a) Possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos ou sistemas (ataque de negação de serviço). Alternativamente, possuir mecanismo no provedor de telecomunicações (ou backoffice) para desativar a conexão de equipamentos específicos a fim de minimizar seu uso como vetor em ataques a outros equipamentos ou sistemas.

    Justificativa:

    A capacidade dos dispositivos de detectar estarem sob ataques é um tipo de proteção de Segurança Cibernética bastante novo, cuja tecnologia não está amplamente disponível no mercado e pode agregar custo considerável nos produtos (software / hardware). Por outro lado, atuar no backoffice ou no provedor de telecomunicações é uma forma mais comum no mercado, oferece o mesmo grau de proteção, quando disponível, e é efetivamente usado para mitigar ataques do tipo denial of service.

    Contribuição N°: 115
    ID da Contribuição: 92600
    Autor da Contribuição: Mateus de Faria Pereira
    Data da Contribuição: 15/05/2020 15:48:39
    Contribuição:

    c) Mitigar Replay Attacks e Man in the middle attacks (MITM)

    d) Protocolos de Comunicação não devem sofrer downgrade

    Justificativa:

    c) Padrões de ataques cibernéticos conhecidos e que devem ser evitados. ENISA - European Union Agency For Network and Information Security Good Practices for Security of Internet of Things.

    d) Durante um ataque o equipamento deve reagir de forma a utilizar o máximo de segurança possível.

    Contribuição N°: 116
    ID da Contribuição: 92617
    Autor da Contribuição: Gilberto Martins de Almeida Filho
    Data da Contribuição: 15/05/2020 17:14:53
    Contribuição:

    Alterar o letra a) do item 5.1.6

    "5.1.6. Quanto à capacidade de mitigar ataques:

     a) Possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos ou sistemas (ataque de negação de serviço). Alternativamente, possuir mecanismo no provedor de telecomunicações (ou backoffice) para desativar a conexão de equipamentos específicos a fim de minimizar seu uso como vetor em ataques a outros equipamentos ou sistemas."

    Justificativa:

    A capacidade dos dispositivos de detectar estarem sob ataques é um tipo de proteção de Segurança Cibernética bastante novo, cuja tecnologia não está amplamente disponível no mercado e pode agregar custo considerável nos produtos (software/hardware). Por outro lado, atuar no backoffice ou no provedor de telecomunicações é uma forma mais comum no mercado, oferece o mesmo grau de proteção, quando disponível, e é efetivamente usado para mitigar ataques do tipo denial of service.

    Contribuição N°: 117
    ID da Contribuição: 92622
    Autor da Contribuição: JOAO LUIZ FREIRE DA COSTA BEZERRA
    Data da Contribuição: 15/05/2020 17:45:42
    Contribuição:

    Existe uma dificuldade técnica em determinar o "usualmente necessário" quando isso se refere a taxa de transmissão de dados de saída, devido a diversidade de sistemas e funcionalidades existentes.  Uma alternativa seria obrigar o fabricante a informar a sua taxa máxima de transmissão (upload), a partir da qual o sistema bloquearia os dados excedentes.

    Justificativa:

    Existe uma dificuldade técnica em determinar o "usualmente necessário" quando isso se refere a taxa de transmissão de dados de saída, devido a diversidade de sistemas e funcionalidades existentes.

    Contribuição N°: 118
    ID da Contribuição: 92650
    Autor da Contribuição: LUCIMARA DESIDERA
    Data da Contribuição: 15/05/2020 19:56:47
    Contribuição:

    Almejando aperfeiçoar a capacidade de mitigação de ataques de negação de serviço e também a promoção de boas práticas de higiene e a resiliência das redes, gostaríamos de sugerir que a implementação de filtro antispoofing de acordo com a BCP 84 (https://tools.ietf.org/html/bcp84), para ambos os protocolos, IPv4 e IPv6, seja um requisito de segurança mínimo para dispositivos terminais que se conectam à Internet e para equipamentos de infraestrutura de redes.

    Justificativa:

    Uma das maneiras mais efetivas de se mitigar ataques de negação de serviço consiste em eliminar o tráfego malicioso em sua origem, ou mais próximo possível dela. Limitar a capacidade de transmissão (banda) do dispositivo, especialmente os que têm perfil de uso de dados bem definido, pode ajudar a diminuir o volume de dados transmitidos. Todavia, para ataques baseados em reflexão com amplificação, e dependendo da função/papel do dispositivo, tal medida pode ter eficácia limitada e causar impacto em tráfego legítimo. Ataques que envolvem reflexão e amplificação são particularmente nocivos, pois mesmo requisições pequenas geradas por um dispositivo infectado (bot), podem refletir em respostas muito maiores (amplificadas) ao atingirem o destino (vítima). Nos ataques com reflexão e amplificação, as requisições primárias se caracterizam por terem o endereço IP de origem adulterado (IP spoofing) e, para mitigação destes casos, o ideal é evitar que tal tráfego com endereço IP de origem adulterado seja transmitido pela rede (https://www.internetsociety.org/wp-content/uploads/2017/08/ISOC-AntiSpoofing-20150909-en-2.pdf). O local mais adequado para efetuar esta mitigação é justamente nos dispositivos CPEs aonde uRPF não apresenta efeitos operacionais indesejados. Medidas de filtragem antispoofing ajudam não apenas a mitigar ataques de negação de serviço, como contribuem também para melhorar a resiliência da rede do prestador de serviço. Para propiciar tal mitigação, os dispositivos devem implementar o suporte a filtragem antispoofing.

    Contribuição N°: 119
    ID da Contribuição: 92666
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:
    Justificativa:
    Contribuição N°: 120
    ID da Contribuição: 92688
    Autor da Contribuição: Karla Menandro Pacheco da Silva
    Data da Contribuição: 17/05/2020 10:48:49
    Contribuição:

    Caso não seja possível excluir os componentes automotivos do escopo da resolução, sugerimos:

    Alterar o letra a) do item 5.1.6

     a) Possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos ou sistemas (ataque de negação de serviço). Alternativamente, possuir mecanismo no provedor de telecomunicações (ou backoffice) para desativar a conexão de equipamentos específicos a fim de minimizar seu uso como vetor em ataques a outros equipamentos ou sistemas. 

    Justificativa:

    A capacidade dos dispositivos de detectar estarem sob ataques é um tipo de proteção de Segurança Cibernética bastante novo, cuja tecnologia não está amplamente disponível no mercado e pode agregar custo considerável nos produtos (software/hardware). Por outro lado, atuar no backoffice ou no provedor de telecomunicações é uma forma mais comum no mercado, oferece o mesmo grau de proteção, quando disponível, e é efetivamente usado para mitigar ataques do tipo denial of service. 

    Contribuição N°: 121
    ID da Contribuição: 92702
    Autor da Contribuição: Paulo Cesar Valete
    Data da Contribuição: 17/05/2020 19:56:24
    Contribuição:

    Dar nova redação à alínea “a” conforme segue:

    Possuir mecanismo para limitação da taxa de transmissão de dados de saída (upload), além do usualmente necessário, a fim de minimizar sua utilização como vetores em ataques a outros equipamentos ou sistemas (ataque de negação de serviço). Este requisito é opcional para equipamentos Gateways e/ou Roteadores do segmento residencial de uso doméstico.

    Justificativa:

    A Telefônica Brasil S.A. destaca que para Gateways e/ou Roteadores do segmento residencial, o emprego de tal mecanismo dependerá das características do acesso, e.g. tipo de infraestrutura dedicada, de forma que em determinadas situações pode não se justificar a aplicação.

     Item:  6. REQUISITOS PARA FORNECEDORES DE EQUIPAMENTOS PARA TELECOMUNICAÇÕES

    6.1.Os fornecedores de equipamentos terminais que se conectam à Internet e de equipamentos de infraestrutura de redes de telecomunicações, devem:

    6.1.1.Ter uma política clara de suporte ao produto, especialmente em relação à disponibilização de atualizações de software/firmware para correção de vulnerabilidades de segurança.

    6.1.2.Deixar claro para o consumidor até quando serão providas atualizações de segurança para o equipamento e com que frequência ocorrerão.

    6.1.3.Garantir que os processos de atualização automática de software/firmware sejam realizadas em fases a fim de evitar que erros não intencionais da nova versão de software/firmware sejam distribuídos a todos os equipamentos sob atualização de uma só vez.

    6.1.4.Prover atualizações de segurança por, no mínimo, 2 (dois) anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

    6.1.5.Disponibilizar um canal de comunicação que possibilite aos seus clientes, usuários finais e terceiros reportarem vulnerabilidades de segurança identificadas nos produtos.

    6.1.6.Disponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa, para:

    a) Informar sobre novas vulnerabilidades identificadas em seus produtos, medidas de mitigação e correções de segurança associadas;

    b) Manter histórico de: vulnerabilidades identificadas, medidas de mitigação e correções de segurança;

    c) Permitir acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos; e

    d) Fornecer manuais e outros materiais com orientações relativas à configuração, atualização e uso seguro dos equipamentos.

    Contribuição N°: 122
    ID da Contribuição: 90930
    Autor da Contribuição: WILLYAN HASENKAMP CARREIRA
    Data da Contribuição: 26/03/2020 12:16:53
    Contribuição:

    6.1.Os fornecedores de equipamentos terminais que se conectam à Internet e de equipamentos de infraestrutura de redes de telecomunicações, devem:

    6.1.1.Ter uma política clara de suporte ao produto, especialmente em relação à disponibilização de atualizações de software/firmware para correção de vulnerabilidades de segurança.

    6.1.2.Deixar claro para o consumidor até quando serão providas atualizações de segurança para o equipamento e com que frequência ocorrerão.

    6.1.3.Garantir que os processos de atualização automática de software/firmware sejam realizadas em fases a fim de evitar que erros não intencionais da nova versão de software/firmware sejam distribuídos a todos os equipamentos sob atualização de uma só vez.

    6.1.4.Prover atualizações de segurança por, no mínimo, 2 (dois) anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

    6.1.5.Disponibilizar um canal de comunicação que possibilite aos seus clientes, usuários finais e terceiros reportarem vulnerabilidades de segurança identificadas nos produtos.

    6.1.6.Disponibilizar um canal público de suporte, por meio de página na internet ou EMAIL em língua portuguesa ou em INGLES, para:

    a) Informar sobre novas vulnerabilidades identificadas em seus produtos, medidas de mitigação e correções de segurança associadas;

    b) Manter histórico de: vulnerabilidades identificadas, medidas de mitigação e correções de segurança;

    c) Permitir acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos; e

    d) Fornecer manuais e outros materiais com orientações relativas à configuração, atualização e uso seguro dos equipamentos.

    Justificativa:

    6.1.1. Justificativa

    Não cabe a uma agência certificadora se envolver em questões que apenas dizem respeito aos produtos. Quem desenvolve o produto precisa demandar por isso quando necessário e não depender de uma certificação. Principalmente porque imposição de requisitos podem matar várias aplicações de IoT.

    6.1.2. Justificativa

    Novamente não cabe a uma agência certificadora dizer ou impor regras de como as empresas devem se relacionar com seus consumidores. De qualquer forma os consumidores precisam ser educados a buscar soluções que atendam as necessidades deles.

    6.1.3. Justificativa

    Novamente não cabe a uma agência certificadora dizer como os processos devem ser executados ficando a cargo de cada um implementar soluções que lhes for mais favoráveis.

    6.1.4. Justificativa

    A busca por segurança deve partir do consumidor, que precisa ser educado. E não regulado por uma agência.

    6.1.5. Justificativa

    Totalmente pertinente.

    6.1.6. Justificativa

    Deve ficar a cargo do cliente investigar as soluções que lhe parecer atender melhor os requisitos. Email é uma ferramenta bastante utilizada e operamos num mundo globalizado onde o Inglês tem sido a lingua comum. 

    Os demais subitens não devem ficar a cargo de uma agencia certificadora esse papel, pois o cliente deve buscar por isso no momento da compra.

    DEMAIS CONSIDERAÇÕES

    Deve-se educar os clientes não criar barreiras e processos certificadores que geram custos e impactam o preço final do produto. Alguns mercados são muito novos e precisam ser desregulados para que soluções disputem o mercado e vençam aquelas que melhor atenderem seus clientes. Novamente, precisamos EDUCAR e não burocratizar.

    Contribuição N°: 123
    ID da Contribuição: 92549
    Autor da Contribuição: Grace Kelly de Cassia Caporalli
    Data da Contribuição: 13/05/2020 13:34:56
    Contribuição:

    MANIFESTAÇÃO 1 - item 6.1.2:   EXCLUIR item 6.1.2.

    MANIFESTAÇÃO 2 - Item 6.1.4 :  EXCLUIR item 6.1.4.

    Justificativa:

    JUSTIFICATIVA 1 - item 6.1.2:  O item 6.1.2. trata dos prazos sobre atualizações de segurança. Em relação a periodicidade, esta pode variar dependendo de cada produto ou vulnerabilidade encontradas, bem como o risco envolvido, portanto acreditamos que estabelecer uma periodicidade, (a qual pode variar de mensal, trimestral ou em menor periodicidade dependendo do produto ou real necessidade de atualização) poderá ter efeitos contrários ao pretendido, engessando a possibilidade de que atualizações sejam feitas fora da regularidade informada.

    JUSTIFICATIVA 2 - item 6.1.4 : há extrema variação entre categorias distintas de equipamentos quanto à sua vida útil e necessidade de atualização. Seria mais razoável se solicitar ao fabricante que informe a periodicidade de atualizações e prazo de atualizações após descontinuidade da oferta do produto no mercado.

    Contribuição N°: 124
    ID da Contribuição: 92569
    Autor da Contribuição: Fernando Capez
    Data da Contribuição: 14/05/2020 12:18:59
    Contribuição:

    6.1.4.Prover atualizações de segurança por, no mínimo, 5 (cinco) anos após a descontinuidade de distribuição do produto no mercado consumidor, tendo ainda por base a vida útil de cada equipamento.

    Justificativa:

    No que tange a proteção do consumidor, não é admissível que em tão pouco tempo haja a descontinuidade de suporte para novas atualizações de segurança, o que colocaria o produto vulnerável a falhas de segurança por falta de atualização ou correção.

    Salienta-se que os equipamentos de telecomunicações são bens duráveis, ou seja, a sua permanência em uso pode-se perpetrar por grande lapso temporal. Portanto, entendemos que à oferta de atualizações de segurança devem ser feitas durante o período em que o bem é comercializado no mercado do consumo, bem como mantido por, no mínimo 5 (cinco anos), após cessada a sua distribuição. E mais, deve-se levar em consideração que este prazo pode ser ampliado, de acordo com o caso concreto, tendo em vista a variação da vida útil de cada equipamento, possibilitando ao consumidor o resguardo do seu direito no caso de posse de produto descontinuado, ainda em funcionamento, porém, vulnerável à ataque cibernético.

    Contribuição N°: 125
    ID da Contribuição: 92572
    Autor da Contribuição: LUIZ GUSTAVO DE MORAIS
    Data da Contribuição: 14/05/2020 14:45:28
    Contribuição:

    6.1.2. Deixar claro para o consumidor até quando serão providas atualizações de segurança para o equipamento e, quando aplicável, com que frequência ocorrerão.

    6.1.4. Prover atualizações de segurança, quando aplicável, por, no mínimo, 2 (dois) anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.  Favor esclarecer se este requisito foca em definir um período mínimo de cobertura após o lançamento do produto ou define que uma atualização de segurança é requerida antes de no mínimo 2 anos após o produto estiver em serviço. Sugere-se adicionar o trecho “quando aplicável” no requisito para evidenciar a intenção.

    6.1.6. Disponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa, para:

      c) Quando aplicável, Permitir acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos; e

    Justificativa:

    Justificativa item 6.1.2: Permitir que fornecedores de equipamentos forneçam atualizações de segurança sem um cronograma predeterminado, em vez disso, que disponibilizem as atualizações para os usuários finais assim que as vulnerabilidades forem resolvidas e estiverem prontas para serem instaladas.

    O texto regulatório especifica permitir que os clientes verifiquem se uma atualização de segurança está disponível (seção 5.1.1 item b), assim como exige que os fornecedores de equipamentos informem sobre novas vulnerabilidades identificadas, medidas de mitigação e as associadas atualizações de segurança (seção 6.1.6).

    Justificativa item 6.1.4: Busca-se obter esclarecimento para este requisito e evitar interpretações incorretas durante futuros processos de homologação de produtos

    Justificativa item 6.1.6:Todas as atualizações de segurança de software/firmware para equipamentos relacionados a telecomunicações em veículos são instalados automaticamente via ar. O usuário final não precisa ter acesso aos mesmos (arquivos), pois o manuseio do arquivo e instalação no produto é feito de maneira segura e protegida pela montadora.

     

     

    Contribuição N°: 126
    ID da Contribuição: 92586
    Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
    Data da Contribuição: 14/05/2020 17:13:25
    Contribuição:

    6.1.3 - Este requisito é excessivamente prescritivo. Os fornecedores devem ter o poder de implantar atualizações de produtos da maneira que eles determinarem ser mais segura e eficaz.

    6.1.5, 6.1.6 - 

    A BSA congratula a Anatel por incentivar os fornecedores a manter programas coordenados de divulgação de vulnerabilidades. A implementação bem-sucedida desses programas requer uma consideração cuidadosa dos direitos, obrigações e expectativas de todas as partes interessadas envolvidas. Portanto, a BSA incentiva fortemente a Anatel a modificar esse requisito para se referir aos principais padrões reconhecidos internacionalmente, fornecendo orientação sobre divulgação coordenada de vulnerabilidades, como ISO / IEC 29147 e ISO / IEC 3011.

    Especialmente a consulta deve:

    • Permitir o lançamento de avisos de segurança e materiais relacionados em inglês, dada a natureza global do ecossistema de CDV.

    • Considere a exclusão da proposta na seção 6.1.4 (requisito obrigatório para fornecer dois anos de atualização de segurança enquanto o equipamento estiver sendo distribuído ao mercado consumidor) é globalmente sem precedentes, pode ser tecnicamente inviável e pode limitar a disponibilidade de produtos no mercado brasileiro.

    Os requisitos de suporte ao produto (6.1.2, 6.1.4) pressupõem que um fabricante possa saber quanto tempo pretende oferecer suporte a um dispositivo quando estiver se comunicando com um consumidor. Essa presunção ignora as variabilidades que um fabricante não pode controlar ao fabricar e vender o dispositivo.

    Além disso, a intenção da seção 6.1.4 pode ser tecnicamente inviável, impor custos desproporcionais ao mercado brasileiro e afirmar requisitos em termos de negócios (efetivamente uma garantia). Esse assunto geralmente é regulamentado no mercado sob as limitações atuais da garantia, tomada de decisão contratual e do consumidor e não é apropriado para regulamentação. Como tal, o termo proposto é globalmente sem precedentes, mesmo na regulamentação que impõe requisitos mínimos/razoáveis & 8203;& 8203;de segurança.

    Em vez disso, a consulta pode considerar que o fabricante seria obrigado a fornecer ao usuário um aviso sobre a expiração das atualizações de segurança do produto e sua descontinuidade enquanto o equipamento está sendo distribuído ao mercado consumidor.

    Justificativa:

    A BSA acredita que os padrões de cibersegurança propostos na consulta podem ser mais eficazes se estiverem alinhados com os padrões reconhecidos internacionalmente. Esses padrões fornecem orientações específicas para desenvolvedores e fabricantes sobre como implementar certos requisitos. Os padrões de cibersegurança propostos devem ser atualizados com referências a padrões apropriados onde quer que existam. Além disso, alguns padrões não são universalmente aplicáveis & 8203;& 8203;ao amplo escopo de dispositivos cobertos pela consulta.

    Contribuição N°: 127
    ID da Contribuição: 92593
    Autor da Contribuição: Wilson Cardoso
    Data da Contribuição: 14/05/2020 18:34:41
    Contribuição:

    Pedimos retirar a referencia a equipamentos terminais. Consideramos que os prazos, periodiciade assim com metodos de distrinuição devem ser definidos em contratos

    Justificativa:

    O uso de instrumentos contratuais define o entorno de cada equipamento, software ou solução. 

    Contribuição N°: 128
    ID da Contribuição: 92618
    Autor da Contribuição: Gilberto Martins de Almeida Filho
    Data da Contribuição: 15/05/2020 17:14:53
    Contribuição:

    Excluir o item 6.1.2, alterar os itens 6.1.3, 6.1.4 e a letra c) do item 6.1.6

    "6. REQUISITOS PARA FORNECEDORES DE EQUIPAMENTOS PARA TELECOMUNICAÇÕES
    [..]
    6.1.2.Deixar claro para o consumidor até quando serão providas atualizações de segurança para o equipamento e com que frequência ocorrerão.

    6.1.3. Para equipamentos de infraestrutura, garantir que os processos de atualização automática de software/firmware sejam realizadas em fases a fim de evitar que erros não intencionais da nova versão de software/firmware sejam distribuídos a todos os equipamentos sob atualização de uma só vez. 

    6.1.4. Prover atualizações de segurança, quando necessário, por, no mínimo, 2 (dois) anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

    [...]

    6.1.6. Disponibilizar um canal público de suporte, por meio de página na internet em língua portuguesa, para:

    [...]

      c) Quando aplicável, Permitir acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos; e"

    Justificativa:

    6.1.2: Anfavea entende que o texto está redundante, visto que o processo de homologação já requer suporte do produto ao longo da sua comercialização, conforme item 6.1.4.

    6.1.3: Para requisitos de fornecimento de equipamentos, os equipamentos de infraestrutura e os equipamentos terminais devem ter tratados distintamente, dado a diferença de criticidade de ambos.

    6.1.4: Anfavea entende que um componente não terá uma atualização obriogatória de segurança nesses 2 anos quando não houver vulnerabilidades.

    Letra c) do item 6.1.6: Grande parte das atualizações de segurança de software/firmware para equipamentos relacionados a telecomunicações em veículos são instalados automaticamente via ar. O usuário final não precisa ter acesso aos mesmos (arquivos), pois o manuseio do arquivo e instalação no produto é feito de maneira segura e protegida pela montadora. Além disso, a disponibilização de software/firmware é um dos meios de controle de segurança da montadora.

    Contribuição N°: 129
    ID da Contribuição: 92638
    Autor da Contribuição: Mariana Giostri M. Oliveira
    Data da Contribuição: 15/05/2020 19:12:28
    Contribuição:

    6.1.4. Prover atualizações de segurança por, no mínimo, 2 (dois) anos após o lançamento do produto ou e enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

    Justificativa:

    Na medida em que há uma extrema variação entre as diversas categorias distintas de equipamento quanto à sua vida útil e necessidade de atualização, a Brasscom sugere que a Anatel proporcione aos fabricantes a flexibilidade de definir a periodicidade e prazo de atualizações de seus equipamentos, inclusive após a descontinuidade da oferta do produto no mercado.

    Contribuição N°: 130
    ID da Contribuição: 92651
    Autor da Contribuição: LUCIMARA DESIDERA
    Data da Contribuição: 15/05/2020 19:58:30
    Contribuição:

    Sugerimos mover o 6.1.3 para 5.1.1 pois refere-se a procedimentos de atualização de software/firmware.

     

    Sugerimos nova redação para o item 6.1.5:

    6.1.5. Definir políticas de Coordinated Vulnerability Disclosure (CVD) e disponibilizar um canal de comunicação que possibilite aos seus clientes, usuários finais e terceiros reportarem vulnerabilidades de segurança identificadas nos produtos.

    Justificativa:

    Em complemento ao explanado na justificativa das contribuições ao item 4, cabe ressaltar que os softwares de que trata esta Consulta, em sua maioria, são a combinação de múltiplos componentes de diversas organizações distintas, sendo bastante comum que bibliotecas de software, tanto de código aberto como proprietário, sejam licenciadas para composição da solução. Quando uma vulnerabilidade é descoberta em alguma biblioteca, isso impacta vários fornecedores da cadeia em que a biblioteca é utilizada, e em geral, a correção do problema implica na ação de múltiplos atores da cadeia para se chegar à correção dos produtos finais. Em cadeias de suprimentos complexas, invariavelmente haverá confusão sobre quem é responsável por coordenar, comunicar e finalmente corrigir as vulnerabilidades. Isso comumente gera atrasos e deixa os sistemas expostos a riscos. Possuir uma política de Coordinated Vulnerability Disclosure (CVD) é um passo para que o fabricante possa mapear os softwares externos que utiliza, bem como os terceiros que utilizam o seu software, de forma a definir uma política de comunicação e atualização que implique na atualização de todos os produtos que utilizam determinado software.

     

     

    Contribuição N°: 131
    ID da Contribuição: 92660
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:

     

    6.1.7 Garantir que a versão Beta ou versão não final do software/firmware deixe de funcionar após o lançamento da versão oficial.

      

    Justificativa:

     

    (Acréscimo de novo item. Justificativa: impedir que versões ultrapassadas estejam em uso)

      

    Contribuição N°: 132
    ID da Contribuição: 92674
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:20:08
    Contribuição:

     

    6.1.7 Garantir que a versão Beta ou versão não final do software/firmware deixe de funcionar após o lançamento da versão oficial.

      

    Justificativa:

     

    (Acréscimo de novo item. Justificativa: impedir que versões ultrapassadas estejam em uso)

      

    Contribuição N°: 133
    ID da Contribuição: 92680
    Autor da Contribuição: EMILIO CARLOS REBOUCAS SANTANA LOURES
    Data da Contribuição: 16/05/2020 19:57:35
    Contribuição:

    A norma deveria propor e fornecer incentivos para os fabricantes de Equipamentos cobertos adotarem processos coordenados de divulgação e manipulação de vulnerabilidades, de acordo com as melhores práticas do setor e com os padrões internacionais (ISO / IEC 29147, 30111).

    Considerar a exclusão da proposta na seção 6.1.4 (requisito obrigatório para fornecer dois anos de atualização de segurança enquanto o equipamento estiver sendo distribuído ao mercado consumidor) que possa limitar a disponibilidade de produtos no mercado brasileiro.

    Em vez disso, os requisitos poderiam propor que o fabricante fosse orientado a fornecer um aviso geral ao usuário (no curso dos negócios) sobre a expiração das atualizações de segurança do produto e sua descontinuidade, enquanto o equipamento estiver sendo distribuído ao mercado consumidor.

    Justificativa:

    Vários requisitos sob a seção 6 e especificamente as seções 6.1.2 e 6.1.4 e os requisitos para beneficiar vários “canais de apoio público” relacionadas com atenuações em Português ( 6.1.6 ) são globalmente sem precedentes e podem impor requisitos desproporcionalmente onerosos ao mercado brasileiro.

    Os requisitos de suporte ao produto (6.1.2, 6.1.4) pressupõem que um fabricante saiba quanto tempo pretende oferecer suporte a um dispositivo quando estiver se comunicando com um consumidor. Essa presunção ignora as variabilidades que um fabricante não pode controlar ao fabricar e vender o dispositivo e ignora as variabilidades que um fabricante não pode controlar ao fabricar e vender o dispositivo.

    Além disso, a intenção da seção 6.1.4 pode ser tecnicamente inviável, impor custos desproporcionais ao mercado brasileiro e afirmar requisitos em termos de negócios (efetivamente uma garantia). Esse assunto geralmente é regulamentado no mercado sob as limitações atuais da garantia, tomada de decisão contratual e do consumidor e não é apropriado para regulamentação / norma proposta. Como tal, o termo proposto é globalmente sem precedentes no contexto das exigências da regulamentação sobre requisitos mínimos / razoáveis de segurança.

    Contribuição N°: 134
    ID da Contribuição: 92689
    Autor da Contribuição: Karla Menandro Pacheco da Silva
    Data da Contribuição: 17/05/2020 10:51:51
    Contribuição:

    Caso não seja possível excluir os componentes automotivos do escopo da certificação, sugerimos:

    Excluir o item 6.1.2    

    Alterar o item 6.1.4

    6.1.4. Prover atualizações de segurança, quando necessário, por, no mínimo, 2 (dois) anos após o lançamento do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

    Alterar a letra c) do item 6.1.6

      c) Quando aplicável, Permitir acesso a correções de segurança e/ou novas versões de software/firmware para seus produtos; e

     

    Justificativa:

       6.1.2 - Entendemos que o texto está redundante, visto que o processo de homologação já requer suporte do produto ao longo da sua comercialização, conforme item 6.1.4.

    6.1.4 - Entendemos que um componente não terá uma atualização obriogatória de segurança nesses 2 anos quando não houver vulnerabilidades.

    6.1.6 - Grande parte das atualizações de segurança de software/firmware para equipamentos relacionados a telecomunicações em veículos são instalados automaticamente via ar. O usuário final não precisa ter acesso aos mesmos (arquivos), pois o manuseio do arquivo e instalação no produto é feito de maneira segura e protegida pela montadora. Além disso, a disponibilização de software/firmware é um dos meios de controle de segurança da montadora.

     

    Contribuição N°: 135
    ID da Contribuição: 92691
    Autor da Contribuição: WILLIAM GARCIA PIRES
    Data da Contribuição: 17/05/2020 16:26:00
    Contribuição:

    Referente ao termo "fornecedores de equipamentos terminais" ou de telecom, deveria conter uma definição no item 3 (Definição), definindo quem são os fornecedores de equipamentos.

    Justificativa:

    Uma vez existindo a definição, seja o fabricante ou uma empresa que disponibiliza o equipamento como comodato, deixaria mais claro a quem se refere à responsabilidade neste item do ATO.
    Exemplo de definição: "Fornecedor de equipamento de telecomunicão: fabricante de hardware e ou software do produto."

    Contribuição N°: 136
    ID da Contribuição: 92696
    Autor da Contribuição: Tiago Brocardo Machado
    Data da Contribuição: 17/05/2020 17:42:04
    Contribuição:

    A Ericsson propõe a alteração do item 6.1.4. para a seguinte redação:

    “6.1.4.Prover atualizações de segurança por um período compatível com a segmentação do equipamento destinado ao mercado de telecomunicações  que seja consenso da indústria e que siga padrões globais de segurança cibernética”

    Além de excluir os itens 6.1.5 e 6.1.6 dos equipamentos destinados a infraestrutura de rede.

    Justificativa:

    A Ericsson entende que o setor de Telecomunicações produz tecnologias inovadoras que estão crescendo e evoluindo continuamente. Neste contexto deve-se fomentar um ambiente que tenha flexibilidade e adaptabilidade par permitir ao mesmo tempo a disrupção tecnológica e a maturidade de soluções de cibersegurança que sigam os padrões globais. Portanto, ao considerar um conjunto mínimo de requisitos para a rede de telecomunicações, a Ericsson recomenda à ANATEL que esteja atenta à necessidade de uma regulamentação baseada em princípios, flexível o suficiente para manter-se atualizada com os recentes ciclos de desenvolvimento e inovação da tecnologia. Também compartilharíamos algumas preocupações em estabelecer requisitos específicos de segurança cibernética para uma ou outra tecnologia. Como a ANATEL está ciente, as várias tecnologias tendem a trabalhar juntas devido a períodos de transição, eficiência da rede em diferentes estados de desenvolvimento ou ainda tecnologias que façam uso simultâneo de diferentes gerações de equipamentos . Isso se torna mais visível quando falamos de redes 5G, que em um primeiro momento estarão intrinsicamente ligadas as redes 4G, LTE. Dessa forma, recomendamos a ANATEL para evitar requisitos e métodos específicos de projeto. Em vez disso, políticas eficazes de segurança cibernética devem permitir práticas flexíveis e orientadas ao processo.

    Do ponto de vista da cibersegurança, idealmente, devemos ter um conjunto de princípios de alto nível e práticas orientadas a processos que abranjam todo o ecossistema, e não diferentes conjuntos de regulamentos para diferentes conjuntos de tecnologias que estão sendo usados. O que de certa forma confronta com a proposta do item 6.1.4. que não tem sua aplicabilidade factível com os diferentes setores da indústria de Telecomunicações. Os itens 6.1.5 e 6.1.6 são outro exemplo que tem sua aplicabilidade destinada apenas ao setor de devices/ CPE’s/ smartphones, não sendo compatível com a indústria de infraestrutura. Cibersegurança é um campo dinâmico e interconectado que transcende fronteiras geográficas e jurisdições nacionais. As empresas de tecnologia da informação e comunicação (TIC) realizam operações comerciais e entregam a clientes em países do mundo todo. Muitos deles atendem ao mercado global moderno por meio de cadeias de suprimentos complexas, nas quais os produtos são desenvolvidos e montados através de fronteiras nacionais para usuários de todos os setores - da agricultura aos serviços financeiros, da manufatura às entidades governamentais. Essas empresas não apenas inovam e investem no desenvolvimento de produtos e serviços interoperáveis e implantáveis globalmente, mas também contribuem para a formação de padrões internacionais de segurança cibernética.

    Contribuição N°: 137
    ID da Contribuição: 92703
    Autor da Contribuição: Paulo Cesar Valete
    Data da Contribuição: 17/05/2020 19:59:41
    Contribuição:

    Dar nova redação ao item 6.1.4 conforme segue:

    6.1.4. Prover atualizações de segurança por, no mínimo, 2 (dois) anos após a comunicação formal da descontinuidade do produto ou enquanto o equipamento estiver sendo distribuído ao mercado consumidor, sendo aplicável a opção que mais se estender.

    Justificativa:

    A Telefônica Brasil S.A. destaca que há uma dificuldade maior para obtenção de suporte após a descontinuidade do produto. Assim, a alteração proposta visa um melhor controle sobre o fim do suporte, permitindo, se for o caso, o estabelecimento de programa mais adequado de substituição do produto. 

    Contribuição N°: 138
    ID da Contribuição: 92712
    Autor da Contribuição: Sergio Mauro da Silva Maia
    Data da Contribuição: 17/05/2020 20:58:41
    Contribuição:

    Contribuição, Itens 6.1.5 e 6.1.6: Para os subitems acima, sugerimos que as informações prestadas , quando aplicáveis,  sejam fornecidas pelo canal padrão de atendimento ao cliente disponibilizado pela prestadora ou por meio de página da prestadora na internet em língua portuguesa.

    Justificativa:

    Justificativa: Utilização de canais de comunicação já existentes com o usuário, evitando custos extras às prestadoras.

     Item:  7. DISPOSIÇÕES FINAIS

    7.1.Considerando as ininterruptas evoluções tecnológicas do setor de telecomunicações e o incessante surgimento de novas ameaças à segurança cibernética para equipamentos de telecomunicações, este documento está sujeito a periódicas atualizações a fim de manter-se alinhado ao estado da arte do setor.

    Contribuição N°: 139
    ID da Contribuição: 92587
    Autor da Contribuição: GUILHERME CARVALHO DE CAMARGO
    Data da Contribuição: 14/05/2020 17:14:10
    Contribuição:

    Melhorar a segurança dos dispositivos conectados, incluindo hardware, software e firmware, é um dos desafios mais prementes que enfrentamos na área de segurança cibernética, e a BSA e seus membros estão ansiosos em trabalhar com a Anatel para incentivar medidas de segurança mais robustas em toda a indústria de TI. Esperamos que nossas recomendações ajudem a Anatel a desenvolver e refinar seus padrões de segurança cibernética, e esperamos trabalhar em conjunto com a Anatel para garantir que esses padrões sejam o mais eficazes possíveis para fortalecer a confiança dos consumidores em dispositivos conectados. Obrigado pela oportunidade de oferecer comentários a respeito deste importante assunto.

    Justificativa:

    Melhorar a segurança dos dispositivos conectados, incluindo hardware, software e firmware, é um dos desafios mais prementes que enfrentamos na área de segurança cibernética, e a BSA e seus membros estão ansiosos em trabalhar com a Anatel para incentivar medidas de segurança mais robustas em toda a indústria de TI. Esperamos que nossas recomendações ajudem a Anatel a desenvolver e refinar seus padrões de segurança cibernética, e esperamos trabalhar em conjunto com a Anatel para garantir que esses padrões sejam o mais eficazes possíveis para fortalecer a confiança dos consumidores em dispositivos conectados. Obrigado pela oportunidade de oferecer comentários a respeito deste importante assunto.

    Contribuição N°: 140
    ID da Contribuição: 92661
    Autor da Contribuição: Telma do Carmo Canotilho
    Data da Contribuição: 16/05/2020 10:06:37
    Contribuição:

     

    7.x, REQUISITOS RETIRADOS DA Instrução Normativa número 4 - Segurança Cibernética QUE DEVEM SER ADOTADOS PARA OS EQUIPAMENTOS UTILIZADOS NAS REDES 5G.

     

    7.1. Garantir que os serviços prestados e os equipamentos utilizados cumpram os protocolos de comunicação e as especificações técnicas de infraestrutura reconhecidos pela Agência Nacional de Telecomunicações ou, na sua ausência, aqueles estabelecidos pela Associação Brasileira de Normas Técnicas (ABNT) ou reconhecidos internacionalmente;

     

    7.2. Garantir que, está disponível nos equipamentos a serem utilizados pela empresa provedora de serviços , ao menos os padrões nos moldes do SEC009 (Multi-tenant hosting management security) e do SEC002x (Security feature management of open source software), definidos pela ETSI (European Telecommunications.

     

    7.3. Garantir que se utiliza o protocolo IPV6, a fim de se evitar o tráfego de dados forjados, sem prejuízo da proteção da origem dos dados trafegados.

     

    7.4. Deixar claro se os softwares utilizados nos equipamentos de infraestrutura de redes 5G são abertos e se são passíveis de auditoria em termos de segurança.

      

    7.5. Garantir que o produto / Sistema passou por um processo de auditoria que assegurem a segurança cibernética dos produtos / sistemas utilizados na rede 5G, podendo ser fornecidos de forma conjunta com as prestadoras de serviços e empresas interessadas em fornecer tecnologia 5G;

     

    7.6. Garantir que o equipamento não afeta os requisitos de segurança da informação, quais sejam: disponibilidade, integridade, e confidencialidade na atividade de tráfego na rede 5G.

     

    7.7 Deixar claro se os equipamentos dispõem de mecanismos que possibilitem inspeção, inclusive a sua auditoria, em equipamentos em produção, até mesmo com a retirada de hardware  para avaliação em laboratório;

     

    7.8. Garantir que o equipamento dispõe de facilidade para  registrar o estado de configuração dos equipamentos de sua rede (resultado do gerenciamento de configuração), contendo informações como topologia de rede, versões de hardware e de software dos equipamentos, a fim de auxiliar a atividade de auditoria.

     

    8.1.Considerando as ininterruptas evoluções tecnológicas do setor de telecomunicações e o incessante
    surgimento de novas ameaças à segurança cibernética para equipamentos de telecomunicações, este
    documento está sujeito a periódicas atualizações a fim de manter-se alinhado ao estado da arte do setor.
    Imprimir

     

    9. MODELO DE RELATORIO COM  LISTA DE VERIFICAÇÃO E AVALIAÇÃO DO PRODUTO APRESETADO

     

    Ferramenta para evidenciar conformidade do Produto/Sistema apresentado pelo SOLICITANTE aos requisitos da Anatel especificados na tabela abaixo.

     

    Previsto determinar o grau de atendimento a estes requisitos básicos de segurança cibernética.

     

     

     

    MODELO DE RELATÓRIO DE AVALIAÇÃO DE CONFORMIDADE 

     

    1.           OBJETIVO

     

    Ferramenta para evidenciar conformidade do Produto/Sistema apresentado pelo SOLICITANTE aos requisitos da Anatel especificados na tabela abaixo.

     

    Previsto determinar o grau de atendimento a estes requisitos básicos de segurança cibernética.

     

     

     

    2.           IDENTIFICAÇÃO DO PRODUTO

     

    SISTEMA:

    xxxxx

     

    PRODUTO:

    MODELOS:

    Xxxxx

    xxxxxx

    ZZZZZZZ 

     

    3.           CARACTERÍSTICAS TÉCNICAS DOS PRODUTOS

     

    O Produto/Sistema  apresentado pelo solicitante é composto hardware contidos na lista anexa bem como de software.

     

    Descrição de como funciona o produto/Sistema e as condições de contorno utilizadas no seu projeto.

     

    Em particular descrever/declarar a política de segurança cibernética projetada e implementada.

     

     

     

    4.           REFERÊNCIAS TÉCNICAS

     

    Nota: Listar as referências técnicas utilizadas no projeto do seu produto de preferência com normas e melhores práticas internacionais.

     

    4.1.           Regulamento de Avaliação da Conformidade e de Homologação de Produtos para Telecomunicações, aprovado pela Resolução n.º 715, de 23 de outubro de 2019.

     

    4.2.           OECD - Enhancing the Digital Security of Products - Draft Scoping Paper (November 2019).

     

    4.3.           IEEE Internet Technology Policy Community White Paper - Internet of Things (IoT) Security Best Practices (February 2017).

     

    4.4.           IETF - Internet of Things (IoT) Security: State of the Art and Challenges - RFC 8576.

     

    4.5.           LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

     

    4.6.           ENISA - Baseline Security Recommendations for IoT in the Context of Critical Information Infrastructures (November 2017).

     

    4.7.           GSMA IoT Security Guidelines – Complete Document Set.

     

    4.8.           Instrução Normativa número 4 de 26/03/2020 - Gabinete de Segurança Institucional

     

     

     

    5.        RELAÇÃO DE DOCUMENTOS APRESENTADOS

     

    Manual/Especificações Técnicas; Declaração do fabricante

     

    Fotos – Diagramas  -  Certificações

     

     

     

    6.       AVALIAÇÃO DOS REQUISITOS BÁSICOS DE SEGURANÇA CIBERNÉTICA E O GRAU DE ATENDIMENTO EVIDENCIADO.

     

     

     

    Requisitos mínimos de segurança cibernética para equipamentos de telecomunicações

    1          

    Ser Produto/Sistema  de terminal que se conectam à Internet e para produtos/ Sistemas de infraestrutura de redes de telecomunicações, com facilidades construídas visando minimizar vulnerabilidades por meio de atualizações de software/firmware ou por meio de recomendações em configurações e em seus mecanismos de gerenciamento remoto.

     

    Grau

    0

    4

    8

    10

     

     

     

     

     

     

     

     

    Requisitos  Gerais

     

    2          

    Analise e Avaliação dos documentos fornecidos e da declaração de conformidade para evidenciar consistência com produto e modelos abrangidos considera as diferentes características técnicas dos equipamentos (quantidade de memória, capacidade de processamento de dados, interfaces do usuário, interfaces de comunicação, etc.) e os fins a que se destinam. O que foi declarado/evidenciado e o que será comercializado?
     

    Grau

    0

    4

    8

    10

     

     

     

     

     

    3          

    Evidenciar que para produtos enquadrados na definição de CPE (Customer Premises Equipment) , a declaração de conformidade deve orientar-se, adicionalmente, pelo conjunto de requisitos contidos na referência :- LAC-BCOP-1 (May/2019) – Best Current Operational Practices on Minimum Security Requirements for Customer Premises Equipment (CPE) Acquisition.

     

    Grau

    0

    4

    8

    10

     

     

     

     

     

    4          

    Identificar/declarar vulnerabilidades relacionadas a um ou mais requisitos de segurança cibernética e o grau de risco da vulnerabilidade. Validar análise de risco e garantir que será informado aos usuários e demais interessados.

    Grau

    0

    4

    8

    10

     

     

     

     

     

    5          

    Evidenciar/avaliar que possui mecanismos periódicos, seguros e automatizados para atualização de software/firmware que empregam métodos adequados de confidencialidade, integridade, disponibilidade e autenticidade.

    Grau

    0

    4

    8

    10

     

     

     

     

     

    6          

    Deve garantir que as informações trafegadas estão suportadas por um protocolo de segurança, criptografia e algoritmos de segurança e métodos de verificação de integridade, provendo a confidencialidade e inviolabilidade dos dados.

    Grau

    0

    4

    8

    10

     

     

     

     

     

    7          

    Evidenciar/avaliar que os usuários verifiquem, de forma não automatizada, a disponibilidade de atualizações de software/firmware.

    Grau

    0

    4

    8

    10

     

     

     

     

     

     

     

     

     

    8          

    Evidenciar/avaliar  que se identificado uma vulnerabilidade no software/firmware é garantido que o equipamento seja atualizado/ação corretiva.

    Grau

    0

    4

    8

    10