Community

Segurança para Tech Product Managers: Os Dois Lados da Moeda

Alfredo Torquato

No universo do software, a segurança é um tema extremamente relevante, mas que muitas vezes carece de conteúdo direcionado. Não estamos falando aqui apenas de aspectos relacionados a área de SecInfo, como DevSecOps, BlueTeam, RedTeam ou CTI. Nosso objetivo é trazer essa discussão para a realidade dos produtos. Diante desse cenário, vamos abordar a segurança sob os dois pontos de vista, ou seja, os dois lados da moeda.

Se você é novo por aqui, faz todo sentido você dar uma olhadinha aqui e aqui. São artigos complementares a esse texto e podem te ajudar na melhor absorção. Além disso, o Guilherme amigo de longa data, trabalhou como líder técnico de DevOps e vivia o mundo SecInfo diariamente na Tempest e agora é super especialista em segurança na Housecall Pro. O Guilherme já participou do podcast aqui da @devdelivery e agora veio dar o ar da sua graça aqui nos artigos.

Finalizada as apresentações, bora jogar a moeda pra cima.

Cara ou coroa?

Segundo a matemática, a probabilidade de sair cara ou coroa ao jogarmos uma moeda é de 50% para cada lado. No entanto, experimentos como o realizado pelo pesquisador inglês John Kerrich mostram que essa proporção pode variar. Em 10 mil arremessos da mesma moeda, foram registradas 5.067 caras e 4.933 coroas, ou seja, uma probabilidade de acerto de 50,67% para cara. Assim, podemos dizer que cara tem uma ligeira vantagem e é mais frequente nos resultados.

Parte 1: Cara – O Lado comumente difundido

Ao pesquisarmos sobre segurança relacionada à gestão de produtos, geralmente encontramos alguns conceitos pontuais:

Atualização do ambiente – Todos os nossos sistemas estão atualizados e corrigidos? Nossas soluções de antivírus e firewall estão atualizadas e totalmente funcionais? Aqui é o básico. Independentemente da sua profissão, isso pode ser uma porta de entrada para perda de dados sensíveis ao seu negócio e seu produto. Por exemplo: você tem windows e devido a uma falha, hackers conseguem invadir e coletar alguma informação da sua máquina/rede. Normalmente, isso pode acontecer em escala e a Microsoft corrigi a vulnerabilidade em um patch de segurança. O objetivo de uma atualização de patch de segurança é cobrir as falhas de segurança que uma atualização de software importante ou um download inicial de software não cobriu. O problema aqui a ser observado é que o patch não pode resolver as vulnerabilidades se o usuário ou administrador de rede não instalar imediatamente a atualização na qual o patch de segurança está contido. Qualquer software normalmente tem muitos patches lançados ao longo de um período, portanto, se você tiver o software inicial, mas optar por não atualizá-lo, estará deixando um buraco para cada patch lançado para esse determinado software.

Backups – Está sendo feito backup de tudo regularmente? Temos procedimentos sobre como restaurar sistemas a partir de um backup, se necessário? Já pensou se o repositório das especificações/documentações das features não entrou no backup ou esta corrompido? Nesse ponto, podemos observar dois itens importantes: Primeiro, precisamos fazer backup de tudo o que é importante. Muitos backups são centrados no servidor ou no aplicativo, mas e quanto a todos os dados não estruturados espalhados pela sua rede e na nuvem que não estão sendo copiados? Em segundo lugar, teste seus backups ocasionalmente, especialmente se você não estiver recebendo nenhum erro em seus backups. Não há nada pior do que tentar se recuperar de uma perda, apenas para descobrir que seus backups não são legítimos ou que você fez backup dos dados errados ou nenhum dado. Os testes dos backups precisam estar incluídos na politica e estratégia de segurança.

