O Guia Essencial de Segurança de Dados para Gestores de Produto

Já ouviu falar do Code Spaces? Era um repositório de código-fonte semelhante ao GitHub.

Bem, provavelmente nunca ouviu falar dele porque, apesar de ser um produto promissor, desapareceu quase instantaneamente em junho de 2014, após uma enorme falha de segurança. A falha fez com que perdessem todos os dados dos clientes, obrigando-os a cessar a sua atividade.

Depois desse incidente, todos no mundo digital, incluindo os gestores de produto, aprenderam uma lição que nunca deve ser esquecida—OS PRODUTOS TÊM DE SER SEGUROS.

Neste guia, vou apresentar-lhe o mundo da segurança dos produtos e ajudá-lo a ter a segurança em mente ao gerir os seus produtos.

Porque Devem os Gestores de Produto Preocupar-se com a Segurança dos Dados

Em teoria, o seu dia a dia de gestão de produto deveria concentrar-se apenas na retenção, nas entrevistas com utilizadores e noutras tarefas não técnicas, sem preocupações com a segurança.

No entanto, vivemos num mundo de pessoas mal-intencionadas que teriam todo o gosto em roubar os seus dados (para os vender mais tarde em algum lugar), encriptá-los, exigir um resgate por eles (ou seja, ransomware) ou simplesmente causar danos pelo prazer de causar danos.

Por isso, para além da ativação e da retenção, também deve preocupar-se com o enorme risco empresarial que uma segurança negligente pode representar para o seu produto. Uma falha de segurança suficientemente grave prejudicará tanto a sua reputação que todos os anos de trabalho árduo das suas equipas de marketing, desenvolvimento de produto e vendas podem desaparecer num único dia.

Além disso, acabará por enfrentar ações judiciais por parte dos seus parceiros e clientes cujos dados não conseguiu proteger.

Por isso, na minha opinião, é da máxima importância que os gestores de produto estejam “conscientes da segurança” ao criar e desenvolver os seus produtos.

As 4 Lacunas de Segurança Mais Comuns no Desenvolvimento de Produtos

Enquanto gestor de produto, não precisa realmente de ter conhecimentos aprofundados sobre os métodos de pirataria informática mais recentes e as formas de se proteger contra eles. Isso é algo que as suas equipas de segurança e engenharia devem implementar e gerir.

No entanto, precisa de ter uma compreensão técnica básica de como funcionam alguns dos problemas de segurança mais comuns e de como os piratas informáticos podem explorá-los. Isto tornará o seu processo de tomada de decisões mais “consciente da segurança”.

Vamos analisar em conjunto quatro dessas lacunas de segurança e compreender do que se trata.

1. Injeção de SQL

Quando era um jovem gestor de produto, decidi aprender um pouco de programação e criei um pequeno (e horrível) código PHP que servia como back-end de um formulário de contacto de um sítio web. Recebia uma mensagem, guardava-a na base de dados e compunha um e-mail dirigido a mim com o seu conteúdo.

Quando mostrei isto a um amigo programador, além de mal conseguir conter o divertimento (o meu código era simplesmente muito mau), perguntou-me se tinha higienizado as entradas. Como deve ter adivinhado, não fazia ideia do que ele queria dizer, e explicou-me que as minhas bases de dados estavam expostas a injeção de SQL por não haver higienização das entradas.

A injeção de SQL é o processo através do qual o pirata informático escreve código SQL especial em vez de texto nas suas entradas, acabando por executar esse código no seu back-end e obtendo acesso não autorizado ao seu produto ou roubando informações das suas bases de dados.

Imagine que o LinkedIn utilizava esta consulta SQL para verificar a sua palavra-passe ao iniciar sessão (aviso: eles utilizam definitivamente algo mais inteligente do que o SQL apresentado aqui).

Se, teoricamente, as entradas da página de início de sessão não fossem higienizadas, poderia escrever ' OR '1'='1 nos campos de nome de utilizador e palavra-passe e clicar em Iniciar sessão.

