Introdução

No post Requisitos de Segurança Cibernética da Anatel (Ato 77/21), abordamos o Ato nº 77/21 da Anatel, que define requisitos de segurança cibernética para equipamentos de telecomunicações vendidos no país. Naquela oportunidade, discutimos o Ato de uma maneira geral e examinamos os seus requisitos.

Neste blog post compartilhamos nossa experiência com um ensaio de avaliação de segurança de um dispositivo IoT baseada nos requisitos prescritos pela regulamentação, provendo uma visão geral da avaliação e as algumas das principais implicações práticas do Ato para os fabricantes de dispositivos.

 

 

Avaliação de Conformidade de Dispositivo IoT ao Ato 77/21

Como parte de sua análise do Ato nº 77/21 da Anatel, o SiDi avaliou a conformidade perante o disposto de um dispositivo IoT bastante comum no mercado: um smart speaker (alto-falante com comando de voz para serviço de assistente pessoal inteligente).

A avaliação aqui apresentada tem caráter meramente ilustrativo e é nula para fins de homologação/certificação perante o órgão. Ela visa tão somente servir como uma prova de conceito ao processo de avaliação de conformidade aos requisitos prescritos no Ato nº 77/21 da Anatel.

As seções que seguem resumem os principais aspectos da avaliação e descrevem alguns dos destaques do processo.

 

 

Checklist

Como ponto de partida para a análise aqui discutida, elaborou-se um checklist (documento contendo uma lista de requisitos prescritos pela norma), de forma a guiar o processo de análise em face ao disposto. Checklists constituem uma ferramenta amplamente utilizada no nicho de teste e análise de segurança e têm como principal finalidade evitar erros e omissões no processo de avaliação no que diz respeito à garantia de sua completude, assegurando ampla cobertura de testes.

O checklist desenvolvido para realizar a análise contempla 52 casos de teste, levantados com base nos requisitos – e respectivas implicações práticas – prescritas pela agência reguladora.

Os parágrafos que seguem procuram ilustrar a maneira como a elucidação de tais casos de teste se deu, provendo um exemplo de derivação de casos de teste a partir de um dos itens do requisito 4.1 do Ato nº 77/21.

O propósito do trecho abaixo é prover uma visão de como, a partir de um requisito em alto nível do Ato, se deu a derivação de casos de teste granulares. Posteriormente, na seção Destaques da Análise, o leitor verá como se deu a verificação, propriamente dita, de alguns dos casos de teste que resultaram do processo de derivação aqui ilustrado.

O requisito 4.1 do Ato, em seu item “a)”, prescreve:

 

“4.1. Ao requerer a homologação do produto para telecomunicações junto à Anatel, o requerente deve apresentar uma declaração:

a) indicando que o produto foi desenvolvido em observância ao princípio de security by design;”

 

O princípio de security by design dita que produtos de software sejam, desde o início, projetados para serem fundamentalmente seguros. Ora, de forma a aderir a ele, espera-se que, desde as fases mais embrionárias do SDLC (Software Development Life Cycle, ou “ciclo de vida de software”), um produto de software incorpore determinadas preocupações de engenharia de segurança, a saber:

1. Minimização da superfície de ataque: reduzir o número de pontos de entrada através dos quais uma entidade maliciosa (ou “atacante”) possa vir a comprometer quaisquer requisitos de segurança que o produto em questão se proponha a cumprir;
2. Configuração padrão de fábrica segura: utilizar configurações seguras já a partir do momento em que o usuário final comece a utilizá-lo, sem que seja necessária qualquer intervenção por parte do usuário no que diz respeito à seleção ou implementação de tais configurações;
3. Minimização de privilégios: servir-se do princípio de least privilege, que prescreve que quaisquer subentidades do produto (e.g. contas de usuário, serviços de rede e outras entidades computacionais) tenham apenas os privilégios de segurança necessários ao cumprimento de suas tarefas no contexto geral do produto;
4. Defesa em profundidade: servir-se do princípio de defense in depth, que prescreve que contramedidas de segurança sejam dispostas em superposição, de maneira que uma linha defensiva extensa, ou “profunda”, aumente a distância entre um adversário e o seu objetivo, de forma a desmotivar, adiar e eventualmente dissuadir eventuais ataques;
5. Garantia de estado seguro após falhas: restaurar um estado de operação seguro depois que uma falha, natural ou forçada, ocorra durante a sua operação normal, de forma que eventuais falhas não representam a transição do sistema a um estado de operação inseguro;
6. Separação de responsabilidades: levar em consideração, desde a fase de concepção, o princípio de separation of duties, que prescreve que subentidades específicas devem ter atribuições distintas, sem sobreposição, de maneira que o comprometimento de uma dessas subentidades se limite a prejudicar apenas os recursos sobre os quais a subentidade comprometida pode agir; e
7. Moderação no uso de controles de segurança por obscuridade: a prática de security by obscurity consiste em acreditar no fato de que algo está “escondido” e, portanto, “seguro”. Tal asserção contraria diretamente o princípio de Kerckhoffs (Máxima de Shannon), segundo o qual um design de segurança, em si mesmo, não deve ser requerido como segredo.