Conformidade – Estamos acompanhando todos os regulamentos e requisitos regulamentares aplicáveis? O desenvolvimento, a utilização e o gerenciamento de sistemas de informação devem estar de acordo com requisitos legais. Já imaginou liberar o acesso ao seu produto para usuários dos EUA e não estar em conformidade, por exemplo, com a LGPD deles? No meu dia-a-dia, isso é mega pertinente e as vezes, no automático, nosso modo de pensar sob a experiência brasileira pode atrapalhar quando você esta trabalhando para fora. Além disso, deve estar em conformidade técnica com as políticas e normas organizacionais de segurança da informação. Deve existir ainda uma política de conformidade, que deve ser divulgada em toda a organização. E uma vez que todos tomem consciência de suas responsabilidades, do que pode ou não ser feito e do que pode ou não ser acessado. Podemos citar também a PCI-DSS, que é uma certificação para empresas que atuam na área financeira (caso seu produto realize transações financeiras). Também outras certificações como SOC II (mais comum por não ter que divulgar os dados). A SOC II analisa se você faz backups de forma rotineira, se os backups estão seguros, como é feito o controle de acesso ao seu ambiente (AWS, Microsft Azure, inclusive o serviço de e-mail) e aplicação (produto).

Verificação de Fornecedores – Imagine que você tem um time especialista, outsourcing, para um desenvolvimento específico. Porém eles estão habituados com as regras e políticas da sua própria empresa. Porém nossos fornecedores precisam atender nossos próprios padrões de segurança. Se existe uma politica de conformidade, funcionários e fornecedores devem ser abordados por ela. As regras podem e devem ser explicitas junto a contratação do fornecedor, tanto para deveres como responsabilidades.

Auditabilidade – Estamos armazenando todos os dados, transações, eventos e históricos de alterações relevantes para que possamos passar junto a uma auditoria oportuna? Aqui podemos concentrar ações tanto do sistema operacional quanto dentro das ferramentas de uso diário e/ou uso sensível da empresa.

Criptografia – Todo o material sensível é criptografado e estamos usando a melhor e mais recente tecnologia para fazer isso? Criptografia significa que apenas pessoas e sistemas que deveriam ler seus dados, de fato, estão fazendo isso. Se as pessoas de fora tiverem acesso, elas não conseguirão entender o que estão vendo.

Alfredo, não entendi!

Bom, sabe quando você tem um arquivo excel (xlsx) e vai tentar abrir com um bloco de notas ou qualquer outro software incapaz de ler uma planilha, o arquivo é aberto com vários caracteres estranhos né? então, só quem vai ver a planilha é quem tem um excel para ler. É mais ou menos o que quis dizer no paragrafo acima.

As empresas precisam criptografar todos os dados pessoais. Existem tecnologias comuns. Eles funcionam e não são difíceis de implementar. Existem duas maneiras de acessar os dados.

  1. Quando estamos transmitindo dados pela internet.
  2. Quando a armazenamos em algum lugar.

Tecnologias como SSL para transmissão e RSA ou AES para armazenar são boas para serem analisadas no início. Existem provedores de serviços externos que podem fazer testes de penetração. Eles tentam invadir os dados da sua empresa e mostrar como eles fizeram isso.

Um bom exemplo disso são os Ransomware. Onde caso sua proteção não seja efetiva, você estará exposto. Onde os atacantes utlizam de sistemas vulneráveis para criptografar todos os seus dados, sendo que não são feitos backups regularmente, e pedem recompensa pelos dados da sua empresa.

Autenticação – Estamos usando autenticação de dois fatores onde faz sentido? Logon único? Exigindo atualizações regulares de senha? A autenticação é o processo de verificar a identidade de um usuário obtendo algum tipo de credenciais e usando essas credenciais para verificar a identidade do usuário. Se as credenciais forem válidas, o processo de autorização será iniciado. O processo de autenticação sempre prossegue para o processo de autorização.

Flat traffic police inspector check digital driver licence of young woman, scan QR code with phone. Traffic officer scanning electronic driving document with smartphone app. Policeman control of car.

Você ai, já passou em alguma blitz da polícia? Seja dirigindo ou de carona, você viu como é a abordagem certo? Quando o policial te solicita o documento, ele quer confirmar que você é quem diz ser, e se seus dados estão válidos junto a base de dados regulamentar.

Lembra que falei ali em cima que depois de autenticar, tem o processo de autorizar? Aqui é onde o policial irá te liberar para seguir adiante ou … 🙁 game over.

