fbpx
ArtigosEm Destaque

Estrutura de Confiança de Segurança e Privacidade da IoT, v2.5

O IoT Trust Framework® inclui um conjunto de princípios estratégicos necessários para ajudar a proteger dispositivos da IoT e seus dados, quando enviados e durante todo o seu ciclo de vida. Por meio de um processo de múltiplas partes interessadas, orientado por consenso, foram identificados critérios para tecnologias domésticas, de escritório e wearables conectados, incluindo brinquedos, rastreadores de atividade e dispositivos de condicionamento físico. A Framework descreve a necessidade de divulgações abrangentes que precisam ser fornecidas antes da compra do produto, políticas relativas à coleta de dados, uso e compartilhamento, bem como os termos e condições de segurança de correções após a garantia.

As atualizações de segurança são essenciais para maximizar a proteção de dispositivos da IoT, quando as vulnerabilidades são descobertas e os ataques evoluem. Além disso, a Framework fornece recomendações para os fabricantes aumentarem a transparência e a comunicação em relação à capacidade dos dispositivos de serem atualizados e a uma série de questões relacionadas à privacidade de dados.

Essencial para abordar os riscos de segurança inerentes e problemas de privacidade é a aplicação dos princípios a toda a solução ou ecossistema do dispositivo. Isso inclui o dispositivo ou sensor, os aplicativos de suporte e os serviços de backend/nuvem. Como muitos produtos que chegam ao mercado dependem de componentes e softwares de código aberto ou de terceiros, cabe aos desenvolvedores aplicar esses princípios e realizar avaliações de segurança da cadeia de suprimentos e de privacidade.

Servindo como um guia de avaliação de risco para desenvolvedores, compradores e varejistas, a Framework é a base para futuros programas de certificação da IoT. O objetivo da OTA é destacar os dispositivos que atendem a esses padrões para ajudar os consumidores, bem como os setores público e privado, a tomar decisões de compra informadas. A Framework e os recursos relacionados estão disponíveis em https://otalliance.org/IoT.

A Framework é dividida em 4 áreas principais:

  • Princípios de Segurança (1-12) − Aplicável a qualquer dispositivo ou sensor e todos os aplicativos e serviços de nuvem de back-end. Elas abrangem desde a aplicação de um rigoroso processo de segurança de desenvolvimento de software até a adesão aos princípios de segurança de dados, para dados armazenados e transmitidos pelo dispositivo, para fornecer gerenciamento de cadeia, testes de penetração e programas de relatórios de vulnerabilidade. Outros princípios descrevem o requisito de patching de segurança do ciclo de vida.
  • Acesso do Usuário e Credenciais (13-17) − Requisito de criptografia de todas as senhas e nomes de usuários, envio de dispositivos com senhas exclusivas, implementação de processos de redefinição de senha geralmente aceitos e integração de mecanismos para evitar tentativas de login de “força bruta”.
  • Privacidade, Divulgação e Transparência (18 a 33) − Requisitos consistentes com os princípios de privacidade geralmente aceitos, incluindo divulgações proeminentes em embalagens, ponto de venda e/ou postagem online, recurso para que os usuários tenham a capacidade de redefinir dispositivos para configurações de fábrica e conformidade com os requisitos regulamentares aplicáveis, incluindo o GDPR da UE e os regulamentos de privacidade das crianças. Também aborda as divulgações sobre o impacto nos recursos ou na funcionalidade do produto, se a conectividade estiver desativada.
  • Notificações e práticas recomendadas relacionadas (34-40) − A chave para manter a segurança dos dispositivos é ter mecanismos e processos para notificar prontamente o usuário sobre as ameaças e ações necessárias. Os princípios incluem a exigência de autenticação de e-mail para notificações de segurança e que as mensagens devem ser comunicadas claramente aos usuários de todos os níveis de leitura. Além disso, os requisitos de embalagem e acessibilidade à prova de adulteração são destacados.
IoT Trust Framework – ˜ Necessária (obrigatória) | Recomendada
Segurança – Dispositivo, Apps e Serviços na nuvem
1. Divulgue se o dispositivo é capaz de receber atualizações relacionadas à segurança e, se sim, divulgue se o dispositivo pode receber atualizações de segurança automaticamente, e qual ação do usuário é necessária para garantir que o dispositivo seja atualizado corretamente e em tempo hábil. ˜
2. Certifique-se de que os dispositivos e aplicativos associados oferecem suporte aos protocolos e práticas recomendadas de segurança e criptografia geralmente aceitos atualmente. Todos os dados pessoalmente identificáveis em trânsito e em armazenamento devem ser criptografados usando os atuais padrões de segurança geralmente aceitos. Estes incluem, mas não se limitam a conexões por fio, Wi-Fi e Bluetooth.  