Fez-se, então, a derivação de 7 pontos de análise a partir de um único requisito. De forma semelhante, casos de teste foram derivados a partir dos demais requisitos de segurança prescritos pelo Ato nº 77/21 da Anatel, totalizando os 52 casos previstos no checklist.

 

Destaques da Análise

Nesta seção, alguns dos principais pontos da análise são apresentados (lista não exaustiva) e suas implicações no SDLC de fabricantes de dispositivos são discutidas. Para cada destaque, introduz-se, primeiro, o(s) requisito(s) a que se referem. Em seguida, os resultados de análise são apresentados e suas implicações práticas são discutidas.

 

Verificação de Atualizações de Segurança

Dentre os requisitos previstos no Ato nº 77/21, o requisito 5.1.1, item “c)”, prescreve:

 

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

c) Possuir mecanismos para informar ao usuário as alterações de software/firmware implementadas devido às atualizações, especialmente aquelas relacionadas à segurança.”

 

O requisito em questão levanta a necessidade de os fabricantes de dispositivos regulamentados pelo Ato nº 77/21 da Anatel conferirem transparência aos seus programas de patching (disponibilização de atualizações de segurança de seus produtos), de forma a esclarecer aos usuários as alterações sofridas por seus dispositivos quando de cada atualização entregue.

Durante a avaliação, verificou-se que, apesar de o fabricante do smart speaker analisado  disponibilizar ao usuário final informação a respeito das atualizações de software/firmware disponíveis/aplicadas, não é possível saber com precisão quais foram as alterações implementadas devido a tais atualizações, tampouco há distinção entre atualizações de segurança e atualizações de outra natureza, de forma que, caso a análise aqui descrita tivesse qualquer validade, o dispositivo não estaria em conformidade com o disposto.

 

Logs de Segurança

O Ato nº 77/21 prescreve, ainda, a adoção de logging de eventos de segurança, conforme enunciado do requisito 5.1.3, item “e)” (sic):

 

“5.1.3. Quanto à instalação e à operação:

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

 

Durante a análise aqui reportada, verificou-se que o smart speaker analisado disponibiliza a usuários finais uma interface de configuração, através da qual é possível acessar listagens de eventos do sistema.

No entanto, tal listagem é restrita a eventos corriqueiros de funcionamento, não sendo possível ao usuário final – através somente das interfaces de usuário previstas pelo fabricante – acessar logs de eventos mais específicos, de forma a verificar entradas relacionadas às atividades com teor de segurança previstas na regulamentação, quais sejam: autenticação e alteração de configurações. Assim, caso a avaliação aqui reportada tivesse qualquer validade, o smart speaker analisado atenderia apenas parcialmente a esse item do Ato.

Introduz-se, então, a necessidade de os fabricantes proverem meios de os usuários acessarem logs de segurança dos dispositivos regulamentados pelo Ato, seja através de interface de usuário própria, seja utilizando interfaces servidas através de outros dispositivos e.g. aplicativo móvel.

 

Detalhes de Software/Firmware e Código Aberto

Já o item “f)”, do mesmo requisito, prescreve:

 

“f) Fornecer documentação que descreva, no mínimo, o nome, a versão e as funcionalidades do software/firmware e/ou sistema operacional, bem como nome completo e versão de cada software de código aberto incorporado ao sistema. A documentação pode ser em formato eletrônico.”

 

Apesar de disponibilizar a versão do software/firmware do smart speaker analisado, o fabricante não provê maiores detalhes. Ademais, o fabricante provê documentação eletrônica a respeito das funcionalidades do dispositivo.