No desenvolvimento de produtos seguros, é crucial reconhecer que a implementação de autenticação de dois fatores nem sempre é suficiente para garantir a proteção dos usuários. Por exemplo, ao adotar o 2FA por meio de mensagens SMS, é importante considerar a possibilidade de um atacante roubar o chip do celular, comprometendo tanto o 2FA quanto a capacidade de recuperar a senha. Nesses casos, é recomendável associar o 2FA a um aplicativo confiável, como o Google Authenticator ou o Okta Verify, para aumentar a segurança e mitigar as vulnerabilidades associadas ao uso exclusivo do SMS. A autorização é o processo de permitir que um usuário autenticado acesse os recursos verificando se o usuário tem direitos de acesso ao sistema. A autorização ajuda você a controlar os direitos de acesso concedendo ou negando permissões específicas a um usuário autenticado.

💡 Pausa para água? Estamos só na metade 😅

A autorização, por outro lado, ocorre depois que sua identidade é autenticada com sucesso pelo sistema, o que, em última análise, dará permissão total para acessar os recursos, como informações, arquivos, bancos de dados, fundos, locais, quase tudo. Então, para simplificar, a autorização determina sua capacidade de acessar o sistema e até que ponto. Depois que sua identidade for verificada pelo sistema após a autenticação bem-sucedida, você estará autorizado a acessar os recursos do sistema.

No meu dia-a-dia, além dos sistemas onde normalmente faço os processos de autenticação/autorização, um local super comum são as APIs. Aqui, podemos encontrar pelo menos 3 modelos/frameworks para autenticar:

API Key – Uma chave de API é uma string gerada aleatoriamente e preparada de maneira criptograficamente forte.Cada chave de API corresponde a um registro em um banco de dados, que especifica os escopos de acesso da e outras informações relacionadas. Para usar chaves de API em seu serviço de API, primeiro atribua a cada TPM que planeja usar seu serviço de API uma chave de API exclusiva; toda vez que o TPM deseja acessar uma API, ele passa a chave para o serviço da API como parte da solicitação. Ao receber uma chamada de API, o serviço de API verifica a chave de API recebida, geralmente combinando-a com os registros de chave, e atende (ou recusa) a solicitação de acordo.

HTTP Basic Authentication – O Basic Authentication é o sistema de autenticação mais comum do protocolo HTTP. Ele é incluído no header da requisição HTTP. O Basic Auth no HTTPS (TLS) é OBRIGATÓRIO (basic auth sem TLS vão roubar sua senha sempre), mas não é 100% seguro. Seu uso dependerá do nível de risco dos dados que estiverem transitando. Perceba que a cada requisição você estará enviando as credenciais. A autenticação pode ser permanentemente armazenada no navegador, se requerido pelo usuário (bem difícil acontecer quando se trata de RESTful APIs).

Token – As chaves de API e a autenticação básica HTTP exigem que as credenciais sejam enviadas ao serviço de API sempre que uma chamada de API for feita. Por mais simples que seja, o design está longe de ser o ideal, pois incorre em sobrecarga desnecessária e apresenta riscos de segurança adicionais: seu serviço de API precisa verificar repetidamente o mesmo conjunto de credenciais e transmitir informações confidenciais pela rede repetidamente aumenta as chances de comprometimentos de segurança.

Os modelos baseados em token ajudam a resolver algumas das preocupações acima. Em vez de passar credenciais, os clientes agora usam tokens para acessar APIs. Os tokens são independentes das credenciais do usuário e geralmente têm vida curta, consequentemente, mesmo que ocorra um vazamento, o dano pode ser controlado rapidamente. Alguns formatos de token, como JWT (JSON Web Token), também são autocontidos: seu serviço de API pode verificá-los sem precisar consultar uma fonte.

OAuth2 – OAuth2 é uma estrutura de autorização amplamente usada que permite que os clientes acessem recursos com segurança e eficiência. Ele inclui quatro fluxos de autorização diferentes, cada um para um cenário específico.

Limite de responsabilidade – Estamos capturando e armazenando dados de que não precisamos? Estamos enviando ou potencialmente expondo informações que não são críticas para o aplicativo principal?

Política – Sua empresa possui uma política de segurança bem compreendida? Seus usuários conhecem e têm acesso a ela? Alguns exemplos itens presentes em uma politica:

  1. Alteração de senha em x dias
  2. Template mínimo para criação. Com caracter especial, letras maiúsculas e minúsculas e números.
  3. Perfis de usuários com permissões bem delimitadas.