˜

3. Todos os sites de suporte da IoT devem criptografar totalmente a sessão do usuário do dispositivo para os serviços de back-end. As práticas recomendadas atuais incluem HTTPS e HTTP Strict Transport Security (HSTS) como padrão, também conhecidas como AOSSL ou Always On SSL. Os dispositivos devem incluir mecanismos para autenticar, de forma confiável, seus serviços de back-end e aplicativos de suporte1.  

˜

4. Os sites de suporte da IoT devem implementar o monitoramento regular e a melhoria      contínua da segurança dos sites e das configurações do servidor para, aceitavelmente, reduzir o impacto das vulnerabilidades. Realize testes de penetração pelo menos semestralmente2. ˜
5. Estabeleça divulgação coordenada de vulnerabilidades, incluindo processos e sistemas para receber, rastrear e responder prontamente relatórios de vulnerabilidade externos de terceiros, incluindo, entre outros, clientes, consumidores, comunidade acadêmica e comunidade de pesquisa. Corrija de vulnerabilidades e ameaças pós-lançamento de design de lançamento de produtos de maneira publicamente responsável, seja por meio de atualizações remotas e/ou por meio de notificações acionáveis do consumidor, ou outros mecanismos efetivos. Os desenvolvedores devem considerar os programas de “bug bounty” e métodos de crowdsourcing para ajudar a identificar vulnerabilidades.  

 

˜

 6. Assegure-se de que um mecanismo esteja em vigor para métodos seguros e seguros automatizados, para fornecer atualizações de software e/ou firmware, correções e revisões. Essas atualizações devem ser assinadas e/ou verificadas de outra forma como provenientes de uma fonte confiável, incluindo, mas não se limitando a, assinatura e verificação de integridade.  

˜

7. Atualizações e patches não devem modificar as preferências, segurança e/ou configurações de privacidade feitas pelo usuário, sem o seu conhecimento. Nos casos em que o firmware ou software do dispositivo for sobregravado no primeiro uso, o usuário deve ter a capacidade de revisar e selecionar as configurações de privacidade.  

˜

8. Os processos de atualização de segurança devem divulgar se eles são Automatizados (vs automáticos). As atualizações automáticas fornecem aos usuários a capacidade de aprovar, autorizar, ou rejeita-las. Em certos casos, um usuário pode querer decidir como e quando as atualizações serão feitas, incluindo, mas não se limitando ao consumo e à conexão de dados por meio de sua operadora de celular ou conexão ISP. Por outro lado, as atualizações automáticas são enviadas aos dispositivos sem interrupções, sem interação com o usuário, e podem ou não fornecer aviso prévio a ele.  

˜

9. Assegure-se de que todos os dispositivos IoT e softwares associados tenham sido submetidos a testes rigorosos e padronizados de desenvolvimento de software, incluindo teste de unidade, sistema, aceitação e regressão e modelagem de ameaças, além de manter um inventário da fonte para qualquer fonte aberta, código e/ou componentes. Empregue técnicas geralmente aceitas de código e proteção do sistema em uma variedade de cenários de casos típicos de uso, incluindo a prevenção de qualquer vazamento de dados entre o dispositivo, os aplicativos e os serviços na nuvem. O desenvolvimento de software seguro exige pensar na segurança desde o início de um projeto até a implementação, teste e implantação. Os dispositivos devem ser enviados com o software atual e/ou com atualizações automáticas de primeira inicialização, para resolver quaisquer vulnerabilidades críticas conhecidas.  

 

˜

10. Conduza avaliações de segurança e de conformidade de riscos para todos os provedores de serviços e de nuvem. Veja o guia de recursos de IoT https://otalliance.org/IoT ˜
11. Desenvolva e mantenha uma “lista de materiais”, incluindo software, firmware, hardware e bibliotecas de software de terceiros (incluindo módulos de software livre e plug-ins). Isso se aplica aos serviços de dispositivos, dispositivos móveis e nuvem para ajudar a corrigir rapidamente as vulnerabilidades relatadas. x
12. Projete os dispositivos para os requisitos mínimos necessários para a operação. Por exemplo, portas USB ou slots de cartão de memória devem ser incluídos, se forem necessários para a operação e manutenção do dispositivo. As portas e os serviços não utilizados devem ser desativados. ˜
Acesso e credenciais dos usuários
13. Inclua autenticação forte como padrão, inclusive o fornecimento de senhas exclusivas, geradas pelo sistema ou de uso único; ou, alternativamente, use credenciais de certificado seguro. Conforme necessário, exija o uso de senhas exclusivas para acesso administrativo, delineando entre dispositivos e serviços e o respectivo impacto das redefinições de fábrica.  