Finalmente, o fabricante disponibiliza a porção do código do dispositivo oriundo de projetos open source, isto é, de código aberto, mas não há documentação estruturada a respeito do código e/ou das versões de cada componente de software de código aberto incorporado ao sistema. As informações exigidas podem ser recuperadas, entretanto, isso só poderia se dar através de revisão técnica do código-fonte, de forma que, se a análise aqui discutida tivesse qualquer validade, o dispositivo atenderia somente parcialmente ao requisito analisado.

O requisito em questão, portanto, exige dos fabricantes grande transparência no que diz respeito ao software/firmware do dispositivo, tanto em relação às suas funcionalidades específicas, quanto em relação à utilização de componentes open source.

 

Acesso Seguro à Configuração do Equipamento

Curiosamente, o Ato nº 77/21 da Anatel prescreve alguns requisitos referentes ao acesso seguro às configurações do dispositivo, dentre os quais:

 

“5.1.4. Quanto ao acesso para configuração do equipamento:

c) Forçar, na primeira utilização, a alteração da senha inicial de acesso à configuração do equipamento.”

 

No entanto, a configuração do smart speaker analisado é feita de forma automática, através de um aplicativo móvel pareado via Bluetooth, quando do primeiro uso, não demandando ao usuário acessar uma interface de configuração através de um mecanismo de autenticação. Portanto, aqui, resta saber qual seria o entendimento do órgão: (i) o primeiro uso do dispositivo em questão precisaria ser redesenhado para prever o uso de credenciais, de maneira a atender ao requisito de alteração quando da primeira autenticação, previsto no Ato? Ou (ii) devido à natureza do dispositivo, de uso doméstico, ele estaria isento da necessidade de atender a este requisito? Entende-se que tal aspecto do requisito é discutível. Portanto, os resultados da análise aqui reportada, quanto a este item, são inconclusivos.

 

Divulgação Coordenada de Vulnerabilidades

O requisito 6.1.6 do Ato prescreve:

 

“6.1.6. Possuir implementados processos de Divulgação Coordenada de Vulnerabilidades baseados em boas práticas e recomendações reconhecidas internacionalmente.”

 

Durante a análise do dispositivo, constatou-se que, apesar de o fabricante possuir um programa de divulgação coordenada de vulnerabilidades, tal programa não contempla o smart speaker cuja análise é aqui reportada. Sendo assim, caso a análise aqui descrita tivesse qualquer validade, o dispositivo não estaria em conformidade com o disposto.

Cabe mencionar que o fato de o Ato nº 77/21 prever um programa de divulgação coordenada de vulnerabilidades é um avanço em perfeita consonância com uma prática já bastante difundida na indústria de software, a exemplo dos programas de divulgação coordenada de vulnerabilidades de referências no setor, como o Google (e.g. programa “Android Security Bulletins” – contemplando o sistema operacional mobile Android) e a Microsoft (e.g. “Microsoft Security Update Guides” – contemplando múltiplos produtos da empresa).

 

Resumo dos Resultados

Dos 52 itens verificados, caso a análise aqui relatada tivesse qualquer validade, constatar-se-ia que o smart speaker analisado atenderia a apenas 9 itens do Ato.

Quanto aos demais, dividem-se entre (i) itens aos quais o dispositivo, certamente, não atende, (ii) itens cujo atendimento é parcial e (iii) itens inconclusivos, seja por questões interpretativas da regulamentação que merecem esclarecimento, seja por falta de informações internas do fabricante acerca do dispositivo, às quais não houve acesso durante a análise aqui reportada.

 

Conclusão

Assim, supondo que o smart speaker analisado é um exemplar representativo e mediano do universo de dispositivos os quais o Ato nº 77/21 se propõe a regulamentar, nota-se a necessidade de adequações por parte dos fabricantes de dispositivos, de maneira que consigam atender às exigências do Ato em discussão.

Ademais, percebe-se, ainda, a necessidade de esclarecimentos do órgão quanto a alguns pontos previstos na regulamentação, uma vez que nem tudo o que é disposto parece ter aplicabilidade a todo o universo de dispositivos os quais, potencialmente, o Ato nº 77/21 da Anatel se propõe a regular.

Como próximos passos no estudo do Ato nº 77/21, sugere-se a elucidação, junto à Anatel, dos requisitos cujos resultados foram inconclusivos nesta análise. Sugere-se, ainda, a expansão do ensaio aqui relatado, de forma a incluir dispositivos de outras naturezas, resultando em uma amostra mais representativa do universo de produtos regulamentados pelo Ato.