Cookies – Você está solicitando que seus usuários optem por permitir que você armazene seus dados? Você está dando a eles a opção de optar por não participar desses programas? E seus sistemas realmente funcionam de maneira diferente com base na opção selecionada? Os cookies são uma forma de os sites conhecerem seus clientes. Cada cookie armazena algumas informações sobre cada um de seus usuários para lembrar e identificar todos os usuários que retornam. Isso é ótimo para melhorar a experiência do usuário porque os usuários não precisam executar constantemente ações que provavelmente já fizeram muitas vezes antes, por exemplo, fazer login em suas contas ou adicionar um item de volta ao carrinho de compras. Ao lembrar quem você é, os sites que usam cookies podem fornecer uma experiência de usuário personalizada. Existem muitos problemas de segurança em relação ao cookie da web. O principal tópico mais discutido em relação aos cookies é a privacidade. Como os cookies podem ser usados para monitorar o comportamento do usuário em muitos domínios, os cookies apresentam uma maneira de as empresas essencialmente rastrearem você pela Internet.

No contexto da segurança de produtos, é relevante mencionar as práticas de autenticação em plataformas de nuvem, e-mail e Jira. Ao utilizar Single Sign-On (SSO) ou OAuth, geralmente é atribuído um token de curta duração para invalidar as credenciais e evitar invasões por parte de indivíduos com níveis elevados de permissão. No entanto, é necessário encontrar um equilíbrio entre segurança e praticidade, já que as pessoas precisam fazer login repetidamente nas plataformas para continuar suas tarefas. Segurança é diretamente proporcional a burocracia: quanto maior a segurança, maior a burocracia

Alguns pontos que você, como TPM, deveria ficar atento:

  1. Os sistemas de perfis de usuários foram projetados com base nas informações que eles podem extrair dos cookies. Esses sistemas de perfis permitem que os sites forneçam informações ao usuário com base em informações privadas, como histórico de navegação ou conteúdo visualizado.
  2. Os cookies também representam um risco para o fator de autenticação de um site. Os ataques Cross-Site Scripting (XSS) podem ser armados para roubar cookies do usuário e autenticar em um serviço em nome desses cookies roubados.
  3. Os cookies também podem ser usados em ataques Cross-Site Request Forgery (CSRF) para enganar um usuário a realizar inadvertidamente uma ação em um serviço com a identidade associada ao cookie, como alterar a senha do usuário ou enviar dinheiro para um serviço controlado pelo adversário.

Bom, agora é o outro lado da moeda. O lado especialista que pode nos ajudar no direcionamento do desenvolvimento seguro de produtos.

Parte 2: Coroa – O Lado Técnico do Desenvolvimento Seguro de Produtos Digitais

Na primeira parte deste artigo, exploramos o lado mais evidente e perceptível do desenvolvimento seguro de produtos digitais, conhecido como “a cara” da moeda. Agora, vamos mergulhar na parte técnica, representada pela “coroa”, com um foco especial em DevOps e SecOps.

A importância do DevOps na segurança de produtos digitais

O DevOps é uma abordagem que combina desenvolvimento e operações em um fluxo de trabalho integrado. Enquanto tradicionalmente o desenvolvimento e as operações eram realizados em silos separados, o DevOps visa quebrar essas barreiras e promover uma colaboração contínua. Quando aplicado ao desenvolvimento seguro de produtos digitais, o DevOps desempenha um papel crucial.

Uma das principais vantagens do DevOps é a automação de processos, incluindo a implantação de infraestrutura em nuvem pública e/ou privada, análise estática de código e implantação contínua. Essa automação possibilita a identificação e correção mais ágil de vulnerabilidades. Embora o DevOps não esteja diretamente envolvido na criação de testes, é importante ressaltar que a equipe de AppSec desempenha um papel fundamental nesse aspecto. A equipe de AppSec é responsável por desenvolver testes e pipelines de CI/CD específicos para busca de vulnerabilidades de segurança nos produtos (apps). Essa abordagem reflete uma mentalidade de responsabilidade compartilhada, onde a segurança é considerada vital em todas as etapas do ciclo de vida do produto digital, desde o planejamento até a manutenção.

SecOps: integrando segurança ao desenvolvimento

