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