Neste caso, o back-end adicionaria o seu ' OR '1'='1 à consulta SQL, que se tornaria algo semelhante a isto.

Esta consulta devolverá o valor “verdadeiro.” Isso significa que conseguiria iniciar sessão no LinkedIn sem ter um nome de utilizador e uma palavra-passe verdadeiros.

Como já mencionei, pode evitar este problema higienizando as suas entradas. Neste contexto, a higienização significa garantir que tudo o que escreve nos campos de entrada é tratado como texto normal, mesmo que escreva código ou uma consulta SQL.

Com as entradas higienizadas, o LinkedIn tentará procurar na base de dados um utilizador chamado ' OR '1'='1, em vez de executar o código. Acabará por não o encontrar e apresentar-lhe-á um erro a indicar que não existe tal pessoa no LinkedIn.

Nota

É claro que o exemplo acima é uma simplificação e os ciberataques reais são muito mais complexos. Mas, se quiser aprofundar os aspetos técnicos e saber mais sobre estes ataques, recomendo que consulte o livro de Justin Clarke-Salt, Ataques de injeção SQL e defesa.

Proteger-se contra injeções SQL é um dos passos básicos que pode dar para manter os dados dos seus clientes seguros e evitar fugas de dados prejudiciais e acessos não autorizados.

2. Scripting entre sites (XSS)

O XSS é outra forma comum de os hackers manipularem o seu produto e agirem de forma maliciosa sobre ele. Para ter uma ideia de quão comum é o XSS, um relatório da Positive Technologies estima que cerca de 90% de todas as aplicações Web existentes são vulneráveis a este tipo de ataque.

Então, em que consiste? O XSS é um pouco semelhante à injeção SQL no que diz respeito à manipulação do sistema pelos hackers para executar código que não deveria ser executado. No entanto, neste caso, o código malicioso executado não está no back-end/bases de dados do sistema, mas sim no front-end.

Um dos exemplos engraçados e inofensivos de XSS é o emoji de coração que republicava automaticamente no Twitter (sim, continuo a chamar-lhe Twitter — tentem contrariar-me). É engraçado porque ninguém esperava que o Twitter cometesse um erro tão grave, e é inofensivo porque a única coisa que fazia era republicar-se a si próprio.

Este ataque consistia apenas num tweet simples que continha o texto seguinte.

Como é evidente na imagem, isto não é texto simples, mas sim um trecho de código (JavaScript com jQuery, para ser preciso), acompanhado por um emoji de coração no final.

Ora, antes de o Twitter corrigir esta falha de segurança, se abrisse este tweet no seu navegador, o motor do navegador reconheceria o conteúdo como código válido, ocultá-lo-ia do utilizador e executá-lo-ia. Assim, em vez das duas linhas de código, veria apenas um tweet com um emoji de coração.

Quando o código era executado, percorria o HTML da página, encontrava automaticamente o botão de republicação no ecrã e clicava nele.

Isto significava que qualquer pessoa que visse este tweet o republicava automaticamente, o que levou a que uma enorme parte dos utilizadores do Twitter ficasse infetada.

Agora, imagine que não se tratava de um tweet autorreplicável, mas de algo mais prejudicial, como um script que recolhesse informações confidenciais do seu ecrã e as enviasse para o hacker. Em alternativa, um código malicioso no seu navegador poderia assumir o controlo da aplicação Web do seu banco e começar a transferir dinheiro da sua conta.

Percebe o meu ponto de vista — o XSS continua a ser extremamente perigoso, apesar de não conseguir aceder aos seus servidores e bases de dados.

Mas o que é que isto tem que ver consigo enquanto gestor de produto? Bem, pode acabar por pedir aos seus engenheiros funcionalidades e integrações interessantes, como permitir que o seu site veja o conteúdo de outros separadores do navegador do utilizador e faça algo interessante com essas informações.

Se o fizer e a sua equipa se recusar a criar uma funcionalidade desse tipo, não fique confuso nem triste, porque aquilo que está a pedir é essencialmente um ataque XSS a outros sites.