˜

14. Forneça mecanismos de recuperação geralmente aceitos para aplicativos de IoT e senhas de suporte e/ou mecanismos para redefinição de credenciais, usando a verificação e autenticação de múltiplos fatores (e-mail , telefone, etc.), onde não existir senha de usuário. ˜
15. Tome medidas para proteger contra ‘força bruta’ e/ou outras tentativas abusivas de login (como robôs de login automatizados, etc.), bloqueando ou desativando contas de suporte a usuários e dispositivos após um número razoável de tentativas inválidas de login. ˜
16. Forneça aos usuários notificação de redefinição ou de alteração de senhas, ou alterações utilizando autenticação segura e/ou aviso (s) fora de banda (s). ˜
17. Credenciais de autenticação, incluindo, mas não se limitando a senhas de usuários, devem ser salgadas, com hash e/ou criptografadas. Isto se aplica a todas as credenciais armazenadas, para ajudar a impedir ataques não autorizados e ataques de força bruta. ˜
Privacidade, divulgações e transparência
18. Assegure que as políticas de privacidade, segurança e suporte sejam facilmente detectáveis, claras e prontamente disponíveis para revisão antes da compra, ativação, download, ou inscrição. Além da colocação proeminente na embalagem do produto e em seu site, recomenda-se que as empresas utilizem QR Codes, URLs curtos e outros métodos similares no ponto de venda.  

˜

 19. Divulgue a duração e o suporte de segurança e patch no final da vida útil (além da garantia do produto). O suporte pode terminar em uma data de término da validade, como 1º de janeiro de 2025, ou por uma duração específica no momento da compra, não muito diferente de uma garantia tradicional. Idealmente, tais divulgações devem estar alinhadas com a expectativa de vida útil do dispositivo e comunicadas aos consumidores antes da compra. (Reconhece-se que os dispositivos de IoT não possam ser indefinidamente seguros e controláveis. Considere a possibilidade de comunicar os riscos de usar um dispositivo além de sua data de validade e o impacto e risco para os outros, se os avisos forem ignorados ou se o dispositivo não for retirado). Se os usuários precisarem pagar taxas ou assinar um contrato de suporte anual, isso deve ser divulgado antes da compra.  

 

˜

 20. Divulgue claramente quais tipos e atributos de dados pessoalmente identificáveis e sensíveis serão coletados e como eles serão usados, limitando a coleta a dados que sejam razoavelmente úteis para a funcionalidade e a finalidade para a qual estão sendo coletados. Divulgue e forneça aos consumidores a possibilidade de optar por quaisquer outros fins.  

˜

21. Divulgue o que e como os recursos deixarão de funcionar se a conectividade ou os serviços de back-end ficarem desabilitados ou forem interrompidos, incluindo, entre outros, o possível impacto na segurança física. Inclua o que acontece quando o dispositivo não receber mais atualizações de segurança ou se o usuário não atualizar o dispositivo. (Considere a criação de controles para desabilitar a conectividade ou desativar portas para reduzir possíveis ameaças, mantendo a funcionalidade principal do produto, com base no uso do dispositivo, pesando possíveis problemas de vida/segurança). ˜
22. Divulgue a política de retenção de dados e a duração do armazenamento de informações pessoais identificáveis. ˜
23. Os dispositivos de IoT devem fornecer aviso e/ou solicitar confirmação do usuário ao fazer o emparelhamento inicial, a integração e/ou a conexão com outros dispositivos, plataformas ou serviços. ˜
24. Divulgue se e como a propriedade do dispositivo/produto/serviço da IoT e os dados podem ser transferidos (por exemplo, uma casa conectada sendo vendida para uma nova empresa, proprietário, ou a venda de um rastreador de fitness). ˜
 25. Somente compartilhe os dados pessoais dos consumidores com terceiros com o consentimento dos consumidores, a menos que seja necessário e limitado para o uso dos recursos do produto ou operação do serviço. Exija que os provedores de serviços terceirizados sejam mantidos nas mesmas políticas, incluindo a retenção desses dados em requisitos de confiança e notificação de qualquer perda de dados/incidente de violação e/ou acesso não autorizado.  

