Regulamentar o desenvolvimento e a criação de produtos e serviços que contenham medidas de privacidade desde a sua concepção e por padrão nos processos de tecnologia é o objetivo, respectivamente, dos conceitos de Privacy by Design e de Privacy by Default. Mas como implementá-los na sua empresa?
Visando facilitar e difundir esses processos, a Autoridade Norueguesa de Proteção de Dados preparou um guia completo para ajudar organizações a melhor entenderem e ficarem em compliance com as exigências do Privacy by Design e do Privacy by Default — que tornaram-se mandatórios a partir da implementação da General Data Protection Regulation (GPDR), lei que regulamenta a proteção e o uso de dados na União Europeia.
Presentes também na Lei Geral de Proteção de Dados brasileira, ambos os conceitos se referem a tendências mundiais e auxiliam consideravelmente no cumprimento das demais regulamentações de coleta, armazenamento, utilização e descarte das informações pessoais dos clientes.
O documento foi desenvolvido pela Autoridade Norueguesa em conjunto com profissionais de segurança e desenvolvedores de software, tanto do setor público quanto do privado. Continue acompanhando e entenda como fortalecer a privacidade no seu negócio!
Qual é o objetivo do guia da Autoridade Norueguesa?
As diretrizes do documento são voltadas principalmente para desenvolvedores, arquitetos de softwares, gerentes de projetos, profissionais de proteção de dados, profissionais de segurança e quaisquer outros indivíduos que desenvolvam e contribuam para o desenvolvimento de softwares que colham ou processem dados pessoais.
Entretanto, é importante lembrar que o Privacy by Design deve ser uma preocupação da empresa como um todo, assim como acontece com o compliance. Apenas assim é possível transformar a privacidade em um pilar de tudo o que é feito e produzido na organização. Sendo assim, há alguns requisitos funcionais sobre como o software deve ser desenvolvido.
Para começar, o desenvolvimento de softwares deve seguir uma metodologia com atividades-chave para garantir que o produto final seja robusto. Há material disponível para leitura focando em segurança desde a concepção como parte do desenvolvimento do software. Entretanto, o mesmo não acontece com a proteção de dados desde a concepção e por padrão como parte desse desenvolvimento.
Proporcionar esse material para a comunidade de profissionais de tecnologia é, então, um dos motes por trás da criação do guia da Autoridade Norueguesa. O objetivo é fornecer um material abordando desde o planejamento até a engenharia, mostrando como incorporar princípios de proteção de dados, direitos do detentor dos dados e maneiras de obedecer às exigências da GPDR a cada etapa do processo.
O que é o Privacy by Design?
Decisões tomadas de forma automatizada e serviços personalizados tornaram-se parte do nosso dia a dia — e, como aponta o guia, envolvem o processamento em larga escala de dados pessoais. Portanto, usuários esperam que esses serviços sejam seguros e que protejam sua privacidade de forma eficaz.
Nesse contexto, negócios que levam a proteção de dados a sério constroem confiança — ou seja, ter medidas fortes de proteção de dados pode ser uma vantagem competitiva.
Aliados às leis e normas que regulam a proteção de informações dos clientes, os conceitos de Privacy by Design e de Privacy by Default ajudam a garantir que os sistemas de informação utilizados obedecem aos princípios da proteção de dados e protegem os direitos dos indivíduos detentores desses dados.
As diretrizes do Privacy by Design devem ser seguidas desde o início do processo de desenvolvimento de softwares na empresa, assim como ao fazer acordos com fornecedores ou consultorias. Para tanto, a transparência é fundamental.
Quando o assunto é o uso de dados pessoais, transparência envolve providenciar informações sobre quais dados estão sendo processados, por quem, por que e como, além de por quanto tempo eles serão mantidos. Somente assim os indivíduos detentores desses dados podem exercer os seus devidos direitos de privacidade.
Considerar a proteção de dados ao longo de todo o processo de desenvolvimento de programas otimiza os custos e é mais eficaz do que implementar mudanças em um software já existente. Portanto, o comprometimento dos gestores é fundamental para a decisão de aplicar os preceitos de Privacy by Design na empresa.
Como implementar os princípios de Privacy By Design?
Para implementar o Privacy by Design, é importante seguir algumas etapas. A primeira delas é realizar uma avaliação de risco de privacidade, identificando os pontos em que os dados pessoais são coletados, armazenados, processados ou compartilhados. A partir dessa avaliação, é possível identificar os principais riscos e ameaças à privacidade dos dados.
Em seguida, é possível definir as medidas de segurança e privacidade necessárias para mitigar esses riscos. Essas medidas podem incluir o uso de criptografia, autenticação de usuários, controle de acesso, entre outros.
É importante lembrar que as medidas devem ser proporcionais aos riscos identificados e não devem comprometer a usabilidade do produto ou serviço.
Além disso, é importante implementar um processo de verificação da eficácia das medidas de segurança e privacidade implementadas, a fim de garantir que elas estejam funcionando corretamente e que os dados pessoais estejam sendo protegidos adequadamente. Isso pode ser feito por meio de testes de segurança, auditorias internas e externas, e monitoramento constante do sistema.
Outro aspecto importante é a documentação do processo. É necessário documentar todas as etapas do processo de implementação, incluindo a avaliação de risco, as medidas de segurança e privacidade implementadas, a verificação da eficácia e os resultados obtidos. Essa documentação pode ser usada para fins de auditoria e conformidade com leis e regulamentações.
Por fim, é importante treinar os funcionários sobre a importância da privacidade de dados. Em resumo, implementar os princípios de Privacy by Design na tecnologia e nos processos de uma organização requer uma abordagem sistemática e abrangente, que inclui avaliação de risco, medidas de segurança e privacidade, verificação da eficácia, documentação e treinamento dos funcionários.
Ao seguir essas etapas, é possível garantir a privacidade dos dados desde o início do processo de desenvolvimento e oferecer produtos e serviços seguros e confiáveis para os usuários.
Quais são as 7 atividades que levam ao Privacy by Design?
O guia estabelece um conjunto de sete atividades fundamentais para o processo de desenvolver softwares que contenham a proteção de dados desde a sua concepção e por padrão. Tanto o desenvolvimento de programas quanto a proteção de dados são processos contínuos e cada uma dessas atividades é uma peça em um quebra-cabeça.
São elas:
- treinamento;
- exigências;
- design;
- codificação;
- testes;
- lançamento;
- manutenção.
O guia — e, consequentemente, este post — descreve às sete atividades do processo e inclui recomendações da Autoridade Norueguesa sobre como implementá-las e sobre quais são as medidas mais importantes para garantir que sua empresa está adequadamente seguindo o Privacy by Design e o Privacy by Default.
Porém, as metodologias implementadas são fortemente influenciadas pelo leque de produtos e serviços disponibilizados para o cliente, assim como pelo setor de atuação, pela cultura de segurança do negócio e pelo tipo de software que está sendo desenvolvido. Sendo assim, cabe a cada organização avaliar e decidir quais processos, atividades e áreas seria mais interessante priorizar.
Etapa 1: Treinamento
Durante essa atividade, determinam-se os tipos específicos de treinamento a serem dados. A etapa, que deve atingir tanto os colaboradores quanto os gestores, é importante para garantir que todos na organização compreendem a necessidade da proteção e segurança de dados e os riscos associados a isso.
Os colaboradores devem entender quais requisitos são aplicáveis, no que eles devem ficar de olho e quais ferramentas podem ser usadas para converter seu conhecimento em proteção de dados e segurança da informação em software que salvaguarde isso.
A equipe ainda precisa ser informada sobre quais metodologias e rotinas seguir. Cabe à própria organização montar um plano de treinamentos, decidir o que é relevante e quais tipos de treinamento podem ser necessários para algum colaborador em específico.
Quais exigências cabem à organização?
É interessante que tanto os requisitos internos quanto externos sejam assunto de treinamentos para os colaboradores.
Os requisitos internos referem-se a:
- proteção de dados;
- segurança da informação;
- controle interno;
- gestão de recursos;
- análise de riscos;
- exigências referentes a documentação.
Já os requisitos externos dizem respeito a:
- leis e regulamentações de proteção de dados;
- regulamentações específicas para o setor em que a empresa atua;
- a importância dos princípios da proteção de dados;
- direitos dos indivíduos detentores dos dados.
Como fazer isso na prática?
Para começar, estabeleça uma metodologia de desenvolvimento a ser seguida pelos responsáveis pela concepção e realização de softwares. Se forem programas que processam dados pessoais, a metodologia deve incluir privacidade e segurança desde a concepção e por padrão.
Dois exemplos de frameworks de desenvolvimento que têm a segurança como algo intrínseco são o Microsoft Security Development Lifecycle (SDL) e os projetos da OWASP Flagship.
Além disso, prepare um panorama sobre as ferramentas, padrões e melhores práticas a serem usadas durante o desenvolvimento de um software. Os colaboradores devem receber treinamentos quanto a como, quando e por que usar esses elementos.
Confira alguns exemplos elencados pela Autoridade Norueguesa de ferramentas para demandas como testes de segurança, configuração de requisitos de segurança, análises e modelos de riscos:
- OWASP Application Security Verification Standard Project (OWASP ASVS);
- OWASP Top 10;
- OWASP Testing Project;
- ISO27k information security;
- Microsoft SDL.
O guia ainda apresenta um exemplo de checklist de quais atividades devem ser incluídas nos treinamentos para os seus funcionários. Clique aqui e confira.
Etapa 2: Requisitos
A etapa seguinte aborda os requisitos de configuração para a proteção de dados e a segurança da informação. Essas exigências devem refletir a necessidade para tais cuidado e ser incluídas como parte do projeto.
Quando os requisitos para a proteção e segurança dos dados, os níveis de tolerância, os impactos da proteção de dados e os riscos são detectados com antecedência, o time de desenvolvimento já saberá quais exigências precisam obedecer, portanto, podem mitigar as ameaças associadas à proteção de dados e à segurança da informação ao longo de todo o processo do software.
Quais são as exigências para a proteção de dados?
Para estabelecer os requisitos corretos, é importante saber quais categorias de dados pessoais serão processados pelo software, a quais conclusões pode-se chegar a partir deles sobre os indivíduos, quem é o usuário e o dono das informações, quem será definido como o controlador dos dados e, se aplicável, quem processa ou armazena esses dados pessoais.
Isso é necessário para determinar quais leis, regras, diretrizes e códigos de conduta são aplicáveis ao software sendo desenvolvido e para determinar quais requisitos devem ser estabelecidos para o programa. Portanto, é responsabilidade do negócio analisar quais exigências encaixam-se em seus softwares, de acordo com o setor de atuação e o contexto de uso do programa.
Organize esses requisitos em uma checklist, para que os desenvolvedores possam integrá-la ao planejamento do projeto e monitorá-la ao longo de todo o processo.
Obedeça aos princípios de proteção de dados
O requerimento mais importante para um software embutido com proteção de dados desde a concepção é o cumprimento dos princípios referentes a isso. Portanto, o processo deve ser legal, justo e transparente e, no que se refere a dados pessoais, precisa ser desenvolvido com propósitos específicos, explícitos e legítimos — o que inclui somente coletar as informações necessárias para que o software opere.
A Autoridade Norueguesa entende por “necessária” o fato de que é preciso avaliar a quantidade de dados pessoais coletados, a extensão de seu processamento, o período em que ficarão armazenadas e a sua acessibilidade. Considere também o nível de detalhamento das informações exigidas, se rotinas automatizadas de eliminação podem ser implementadas, onde os dados ficarão armazenados e quem terá acesso a eles.
Priorize a concisão das informações e proteja os dados
Para garantir a proteção dos direitos do indivíduo detentor dos dados, é fundamental priorizar a clareza e a concisão das informações sobre como os dados pessoais serão usados. O software deve facilitar que o cliente exerça seus direitos, como acesso, informação, retificação, restrição e portabilidade dos dados.
Isso pode ser resolvido, por exemplo, através de um portal no qual o usuário possa fazer login e acessar um panorama dos dados registrados, informações sobre direitos do usuário e um formulário de ajuda para casos em que ele deseje fazer objeções ou retificações.
A empresa deve garantir a proteção e a segurança dos dados pessoais durante a coleta, o armazenamento, a alteração, a visualização, a comunicação e a eliminação. Criptografia e controles de acesso são algumas das maneiras de alcançar isso.
Os requisitos de segurança para cada software em específico são determinados através da identificação dos riscos aos quais o programa pode ser exposto. A Autoridade Norueguesa sugere seguir as diretrizes dos seguintes documentos:
Defina os riscos de tolerância ao risco
A análise de riscos diz respeito à identificação das possíveis consequências de diferentes incidentes e cenários, além de avaliar o quão provável ou fácil é que um incidente indesejado aconteça.
Então, a gestão da empresa determina o nível de risco que o negócio está disposto a correr em diferentes cenários. Isso é chamado tolerância ao risco e serve como guia na decisão de quais medidas ou recursos serão implementados para que o software não exceda o nível de risco definido como aceitável.
Em termos de segurança, o nível de tolerância é definido individualmente para diferentes cenários, como alteração acidental ou divulgação não autorizada de dados pessoais, ou falta de acesso de tal forma que pudesse impactar significativamente na vida, ou na saúde do indivíduo.
O mesmo acontece em relação à proteção dos dados. Aqui, cenários que podem ser analisados incluem, por exemplo, perda do controle sobre seus próprios dados pessoais por parte do indivíduo, discriminação decorrida do software ou identificação de uma pessoa a partir de dados anônimos.
Alguns cenários de segurança e de proteção de dados terão tolerância zero ao risco, enquanto a empresa pode considerar aceitável correr um certo nível de risco em outros.
Faça uma análise de risco em segurança
A análise de risco começa com o mapeamento dos dados pessoais que devem ser assegurados. Identifiquei qual poderia ser o interesse nessas informações e quais pontos de ataque poderiam ser usados para consegui-las.
Em seguida, faça uma avaliação para determinar quais dados estão vulneráveis a quais riscos. As suas diretrizes de segurança da informação podem ajudar a detectá-las, assim como a identificar os requisitos que devem ser estabelecidos para proteger os dados.
O próximo passo é reavaliar a análise de risco diante dos níveis de tolerância em segurança. Se o nível de risco for mais alto do que o nível de tolerância estabelecido previamente, medidas devem ser estabelecidas para mitigar as ameaças. Também é necessário determinar quem será responsável por tais medidas e estabelecer um prazo para as respectivas implementações.
Faça uma análise do impacto à proteção de dados
Visa avaliar o impacto que um software ou processo operacional previsto pode ter na proteção de informações pessoais, assegurando assim que o programa não infringe nos direitos fundamentais do indivíduo detentor dos dados.
O processamento de dados pessoais deve ser legal, justo e transparente. Uma análise do impacto à proteção de dados é necessária para certos tipos de processamento:
- em casos de avaliação sistemática e extensa de aspectos particulares relacionados a pessoas físicas baseadas em tomadas automatizadas de decisão, incluindo profiling, e em que as decisões possam ter efeitos jurídicos ou de forma similar afetar o indivíduo;
- ao processar dados pessoais sensíveis em larga escala;
- ao monitorar uma área que possa ser publicamente acessada de maneira sistemática e em larga escala.
Em caso de dúvidas sobre se deve-se ou não fazer a análise do impacto à proteção de dados, a Autoridade Norueguesa recomenda seguir em frente com a avaliação. A análise precisa conter, pelo menos:
- descrição sistemática do processo operacional planejado e os motivos para o processamento, incluindo, quando aplicável, o legítimo interesse buscado pelo controlador;
- uma análise da necessidade do processamento e de como o planejamento relaciona-se a essas necessidades;
- uma avaliação dos riscos aos direitos e à liberdade dos indivíduos detentores dos dados pessoais;
- o que foi planejado para endereçar os riscos, incluindo salvaguardas, medidas de segurança e mecanismos para garantir a proteção das informações e para comprovar compliance com as regulamentações de proteção de dados, considerando os direitos e o interesse legítimo dos indivíduos.
Confira a checklist recomendada pelo guia para servir de modelo para o estabelecimento dos seus requisitos de segurança e proteção de dados.
Etapa 3: Design
Essa etapa envolve assegurar que os requisitos de proteção de dados e segurança da informação são refletidos no design, ou projeto, do software. As exigências identificadas na atividade referente aos requisitos precisam ser alcançadas e requisitos para o design devem ser definidos.
Nesse sentido, considere a existência de ameaças que podem tentar obter acesso aos dados pessoais. Analise a superfície de ataque para reduzi-la e, além disso, garanta que o software foi modelado e desenhado de forma a resultar em um produto final robusto.
O objetivo da atividade de design de software é que os requisitos de projeto descrevam de forma acurada e facilmente compreensível como as características de cada peça do programa devem ser desenvolvida, incluindo como as funcionalidades podem ser implementadas e distribuídas de maneira segura.
Considere, por exemplo, um sistema de gestão de identificação e acesso em que o usuário possa ver ao que ele consentiu e quais são suas configurações de segurança, gerenciar suas senhas e compreender como o processo de login funciona.
Seguindo as recomendações da European Union Agency for Network and Information Security (ENISA), a Autoridade Norueguesa divide os requisitos de design em duas categorias: requisitos orientados a dados e requisitos orientados a processos.
Requisitos de design orientados a dados
Minimize e limite
A quantidade de informações pessoais coletadas e processadas, precisa ser limitada àquelas que são legais e estritamente necessárias nas diretrizes de Privacy by Design. Os dados devem ser deletados quando seu armazenamento não for mais exigido para seus propósitos. Uma regra de ouro a seguir é: “Selecione antes de coletar”.
Esconda e proteja
Dados pessoais e as formas com que elas se interseccionam não devem ser comunicadas, processadas ou armazenadas diretamente à vista. Ao esconder dados pessoais facilmente identificáveis, o risco de abuso e o escopo de acidentes em potencial são significativamente reduzidos. Exemplos para fazer isso incluem pseudonimização, criptografia e agregação dos dados.
Separe
Ao separar o processamento ou o armazenamento de diversas fontes de dados pessoais que pertencem a um mesmo indivíduo, você diminui as possibilidades de que seja possível criar um perfil completo de um dos seus clientes. De acordo com o seu propósito, as informações podem ser guardadas em bases de dados separadas, por exemplo.
A separação também é uma forma eficaz de limitar os propósitos e impedir que diferentes conjuntos de dados possam ser linkados entre si.
Agregue
Para garantir a proteção dos direitos dos clientes em relação a seus dados pessoais, eles devem ser colhidos e processados com o maior nível de agregação quanto possível. Evite ao máximo o detalhamento de informações particulares nas limitações daquilo que ainda pode ter valor para o seu negócio e faz sentido para os propósitos de coleta e de uso.
Busque, por exemplo, reduzir o nível de detalhamento e sensibilidade dos dados pessoais, removendo informações desnecessárias ou excessivas sempre que possível. Para ilustrar tendências e valores gerais, você pode combinar estatísticas sobre grandes números de pessoas sem identificar indivíduos.
Tenha a proteção de dados como padrão
Todas as configurações devem vir, por padrão, em suas formas mais privacy-friendly. Assim, o usuário terá que fazer uma escolha consciente se quiser mudar qualquer configuração de forma a reduzir sua privacidade.
Requisitos de design orientados a projetos
Informe
O programa deve ser desenhado e configurado de forma que o cliente tenha informações suficientes sobre como o software funciona e sobre como seus dados pessoais são processados. Ao montar um perfil ou automatizar a tomada de decisões a partir de dados pessoais, o indivíduo precisa saber como isso é feito.
É importante lembrar-se dos requisitos especiais para softwares voltados para crianças. O programa deve, por exemplo, utilizar linguagem simples e clara para prover informações sobre para que as informações pessoais serão usadas. Utilize imagens, ícones, símbolos, vídeos, animações e recursos sonoros para facilitar a compreensão.
Controle
O indivíduo detentor dos dados tem os direitos de controle sobre suas próprias informações pessoais. Isso inclui o direito de acessar, atualizar e/ou deletar esses dados. O design do programa deve garantir que o cliente possa exercer esses direitos o mais facilmente possível.
Um exemplo disso é a criação de um menu ou de uma página específica no software em que o usuário possa conceder e revogar consentimento, assim como visualizar, bloquear e deletar seus dados pessoais.
Reinforce
Desenhe o software de forma a facilitar a documentação sobre como ele protege os dados pessoais dos usuários. Essa documentação deve incluir tudo o que for referente a responsabilização, obediência a regulamentações, auditorias, uso de inteligência artificial, profiling e tomada automatizada de decisões.
Descreva, por exemplo, como o software assegura a possibilidade de o usuário exercer seus direitos, o quão ele está em compliance com as regulamentações de proteção de dados e quais de suas medidas técnicas protegem as informações particulares — aqui, você pode incluir controle de acesso e criptografia.
Demonstre
O controlador precisa ser capaz de documentar os processos de compliance relacionados à proteção de dados e à segurança do processamento. O programa deve ser desenhado e desenvolvido de forma que o responsável consiga documentar e demonstrar como os requisitos das respectivas regulamentações foram implementados.
Exemplos dessa prática incluem documentação que demonstre que o software foi desenvolvido usando uma metodologia que assegura a proteção de dados desde a concepção e a segurança da informação, relatórios de auditorias de segurança, verificações de vulnerabilidades, testes de segurança e relatórios sobre exercícios de invasão de dados.
Reduza as oportunidades de exploração das vulnerabilidades
Analise a superfície de ataque no design do software para reduzir vetores de ataque e oportunidades de explorar pontos fracos e vulnerabilidades. Em uma revisão do design, tanto a comunicação quanto o fluxo de data, o input e output de informações precisam ser avaliados pelo ponto de vista de um invasor.
Você ainda deve investigar se o mesmo tipo de informação está sendo coletado ou armazenado em espaços múltiplos e verificar se essa funcionalidade pode ser simplificada. Ao manter o design simples e eliminar recursos e complexidades desnecessárias, a possibilidade de erros acontecerem é reduzida.
Para esse tipo de análise, utilize as avaliações tanto dos riscos de segurança quanto dos impactos à proteção de dados, organizadas na atividade dos requisitos. Se uma vulnerabilidade for encontrada, medidas para mitigá-la devem ser implementadas visando o alcance dos riscos aceitáveis de proteção e segurança dos dados.
Essa etapa envolve também providenciar uma modelagem de riscos, onde analisam-se os componentes, pontos de acesso, fluxo de dados e fluxos de processo no programa. O objetivo é avaliar como alguém poderia usar o software de forma errada em diferentes cenários.
Revise cada um dos cenários e veja como o design pode ser aprimorado de modo a evitar quaisquer das ameaças identificadas. Para fazer o follow-up, faça uma avaliação de risco de todas as vulnerabilidades que possam ter permanecido e devem ser mitigadas por meio de outras medidas.
Finalize a atividade de design acompanhando a checklist recomendada pelo guia!
Etapa 4: Codificação
A próxima etapa permite que os desenvolvedores escrevam códigos seguros para implementar os requisitos de proteção e segurança de dados.
É fundamental que a empresa escolha uma metodologia confiável tanto para a codificação quanto para permitir que os desenvolvedores detectem e removam vulnerabilidades do código. Ferramentas automáticas de análise de código devem ser introduzidas e a organização precisa estabelecer processos estáticos para a análise e a revisão dos códigos.
Utilize ferramentas e frameworks previamente aprovados
Para garantir a consistência das práticas, uma lista das ferramentas, processos e frameworks previamente aprovados e permitidos para o desenvolvimento de softwares deve ser divulgada e devidamente documentada.
Esclareça também as funcionalidades de cada uma das ferramentas. Isso envolve descrever as próprias ferramentas e seus respectivos recursos de segurança que possam ajudar a automatizar e a reforçar os procedimentos de segurança na codificação.
Também inclua na lista quais componentes de apoio ou terceirizados e quais ferramentas são permitidas durante o desenvolvimento — elas precisam passar por uma análise de risco e vulnerabilidade. Utilize somente as versões mais recentes das ferramentas aprovadas, de modo a tirar o máximo proveito das oportunidades geradas por novos recursos de segurança.
Atualmente, programas são compostos por diversos serviços colaborativos. Isso significa que um número significativamente maior de linguagens, bibliotecas e frameworks de programação são utilizados no desenvolvimento de softwares do que antigamente. Código, bibliotecas e infraestruturas são frequentemente combinados em containers mais estáticos.
É por isso que é tão importante implementar verificações regulares de vulnerabilidade em todas as partes do código. Exemplos de tais ferramentas podem ser encontrado no GitHub e no Docker Security Scanning.
Desabilite funções e módulos não-seguros
Muitas funções, APIs, bibliotecas de terceiros e módulos podem não ser seguros de usar de acordo com seus níveis de ameaça. Conduza uma análise de todos esses elementos. Aqueles que forem identificados como sendo inseguros devem ser proibidos. Já os vistos como ultrapassados ou que contenham vulnerabilidades podem ser atualizados.
A partir disso, construa uma lista de elementos proibidos e confira o código de acordo com ela, substituindo os recursos banidos por alternativas mais seguras. Faça isso através de ferramentas de escaneamento de código. Além disso, o código deve ser conferido a fim de desativar quaisquer instâncias de rastreamento ou coleta desnecessária de dados pessoais.
Faça uma análise e revisão estáticas do código
Conduza-as com regularidade. A análise estática do código garante que as diretrizes para a sua segurança estão sendo seguidas e podem ser medidas, o que permite assegurar que os controles estão funcionando.
Utilize ferramentas para automatizar a análise e a revisão sempre que possível. Mesmo assim, o código também deve ser revisado manualmente, garantindo assim que quaisquer vulnerabilidades que poderiam levar a uso impróprio ou a um vazamento de dados pessoais sejam detectadas.
Agora, fique com a checklist para verificar os conteúdos da sua codificação.
Etapa 5: Testes
Os responsáveis pelos testes checam se todos os requisitos para a proteção de dados e a segurança da informação previamente definidos foram implementados como planejado de acordo com as diretrizes de Privacy by Design.
O próprio software também deve ser testado em busca de vulnerabilidades. Isso é feito através de testes dinâmicos, testes de fuzzing e testes de penetração. É importante revisar a superfície de ataque para verificar que os vetores de ataques descobertos na atividade do design e novos vetores potencialmente introduzidos na codificação serão solucionados.
Teste de implementação dos requisitos de proteção e segurança de dados
Implemente testes para verificar se esses dois pontos imprescindíveis foram implementados corretamente ao longo dos processos de design e de codificação e no software propriamente dito.
A checklist preparada durante a etapa dos requisitos pode ser usada para verificar que todos os componentes exigidos estão incluídos. Para os testes, utilize dados pessoais fictícios.
Teste de segurança
Envolve testar o software de forma completa para descobrir vulnerabilidades e garantir que o código assegura a segurança e a proteção dos dados adequadamente. O guia recomenda que sejam estabelecidos procedimentos para a execução automático do teste, a ser rodado a cada vez que um software for construído.
Testagem dinâmica
Aqui, rode um código utilizando ferramentas ou revisões manuais para analisar como o software se comporta em relação às diferentes permissões de usuário e em casos de falhas críticas de segurança.
A testagem dinâmica garante que os usuários terão acesso somente às informações e funcionalidades para as quais eles têm autorização. É importante verificar que quaisquer tentativas de acessar informações não-autorizadas sejam registradas como violações de segurança.
Teste de fuzzing
Esse tipo de teste é conduzido ao induzir o software intencionalmente ao erro. Isso pode ser feito através de ferramentas que enviam dados aleatórios, mal-formados e/ou incorretos a todos os possíveis campos do programa.
Se o software conta com interfaces múltiplas, esse esforço deve ser realizado para cada uma delas. Utilize ferramentas que possam avaliar o resultado final e aplicar contextos de segurança, como web proxies capazes de escanear seu próprio software atrás de vulnerabilidades.
Teste de penetração e análise de vulnerabilidade
A fim de detectar vulnerabilidades, faça testes de penetração ou análises de vulnerabilidade antes do lançamento do software e em intervalos regulares. Tais testes de segurança visam encontrar, explorar e detectar vulnerabilidades.
Faça uma rotação frequente dos responsáveis pelos testes, evitando assim a situação frequente de deixar o conhecimento adquirido muito dependente de um colaborador ou de uma equipe em específico.
Como modelar as ameaças e revisar a superfície de segurança?
Já que o software pode mostrar-se diferente das especificações técnicas e funcionais definidas durante as atividades de requisitos e de design, a modelagem de ameaças e a superfície de ataque devem ser revisadas quando o programa estiver pronto para ser lançado.
Nessa revisão, verifique se algum vetor de ataque implementado durante a codificação foi devidamente identificado e gerido e, também, que a modelagem de ameaças está sendo revisada de acordo com o software mais recentemente desenvolvido.
Como os requisitos podem ter mudado ao longo do processo, impactos de proteção de dados devem ser revisados novamente. Verifique, por exemplo, que todas as informações pessoais têm um embasamento legal para seu processamento, são necessárias e estão adequadamente protegidas.
Antes de encerrar sua etapa de testes, verifique esta checklist!
Etapa 6: Lançamento
Preparar o software para chegar ao mercado, isso inclui planejar como a organização pode lidar com incidentes que possam surgir após o lançamento de forma eficaz, assim como os procedimentos para atualizar o software quando necessário.
Antes do lançamento, não deixe de fazer uma última revisão completa de segurança.
Se softwares são um produto recorrente da sua empresa, um plano de resposta a incidentes deve ser estabelecido antes do lançamento inicial, enquanto revisões de segurança podem ser realizadas antes de cada apresentação de um novo produto ao mercado.
Plano de resposta a incidentes
Estabeleça um plano para gerenciar incidentes relacionados ao software, contendo recursos e um ponto de contato ou centro de respostas que possa resolver essas situações. O plano também deve incluir informações relevantes sobre suporte, escalabilidade e um panorama sobre como gerenciar incidentes herdados de códigos de terceiros.
Defina o tempo de resposta de acordo com a importância do software. Programas relacionados a atendimentos emergenciais no setor de saúde, por exemplo, exigem suporte 24 horas, todos os dias.
Também é importante pensar em quais canais de comunicação serão usados para reportar incidentes e nas maneiras de eles garantirem a segurança e a privacidade dos conteúdos presentes nas mensagens.
O plano ainda precisa definir o que caracteriza um incidente e qual é o seu ciclo de vida. Isso inclui, por exemplo, detecção e análise, assim como as maneiras de reportar, lidar com e normalizar esses incidentes.
O próximo ponto que deve fazer parte do plano envolve os procedimentos para avaliar respostas de incidentes. Descreva as consequências que essas experiências possam ter tido no processo de desenvolvimento, para o negócio e para aqueles afetados, assim como estratégias para corrigir o software e para definir quais problemas exigem atualizações.
Revisão completa de segurança
Todos os requisitos e análises realizados durante o processo de desenvolvimento devem ser revisados novamente. O ideal é que isso seja feito por um grupo multidisciplinar de especialistas, garantindo assim uma revisão completa de diferentes cenários e consequências, e a implementação das melhores medidas possíveis.
Antes de aprovar o software para lançamento, certifique-se de que todos os requisitos de proteção e segurança de dados foram implementados e estão funcionando como deveriam. Defina quem é o profissional autorizado a declarar a aprovação final do software para lançamento.
Todos os dados e documentações relevantes ao longo de todo o processo de desenvolvimento devem ser arquivados. Isso é importante para as tarefas de suporte, além de ajudar a reduzir os custos a longo prazo de gestão e manutenção do software.
Esta checklist é um bom ponto de partida quanto ao que analisar durante o processo de revisão para lançamento.
Etapa 7: Manutenção
O software foi lançado, mas os processos de Privacy by Design não se encerram. Agora, vem a atividade de manutenção, cujo elemento mais importante é que a organização siga o plano de resposta a incidentes, elaborado durante a etapa anterior.
É imprescindível que a empresa esteja preparada para lidar com incidentes, violações de segurança e ataques que possam resultar em quebras na confidencialidade, na integridade ou na disponibilidade relacionada a dados pessoais. Então, tenha um centro de atendimento preparado para tais situações e que também se responsabilize por fornecer atualizações, diretrizes e informações aos usuários do programa e aos detentores dos dados.
Lidando com incidentes e violações aos dados
Quando um incidente crítico acontecer, é muito importante manter a calma e analisar a situação como um todo. Entretanto, como a Autoridade Norueguesa destaca, a natureza do incidente pode resultar em mudanças no plano de Privacy by Design sendo executado.
A equipe de resposta a incidentes deve saber quem contactar quando for necessário e quem é responsável por construir, testar e instalar atualizações. Esses funcionários também precisam saber quais são as prioridades dentro de cada situação e tudo o que eles podem ou devem fazer em caso de uma crise. Para tanto, organize treinamentos para o time de forma regular.
Além disso, encoraje os usuários do software a reportarem erros, vulnerabilidades e violações aos dados, para que o programa possa ser aprimorado continuamente.
Manutenção, suporte e operação do software
Aqui, siga os procedimentos previamente estabelecidos com as diretrizes de Privacy by Design, incluindo aqueles para a contínua salvaguarda da proteção e da segurança de dados. Isso envolve, por exemplo, testes regulares de segurança, análises de vulnerabilidade e testes da penetração do programa, da infraestrutura e da rede.
Entre os preceitos, inclua correção de bugs, aprimoramentos de performance e atualizações tanto para o software quanto para seus componentes de terceiros. Realize auditorias internas e externas para verificar se tudo está em compliance com as devidas regulamentações.
Veja o checklist recomendado pela Autoridade Norueguesa para a manutenção.
Gostou de entender passo a passo como implementar o Privacy by Design nos projetos de software e de tecnologia da sua empresa? Então, aproveite para conhecer também os 7 princípios do Privacy by Design, estabelecidos pela Dra. Ann Cavoukian em 2009.
Para trazer mais inovação à sua empresa com segurança, privacidade e eficácia, conte com as soluções da idwall. Entre em contato com um de nossos especialistas pelo formulário abaixo!