O XSS é uma área fascinante da cibersegurança e existem muitos livros excelentes sobre o assunto que posso recomendar. O meu favorito é Ataques XSS, de Seth Fogie.

3. APIs inseguras

As interfaces de programação de aplicações (também conhecidas como APIs) são o meio de comunicação entre o seu servidor e o navegador dos utilizadores ou a sua aplicação no dispositivo móvel/computador de secretária.

Sempre que é necessário obter, armazenar ou processar dados no seu servidor, o navegador/aplicação (também conhecidos como "clientes") envia um pedido ao servidor com as informações necessárias. Em seguida, o servidor executa o trabalho e devolve a resposta.

Por exemplo, ao iniciar sessão, os clientes enviam o seu nome de utilizador e palavra-passe e pedem ao servidor que os autentique. Assim que o servidor conclui o pedido, envia uma mensagem de “êxito”, juntamente com o conteúdo da página que o utilizador deve ver quando o início de sessão estiver concluído.

Como as APIs trabalham com dados dos utilizadores, também estão sujeitas a vulnerabilidades de segurança que podem conduzir à manipulação maliciosa de dados (por exemplo, pedir ao servidor que efetue uma transferência de dinheiro em nome do utilizador) ou a uma violação de dados (por exemplo, pedir ao servidor que revele os registos médicos do utilizador).

Os tipos mais comuns de vulnerabilidades das APIs são:

Sem autenticação: neste caso, a API não exige que o cliente comprove a sua identidade antes de fornecer informações confidenciais. Para ter uma ideia de como isto funciona, imagine que alguém vai ao banco e pede para levantar dinheiro da conta de Mark Zuckerberg, e o funcionário do balcão responde simplesmente: "Claro, quanto?"

Sem limitação de taxa: Aqui, as APIs não deixam de processar pedidos, mesmo quando são simplesmente demasiados — muito mais do que deveriam ser — o que leva o servidor a ficar sobrecarregado e a deixar de funcionar. Este tipo de fluxo excessivo de pedidos acontece quando alguém tenta realizar um ataque DDoS aos seus servidores.

Exposição excessiva de dados: Isto acontece quando as respostas da sua API contêm informações que não quer realmente que as pessoas possam consultar. Por exemplo, ao enviar dinheiro a alguém através da banca online, imaginemos que a notificação da API que confirma o sucesso da transação também contém o saldo da conta do destinatário, algo que definitivamente não deveria conseguir ver.

As soluções para estas três vulnerabilidades são relativamente óbvias. Peça autenticação ao disponibilizar dados sensíveis, adicione limitação de taxa e certifique-se de que não está a disponibilizar dados que não deveriam estar presentes.

Se quiser aprofundar um pouco mais a segurança das APIs, pode consultar o livro de Neil Madden sobre o tema.

4. Ausência de encriptação

O meu responsável pela segurança gosta de repetir constantemente que uma estratégia de cibersegurança bem executada num produto é semelhante a uma cebola — consiste em várias camadas de segurança aplicadas a diferentes partes do produto.

Tudo o que discutimos até agora foram riscos de segurança na camada superficial, quando o utilizador não consegue aceder aos seus servidores ou bases de dados e tenta atacar “a partir da superfície”.

No entanto, se um pirata informático conseguir, de alguma forma, obter acesso total aos seus servidores (ultrapassando a primeira camada), deve continuar a ter medidas implementadas para proteger as suas bases de dados contra acessos não autorizados — mantendo também seguras as suas camadas internas.

Uma das melhores formas de proteger os seus dados, neste caso, é encriptá-los. Isto significa que, mesmo que alguém aceda às suas bases de dados e transfira esses dados, eles serão um conjunto de caracteres incompreensíveis para essa pessoa, uma vez que estão encriptados.