˜

 26. Forneça controles e/ou documentação que permitam ao consumidor analisar e editar as preferências de privacidade do dispositivo IoT, incluindo a capacidade de redefinir para o “padrão de fábrica”. ˜
 27. Comprometa-se a não vender ou transferir quaisquer dados de consumidores identificáveis, a menos que seja uma parte dependente da venda ou liquidação da empresa principal, que originalmente coletou os dados, desde que a política de privacidade da parte adquirente não altere substancialmente os termos. Caso contrário, a notificação e o consentimento devem ser obtidos.  

˜

 28. Ofereça a possibilidade de um consumidor devolver um produto sem custos após analisar as práticas de privacidade apresentadas antes da operação, desde que tais termos não sejam divulgados de maneira visível antes da compra. O prazo (número de dias) para devolução de produtos deve ser consistente com as atuais políticas de troca do varejista, ou como foi anteriormente especificado.  

˜

 29. Sempre que a oportunidade se apresentar para recusar ou não optar por qualquer política, as consequências devem ser explicadas de forma clara e objetiva, incluindo qualquer impacto sobre os recursos ou a funcionalidade do produto. Recomenda-se que a possibilidade do usuário final optar por e/ou compartilhar dados seja comunicada ao usuário final. ˜
30. Cumprir os regulamentos aplicáveis, incluindo, entre outros, a Lei de Proteção da Privacidade Online para Crianças (COPPA) e os requisitos regulamentares internacionais de privacidade, segurança e transferência de dados3,4. ˜
 31. Publique claramente a história das alterações do aviso de privacidade do material por no mínimo dois anos. As melhores práticas incluem carimbo de data, linhas vermelhas e resumo dos impactos das mudanças. ˜
32. Ofereça a capacidade do usuário, ou seu procurador, excluir ou tornar dados anônimos, pessoais ou confidenciais armazenados nos servidores da empresa (outros dados do histórico de transações de compra), ao interromper o uso, em caso de perda, ou da venda do dispositivo. x
 33. Ofereça a possibilidade de redefinir um dispositivo e aplicativo para as configurações de fábrica, incluindo a capacidade de apagar os dados do usuário, em caso de transferência, aluguel, perda ou venda. x
Notificações e melhores práticas a elas relacionadas
34. As comunicações do usuário final, incluindo, entre outras, e-mail e SMS, devem adotar protocolos de autenticação para ajudar a evitar spear phishing* e spoofing**. Os domínios devem implementar SPF, DKIM e DMARC para todas as comunicações e avisos relacionados a segurança e privacidade, bem como para domínios reservados e aqueles que nunca enviam e-mail5. *Spear phishing é um golpe de e-mail direcionado com o objetivo de obter acesso não autorizado a dados sigilosos. **Email spoofing é um artifício utilizado por spammers para falsificar o remetente de uma mensagem de e-mail.  

˜

35. Para comunicações por e-mail, no prazo de 180 dias após a publicação de uma política DMARC, implemente uma política de rejeição ou quarentena, que ajude os ISPs e as redes receptoras a rejeitar e-mails que não passem em verificações de autenticação de e-mail6. x
36. Os fornecedores de IoT que usam comunicação por e-mail devem adotar confidencialidade em nível de transporte, incluindo técnicas de segurança geralmente aceitas para ajudar a proteger as comunicações e melhorar a privacidade e integridade das mensagens (também chamada de “TLS Oportunista para e-mail”)7.  

x

37. Implemente medidas para ajudar a prevenir ou evidenciar qualquer adulteração física dos dispositivos. Essas medidas ajudam a proteger o dispositivo de ser aberto ou modificado para fins mal-intencionados após a instalação, ou de ser devolvido a um revendedor em um estado comprometido. x
38. Considere como acomodar os requisitos de acessibilidade para usuários que possam ser deficientes visuais, auditivos e/ou de mobilidade, para maximizar o acesso para usuários de todos os tipos de capacidades físicas. x
39. Desenvolva processos de comunicação para maximizar a conscientização do usuário sobre possíveis problemas de segurança ou privacidade, notificações de fim de vida útil e possíveis recalls de produtos, incluindo notificações no aplicativo. As comunicações devem ser escritas maximizando a compreensão para o nível geral de leitura do usuário. Considere comunicações multilíngues, reconhecendo que o inglês pode ser o “segundo idioma” dos usuários (veja os princípios relacionados com segurança e integridade de mensagens).  