SecOps, ou Segurança Operacional, é uma prática que visa integrar a segurança no ciclo de vida do desenvolvimento de produtos digitais. Ao adotar uma abordagem SecOps, as equipes de desenvolvimento e segurança trabalham em conjunto para identificar e mitigar riscos de segurança.

Um aspecto essencial do SecOps é a realização de testes contínuos de segurança. Isso envolve a execução de testes automatizados e manuais para identificar vulnerabilidades em potencial. Ferramentas como scanners de segurança, análise dinâmica de código e simulações de ataques podem ser utilizadas nesse processo. Além disso, a monitorização constante da infraestrutura e do tráfego de rede é essencial para detectar qualquer atividade suspeita ou invasões em tempo real.

Melhores práticas para o desenvolvimento seguro

No contexto do DevOps e SecOps, existem algumas melhores práticas importantes a serem seguidas para garantir o desenvolvimento seguro de produtos digitais:

  1. Integração de segurança desde o início: A segurança deve ser considerada desde as fases iniciais do desenvolvimento. Isso inclui a definição de requisitos de segurança, a identificação de ameaças potenciais e a realização de avaliações de risco.
  2. Testes contínuos: A realização de testes automatizados e manuais em todas as etapas do desenvolvimento é fundamental para identificar e corrigir vulnerabilidades de forma proativa. Além disso, é importante mencionar a importância da análise estática de código e análise de dependências, que são realizadas pela equipe de AppSec. Essas análises, como a SAST (Static Application Security Testing) e DAST (Dynamic Application Security Testing), são incorporadas ao pipeline de entrega e integração das aplicações, permitindo a identificação de vulnerabilidades. Vale ressaltar que essas análises não são exatamente testes, mas sim análises detalhadas realizadas por meio de ferramentas especializadas, que buscam por potenciais vulnerabilidades. Dessa forma, as práticas de segurança são integradas ao processo de desenvolvimento, garantindo a detecção precoce de falhas e a adoção de medidas para mitigá-las.
  3. Monitorização e resposta a incidentes: Ter uma estratégia de monitorização contínua e um plano de resposta a incidentes é crucial para lidar com ameaças em tempo real. Isso envolve a implementação de sistemas de detecção de intrusão, monitorização de logs e processos claros para responder a incidentes de segurança.
  4. Atualizações e correções regulares: Manter o produto digital atualizado com as últimas correções de segurança é essencial para mitigar riscos. Isso inclui aplicar patches de segurança, atualizar bibliotecas e frameworks utilizados e acompanhar as melhores práticas de segurança recomendadas pela comunidade.
  5. Conformidade: A garantia de conformidade com os padrões e regulamentações relevantes é um aspecto crucial no desenvolvimento de produtos seguros. Para isso, é essencial contar com uma equipe de conformidade dedicada, responsável por avaliar tanto a infraestrutura quanto a aplicação em relação a normas como PCI-DSS (Payment Card Industry Data Security Standard), SOC II (Service Organization Control II) e outros padrões aplicáveis ao setor.

Legal Alfredo, mas preciso de um passo a passo para implementar amanhã!

💡Opa, “pra já”!

Checklist para garantir o desenvolvimento seguro

Product Manager:

DevOps, SecOps, BlueTeam, RedTeam, AppSec:

📢 Baixe agora o template COMPLETO de segurança para Tech PMs e garanta produtos mais seguros! 🚀

Conclusão

💡 E ai, curtiu? Faltou explicar algo? Quer mais um pouco mais de profundidade? Manda sua DM no linkedin ou insta que vamos pegar as dúvidas e fazer uma parte 2.

Neste artigo, exploramos o “lado técnico” do desenvolvimento seguro de produtos digitais, destacando a importância do DevOps e SecOps nesse contexto. Ao adotar uma abordagem colaborativa e integrada, enfatizando a automação, testes contínuos e monitorização, as equipes de desenvolvimento podem criar produtos digitais mais seguros e resilientes.

Lembre-se de que a segurança não é um objetivo único, mas sim um processo contínuo. À medida que novas ameaças surgem e a tecnologia evolui, é fundamental manter-se atualizado e adaptar as práticas de segurança em conformidade. Ao equilibrar tanto o lado “cara” quanto o lado “coroa” da moeda, você estará no caminho certo para o desenvolvimento seguro de produtos digitais.

Referências:

Sair da versão mobile