Apenas a empresa ou o utilizador — as duas partes que possuem a chave de encriptação — conseguiriam desencriptar esses caracteres incompreensíveis e transformá-los em informações úteis. Infelizmente, porém, esquecer-se de encriptar os dados nos servidores é extremamente comum e já provocou inúmeras fugas de dados de grandes dimensões.

Já vi pessoalmente demasiados sites e produtos que arriscaram ao armazenar as palavras-passe dos seus utilizadores em texto simples — algo considerado um pecado mortal no desenvolvimento de software. A melhor prática neste caso consiste em aplicar um algoritmo de hash à palavra-passe, obter uma versão encriptada da mesma (designada por hash) e armazenar essa versão.

A vantagem é que tanto o utilizador como a empresa possuem a chave necessária para reverter o hash para a sua forma de texto simples e utilizar essa palavra-passe para autenticação. Contudo, se um pirata informático aceder à base de dados e transferir o hash, seriam necessários milhões de anos de cálculos para o converter novamente na palavra-passe original sem a chave. (Não estou a brincar, esse é o número real!)

A encriptação é outra área fascinante da cibersegurança que recomendo explorar. Em particular, pode começar por aprender como funciona a criptografia de chave pública, uma vez que é nela que assenta atualmente toda a Internet.

Integrar a segurança das aplicações no ciclo de vida do desenvolvimento de produtos e software

Tendo em mente todas estas vulnerabilidades e boas práticas, vamos concentrar-nos numa pergunta óbvia que poderá ter — como mantenho os meus produtos seguros enquanto gestor de produto?

Pensei que nunca perguntaria! Eis duas boas práticas de segurança importantes que podem ajudar:

Produtos seguros desde a conceção

Esta é uma abordagem ao processo de desenvolvimento que defende que deve ter em conta os requisitos de segurança desde o momento em que começa a criar os seus produtos, para que as medidas de segurança sejam integradas de forma nativa no seu código e na sua arquitetura, em vez de serem adicionadas posteriormente no SDLC.

A última opção é normalmente muito mais dispendiosa e não oferece o mesmo nível de proteção que um software “nativamente” seguro.

Por isso, enquanto gestor de produto, é sua responsabilidade pedir à equipa de desenvolvimento que siga esta abordagem e evitar desvalorizar os itens que ajudam a integrar a segurança no produto.

Auditorias de segurança regulares

A maioria dos produtos que geri era submetida a testes de segurança regulares (normalmente uma vez a cada seis meses ou um ano). Testámos toda a postura de segurança, que incluía:

• Testes de intrusão
• Modelação de ameaças
• Revisão dos controlos de segurança
• Revisão da estratégia de segurança e das funcionalidades de segurança
• Revisão da cadeia de fornecimento e dos fluxos de trabalho de automatização
• Análise do código (incluindo o código de fonte aberta que utilizámos e o código obtido através de parcerias com terceiros)
• Criação do roteiro de segurança e de métricas
• Avaliação de riscos
• ...e muito mais!

Isto é importante porque o seu produto está em constante evolução e pode quebrar acidentalmente a segurança do seu software ao adicionar algo novo. As auditorias regulares identificarão rapidamente estes problemas e permitirão corrigi-los e validá-los — antes que alguém mal-intencionado os descubra primeiro.

Enquanto gestor de produto, o seu trabalho consiste em reservar tempo e dar prioridade a estas auditorias e às limpezas do código que se seguem.

Confie na sua equipa de segurança

Independentemente da funcionalidade que planeia desenvolver e do plano de ação que tem para atingir os seus objetivos de crescimento, certifique-se sempre de que submete as suas ideias à apreciação da sua equipa de segurança.

E ouça — pode parecer-lhe que a equipa de segurança quer tornar o seu produto excessivamente seguro. No entanto, na maioria das vezes, se não gostarem da sua ideia, deverá considerar fazer alterações à mesma. Caso contrário, simplesmente não vale a pena correr o risco.

E, já que estamos a falar em ponderar estas questões, considere também subscrever o nosso boletim informativo para receber diretamente na sua caixa de entrada muitos guias e artigos sobre gestão de produtos!