˜

40. Decrete uma violação e uma resposta cibernética e um plano de notificação ao consumidor para ser reavaliado, testado e atualizado pelo menos anualmente, e/ou após mudanças significativas do sistema interno, mudanças técnicas e/ou operacionais. ˜

Recursos e atualizações são postadas em https://otalliance.org/IoT

Terminologia, Definições e Esclarecimentos

  1. Escopo – Focado em “dispositivos de consumo e serviços domésticos, corporativos, incluindo tecnologias vestíveis”. Smart Cars, incluindo veículos autônomos, assim como dispositivos médicos e dados HIPAA8, estão além do escopo da Framework, mas o maioria dos critérios é considerada aplicável. Respectivamente, eles se enquadram na supervisão regulatória da Administração Nacional de Segurança no Trânsito Rodoviário (NHTSA) e da Food and Drug Administration (FDA)9.
  2. Os termos fabricantes de dispositivos, fornecedores, desenvolvedores de aplicativos, provedores de serviços e operadores de plataforma são todos indicados pelo termo “Empresas”.
  3. Espera-se que as empresas divulguem casos de compartilhamento de dados com a aplicação da lei e façam referência a quaisquer relatórios de transparência aplicáveis, conforme permitido legalmente.
  4. Dispositivos inteligentes referem-se a dispositivos (e sensores) que estão em rede e podem ter apenas comunicações unidirecionais.

__________________

  1. https://otalliance.org/resources/always-ssl-aossl
  2. https://otalliance.org/blog/responsible-coordinated-ethical-vulnerability-disclosures
  3. Companies, products and services must be in compliance with any law or regulation of the jurisdiction that governs their collection and handling of personal and sensitive information, including but not limited to the adherence to the EU-US Privacy Shield Framework www.commerce.gov/privacyshield and/or the EU General Data Protection Regulation (GDPR) www.eugdpr.org. Failure to comply may constitute non-compliance with this framework.
  4. COPPA https://
  5. www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-ruleEmail Authentication – https://otalliance.org/eauth
  6. DMARC –https://otalliance.org/resources/dmarc
  7. TLS for Email – https://otalliance.org/best-practices/transport-layered-security-tls-email
  8. U.S. Department of Health & Human Services, Health Information Privacy
  9. http://www.hhs.gov/hipaa/index.htmlhttp://www.nhtsa.gov/Vehicle+Safety e http://www.fda.gov/MedicalDevices/default.htm

____________________________________________________________________________________

Artigo traduzido e compartilhado sob licença:

Creative Commons License

A OTA é uma iniciativa da Internet Society (ISOC), uma organização sem fins lucrativos 501c3 com a missão de promover o desenvolvimento, a evolução e o uso abertos da Internet para o benefício de todas as pessoas em todo o mundo. A missão da OTA é aumentar a confiança online, o empoderamento do usuário e a inovação por meio da convocação de iniciativas com várias partes interessadas, desenvolvimento e promoção de práticas recomendadas, práticas responsáveis de privacidade e gerenciamento de dados. Para saber mais, acesse https://otalliance.org e https://www.internetsociety.org.

© 2017 A Sociedade da Internet (ISOC). Todos os direitos reservados.

O material desta publicação é apenas para fins educacionais e informativos. Nem a editora, a Online Trust Alliance (OTA), a Internet Society (ISOC) nem os seus membros assumem qualquer responsabilidade por quaisquer erros ou omissões nem como esta publicação ou o seu conteúdo são utilizados ou interpretados ou por quaisquer consequências resultantes direta ou indiretamente a partir do uso desta publicação. Nem a OTA nem a ISOC fazem afirmações ou endossos em relação à segurança, privacidade ou práticas comerciais de empresas que podem optar por adotar as recomendações descritas. Para aconselhamento legal ou qualquer outro, por favor consulte o seu advogado pessoal ou profissional apropriado. Os pontos de vista expressos nesta publicação não refletem necessariamente as opiniões das empresas membros ou organizações afiliadas à OTA e à ISOC. A OTA e a ISOC NÃO OFERECEM NENHUMA GARANTIA, EXPRESSA, IMPLÍCITA OU ESTATUTÁRIA, QUANTO ÀS INFORMAÇÕES DESTE DOCUMENTO.

Tags
Mais