Vídeo no Youtube: https://youtu.be/v_WEbE2vupI
Transcrição do Vídeo:
Antes de tudo, eu não vim aqui te vender curso. Eu vim falar a verdade sobre segurança da informação e o que você precisa saber tanto para LGPD como para atender as boas práticas de segurança na sua empresa. É praticamente um treinamento. E por isso eu serei um pouco duro aqui, em alguns momentos, porque esse é um assunto que não pode ser tratado como se fosse supérfluo.
Logo que a gente entra no setor de TI ou dados da empresa, geralmente o CTO ou CSO ou equivalente, já começa falando: temos de usar um Kali Linux ou Parrot? Vocês vão fazer um teste de penetração (pentest)? Metasploit? A resposta é não.
E nós estamos cercado de vazamentos nos últimos anos, e cada um mais idiota que o outro. Lembram do vazamento do Ministério da Saúde, em que um funcionário subiu uma planilha com dados de acesso a informações médicas de milhões de brasileiros com diagnóstico ou suspeita de covid? De que adianta você pensar em segurança, software ou firewall, quando você tem um funcionário que faz uma burrice dessa? Na primeira semana de setembro deste ano, teve um vazamento no INEP de milhões de dados de estudantes. O código do sistema, que foi todo feito em Angular, permitia que você simplesmente, depois de logado, mudasse o parâmetro de CPF e aí você poderia consultar diversas informações sobre o aluno vinculado à aquele CPF. Mais uma vez, de que adianta firewall quando você tem gente que facilita o trabalho do “hacker”.
Na real, você nem precisa ser hacker, basta saber o básico de programação e rede, e eu te garanto que você consegue explorar a maioria dos últimos vazamentos que tivemos nessa década. E esse é o ponto crucial deste vídeo. Todo desenvolvedor precisa saber o básico de segurança. O ideal é saber pelo menos o nível intermediário. Com o básico de segurança esse problema no código do INEP não teria acontecido. E o que acontece com muitas empresas, é que eles contratam desenvolvedores que não sabem nada de segurança, o que é um pouco difícil, ou não contratam especialistas para testarem.
E eu vou falar uma verdade aqui. Eu trabalho com TI desde 1997. A maioria dos desenvolvedores, eu chuto que uns 90%, tem na verdade é preguiça de pensar em como o sistema que ele mesmo desenvolveu pode falhar ou permitir acessos indevidos. Esse exercício de pensar na segurança do que está escrevendo é imprescindível. Mesmo que exista alguém na equipe responsável pela segurança. Porque se o especialista encontra o erro, você vai ter de refatorar o código e corrigir o problema. Então para quê trabalhar em vão? Já vai testando e amadurecendo seu código à medida que vai escrevendo.
Aquilo que vemos em séries e filmes, em nada tem a ver com o trabalho de um hacker. Longe disso. Imensamente longe. Aquilo que você viu em Mr Robot não acontece na vida real, ou, se acontece, é em menos de 0,1% dos casos. Porque ali na série envolve não só um gênio da computação, como também um minucioso trabalho de engenharia social. Você pode considerar que você nunca vai conhecer um hacker na vida. As chances são muito baixas. Até mesmo porque uma das características de um hacker é ser low profile. Não tem rede social, não vai a eventos e geralmente tem uma profissão não ligada à informática para poder afastar qualquer ligação com suas atividades.
Não é que você deve se preocupar com os hackers russos, chineses ou israelenses que existem por aí. A maioria das invasões se dá por programas mal escritos. Softwares toscos. Eu mesmo cometo alguns erros básicos de vez em quando. Imagina um iniciante. Você não precisa ser um expert em segurança, basta fazer o básico.
E entenda uma coisa: se seu software, site ou plataforma não foi invadido ainda, não significa que está seguro. Significa só que ninguém se interessou em invadir ou não apareceu no radar de alguém mal-intencionado. Falta de invasão é diferente de estar seguro. O que nos leva a:
Não existe ambiente 100% seguro. Isso é mito. Se você vê no rodapé de um site aquele selo de 100% seguro, não se engane. Isso não existe. Temos alguns sistemas com 99,999% de segurança, como é o caso da urna eletrônica brasileira, que faz diversas operações off-line, e só entra na rede depois para transmitir, e ainda assim o pacote transmitido passa por uma série de conferências para ter certeza de que não foi alterado. Além disso, o TSE abre editais públicos, chamados TPS (testes públicos de segurança) onde você pode se inscrever para tentar encontrar bugs e falhas no software. Permitindo assim que o TSE possa corrigir isso antes da próxima eleição. E eu só falei sobre urna aqui, porque é um bom exemplo de serviço bem-feito na área de segurança da informação. Quer saber um pouco mais? Acessa: urnaeletronica.info E isso não é propaganda do governo ou jabá. Não estou sendo pago para falar isso.
Dito isso, eu preciso reconhecer que existem sim algumas empresas que fazem o dever de casa direitinho. Elas não estão 100% seguras, porque ninguém nunca estará. Segurança é uma paranoia constante na vida da pessoa que é responsável pela segurança e pelos dados de outros. Mas algumas empresas não só contratam desenvolvedores experientes, que se preocupam com o que está sendo desenvolvido, bem como possui parte do time dedicado a explorar falhas e encontrar bugs de segurança. E indo além disso, essas empresas abrem programas de bug bounty onde oferecem recompensas financeiras para quem encontrar falhas em seus sistemas. E existe todo um mercado de desenvolvedores experientes que vivem de trabalhar em programas de bug bounty. As recompensas precisam ser boas, senão não vai atrair ninguém. Mas isso é um assunto para outro vídeo.
Você deve estar se perguntando: Então, se nunca estarei seguro, de que adianta? Bom, você deve entender que preocupação com a segurança vai além de impedir invasões, trata-se de entender que devem ter planos de contingências para caso uma invasão ocorra. Você precisa estar preparado para lidar com os problemas e ter um plano de ação para cada caso. Esse inclusive é um dos pontos da LGPD. Uma coisa que eu tenho visto por aí, é que tem empresa que gasta milhares de reais por ano em firewall as a service e softwares de proteção e acham que isso é garantia de segurança e que, por usarem isso, estão adequados à LGPD. Quer um exemplo fácil e que já citei aqui hoje? O INEP provavelmente paga por um serviço de firewall para impedir uma “invasão”. De que adianta ter o firewall se o código está porco e te permite fazer uma ação dentro do sistema para ver dados de outras pessoas?
Segurança não é buscar os 100% de segurança. É ter consciência de que algo de ruim pode acontecer e então implementar planos para agir caso isso aconteça. O nome disso é Compliance. Você precisa ter o entendimento das consequências da lei e a implementação de processos que minimizem os impactos da lei, caso aconteça algo.
O que algumas empresas vendem por aí, como selos, certificados e algumas consultorias, nada mais é do que uma sugestão de que a empresa x tomou providências para evitar problemas e por isso seus gestores (pessoas físicas) não devem ser responsabilizados caso algo de errado aconteça. Isso é o que chamamos de limitar o impacto e gerenciar o risco aos envolvidos. É melhor que não fazer nada, mas eu não considero que isso seja suficiente, uma vez que se houver uma exposição de dados ou um ataque ransomware, esse gerenciamento de risco não vai te salvar ou salvar sua empresa do impacto que acontecerá.
E aí eu vou citar o exemplo das startups que surgem revolucionando o mercado. Quando você é uma startup de tecnologia, você não está preocupado com segurança e com processos. Você está preocupado em entregar o produto o mais rápido possível gastando o menor dinheiro possível. Por isso muitas startups nascem com preços supercompetitivos. Elas não possuem um sistema de gerenciamento de processos bem definidos. E aí você se pergunta: Por que ela já não começa com tudo direitinho, dentro dos padrões? E a resposta é simples, isso custa tempo.
Eu já vi uma startup baixar as portas, porque o desenvolvedor principal não tinha nada documentado, sabia todas as senhas e acessos, e num belo dia de sol ele foi atropelado por um motorista embriagado e veio a óbito. E importante frisar, que acima de tudo, isso é uma perda trágica e irreparável para todos os amigos e familiares daquela pessoa. Mas indo além, o que vocês acham que aconteceu? O custo para a empresa era tão alto para conseguir resolver isso, que ela não conseguiu absorver e fechou as portas.
Uma startup basicamente vive de rodadas de investimento. Quando ela recebe a primeira rodada de investimentos, o CEO não pensa em refatorar o código, criar procedimentos, estruturar o compliance e nem nada disso. Ele precisa entregar novas funcionalidades e aumentar a base de usuários para poder ganhar a próxima rodada de investimentos. Então entra num ciclo de falta de tempo. Nas startups fintechs isso é minimizado depois já da primeira rodada de investimentos, porque uma falha de segurança pode acarretar numa perda expressiva de dinheiro e um grande abalo na confiança com seus usuários. Você está mostrando que você é incompetente e que não cuidou da segurança. Então geralmente está contemplado no capital arrecadado, que parte dos recursos será usado para segurança e compliance.
E não é só ataque de hacker que preocupa. Sistema off-line ou lento demais porque você não soube dimensionar a capacidade de carga dos servidores. Perda de pacote de dados no meio de uma transação ou coisas desse tipo são uma tremenda dor de cabeça e pode trazer muito prejuízo para uma empresa.
Qualquer conselho administrativo que se prese, morre de medo de uma invasão, vazamento de dados, que o sistema fique fora do ar e etc. E não só por questão de segurança, mas porque isso faz parte do “pacote” de uma empresa saudável e será levado em conta caso surja uma oportunidade para um M&A ou IPO. Nenhum investidor que se prese vai investir em uma empresa que não tenha processos estruturados e seja uma grande liability para ele. E por isso deve ser pensado logo que a empresa começa a crescer em como você vai organizar sua infraestrutura.
Da mesma forma que sua empresa quer uma equipe de contabilidade para ter certeza de que não está cometendo algum crime fiscal sem saber e que tenha uma equipe de advogados para garantir que todos os contratos estão de acordo com a lei, há a necessidade de se preocupar com a equipe de tecnologia, para mitigar qualquer problema nessa área. E muitas empresas grandes, tratam corretamente da contabilidade, jurídico, recursos humanos e outras áreas muito bem, mas largam para lá a parte de tecnologia. É um erro muito, mas muito comum.
Se sua empresa é de médio ou grande porte, ou se é pequena, mas é 100% dependente de um sistema, você já deveria estar acostumado com palavras como ITIL, COBIT, TOGAF e outras. Quando uma empresa é pequena, é muito fácil saber tudo sobre o sistema. Geralmente é uma única equipe que cuida do desenvolvimento. Mas em empresas de médio e grande porte, existem dezenas de equipes de desenvolvimento e ninguém sabe 100% de tudo do sistema. Quando um bug acontece na interface do sistema ou o QA identifica uma brecha, pode ser muito difícil identificar quem subiu no deploy aquela falha. Se a documentação não está conforme os padrões, você acaba tendo de devolver todos os pacotes e depois analisando um a uma para poder identificar. Pior, o bug veio nesse último deploy ou já estava em um deploy antigo e só foi ativado agora por conta de uma funcionalidade nova?
Um erro muito comum que eu vejo nas empresas que visito é que elas pegam um framework como o PMBOK, que nada mais é do que um grande manual de boas práticas para gerenciar projetos, e tenta implementar tudo. Todo mundo que mexe com projetos deve saber que nem tudo que o PMBOK traz vai se adequar ao seu tipo de projeto. Um bom gestor de projetos, ou uma boa empresa de auditoria/consultoria, deve explicar e escolher quais pontos do PMBOK serão usados. Para não te fazer perder tempo nem recursos.
Uma das coisas que a implementação de processos garante é um pouco de burocracia para assegurar que tudo esteja bem documentado. Eu já vi uma empresa de médio porte em que metade dos desenvolvedores possuem a capacidade de criar servidores na conta da AWS da empresa para subir aplicações. O que acontecia na prática? Tinham muitos servidores que não estavam listados e que o gerente ou administrador nem faziam ideia que existia. Então uma das primeiras coisas que precisei implementar é deixar a função de criar servidores somente para um ou dois funcionários. E sempre que eles criassem, era preciso documentar tudo. Quem solicitava o servidor precisava justificar e documentar também. Tudo ficou mais organizado. E na falta de 1 ou 2 funcionários da empresa por um curto ou longo período, bastava que os substitutos lessem a documentação para poder entender o que havia no sistema.
Agora imagina que você tem uma startup pequena, 30 funcionários, um software funcionando e entregando um produto de qualidade. Todo mundo conhece todo mundo. Os donos que contrataram e testaram os funcionários. É a melhor fase de uma empresa na minha opinião. Todo mundo tem muita liberdade para criar. E justamente por essa falta de governança que existe nessa fase, é um momento em que a empresa está exposta a diversos riscos. Mas quando você recebe um investimento, digamos que de 10 milhões de dólares, e precisa contratar mais gente para poder crescer e dar conta da demanda. Agora você não tem mais 30 funcionários, você tem 1000. E, obviamente, não foi o dono que contratou todo mundo ou fez a entrevista. Você delegou para uma pessoa do RH. E por melhor que seu gerente de RH seja, sempre haverá más contratações quando você precisa preencher um número grande de vagas. Digamos que seu RH errou pouco, algo em torno de 10% das vagas, você agora é dono de uma empresa com 100 funcionários incompetentes ou ativamente mal-intencionados. Percebe o tamanho do problema?
No começo eu falei que você não precisa se preocupar com hackers russos, chineses e etc. Normalmente ataques que são muito bem planejados são feitos por meio de engenharia social. A engenharia social, a grosso modo, é você espionar dados que são normalmente públicos (como redes sociais, linkedin, e etc) e conseguir informações das pessoas que trabalham na empresa. E então basta que você peça o acesso a pessoa certa, usando a abordagem correta. Não precisa de código ou script elaborado, nenhuma tentativa forçada de passar pelo firewall. Simplesmente pegue o telefone e peça o acesso pro Sysadmin. Vou contar um caso real que aconteceu comigo em um trabalho que fiz para uma empresa de grande porte.
Eu queria ter acesso a um banco de dados de clientes. Eu não era funcionário. Então eu mandei um e-mail pro administrador, me identifiquei que era da consultoria que havia contratado e pedi que ele me passasse o contato do RH que eu precisava dar uma palavrinha com eles. Eu enviei então um e-mail pro RH, contendo a conversa com o administrador no corpo do e-mail e falei que, para realizar meu trabalho eu precisava de um e-mail corporativo, do domínio daquela empresa. O pessoal do RH ligou no TI e solicitou a criação de um e-mail para mim. Depois de um dia, eles me mandaram por e-mail o login e senha do meu novo e-mail. Então eu sabia um dos nomes dos desenvolvedores, que foi citado em uma reunião na empresa. Pesquisei sobre ele no LinkedIn e consegui o nome de mais 2 desenvolvedores. Pela senioridade do cargo, eu supus que o “João” era o mais velho de casa dos 3. Mas eu sabia que o setor era grande. De posse do e-mail corporativo, eu mandei um e-mail pro João me identificando como um novo desenvolvedor que foi contratado para trabalhar remotamente, e que eu faria uma auditoria do código para garantir a segurança. Não foi surpresa nenhuma que o João tenha me respondido em menos de 30 min e se colocou à disposição. A primeira coisa que eu pedi, foi acesso ao código fonte do sistema no Git-hub. Em menos de 1 hora meu e-mail havia sido vinculado como colaborador do sistema e eu tinha acesso a todo o código fonte. Com poucas horas de análise, eu consegui achar o arquivo que continha o usuário e senha do banco de dados. Mas o banco de dados precisava de autenticação para ter acesso. Daria um pouco mais de trabalho, mas não seria problema. No entanto, para poupar meu tempo eu peguei meu celular, liguei pro João no fixo da empresa e pedi ele pra liberar meu acesso. Ele não tinha essa autoridade, mas prontamente me transferiu pro gerente da TI, que fez 1 ou 2 perguntas sobre quem eu era, mas o João já havia dito pra ele sobre mim. E então ele pegou e liberou meu acesso.
Eu não usei nenhum software ou script pra hackear o sistema e ter acesso ao banco de dados deles. Eu simplesmente pedi. Eu pedi com jeitinho. E é justamente esse o tipo de vulnerabilidade que milhares de empresas possuem hoje. Poderíamos analisar este caso com mais detalhes, mas fica para outro vídeo. O ponto principal é: É muito fácil ter acesso a um sistema ou banco de dados se você tiver um pouco de engenharia social. Uma outra maneira muito comum em grandes empresas é o invasor conseguir deixar um pendrive solto na empresa. Seja na porta, no banheiro ou outra área da empresa, que ele teve acesso em uma visita ou algo do tipo. Eu te garanto que em mais de 90% dos casos, alguém da empresa vai pegar esse pendrive no chão e plugar na máquina. Fácil.
Outro tipo de ataque muito comum, é devido a reaproveitamento de código. Todo desenvolvedor que eu conheço reaproveita código de aplicações antigas ou de aplicações de terceiros. E não há nada de errado nisso. Até porque seria impossível criar tudo do zero de forma diferente. Mas é uma boa prática, de tempos em tempos, rodar alguns testes de segurança para ter certeza de que nenhum dos códigos do seu sistema foi explorado como uma falha. E isso acontece o tempo todo. Muitas vezes um código de login é quase perfeito e não apresenta, até então, nenhuma falha. Mas aí um belo dia, alguém descobre uma maneira de burlar. E aí o que o desenvolvedor mal-intencionado faz é criar um script para explorar essa falha de forma automática. Para facilitar a vida dele. A próxima etapa é começar a vasculhar tudo que é site na internet, que utilize esse trecho de código e aplicar o script criado e aí você tem acesso. Em CMSs como o wordpress, drupal, magento e outros, isso é muito comum. Por terem milhões de usuários, eles são muito visados por hackers. Uma vez que o hacker descobre a falha, começam a rodar script para pegar, por exemplo, todos os sites feitos em magento e tentar invadi-los. E no fim das contas, você não está manualmente realizando uma invasão. Você colocou um código um script para fazer isso por você e ele é capaz de testar a invasão em centenas ou milhares de sites por minuto. No fim do dia você pega o resultado do script e tem lá 70 mil sites que te deram acesso. Aí você faz uma análise se algum merece uma atenção especial ou se você vai criar outro script para infectar esses sites ou instalar algo de sua preferência. O que eu quero mostrar com isso, é que muitas vezes não há uma pessoa tentando invadir manualmente seu sistema, mas sim um script que identificou uma vulnerabilidade conhecida. Por isso é de suma importância que você tenha uma rotina de testes.
Para finalizar esse treinamento, eu queria deixar claro para vocês que segurança e LGPD é uma coisa séria. E não adianta instalar firewall ou programa de segurança e achar que está seguro. A ilusão de segurança é um perigo real e afeta milhares de empresas por aí. Fazer gestão de riscos, adequar à LGPD e estruturar processos é um trabalho pesado e requer muita dedicação, treinamento e boa vontade de todo mundo que participa. Sem isso é impossível!
Para ficar por dentro de mais novidades e conteúdos, se inscreva em nosso canal e nos acompanhe nas redes sociais, os links estão na descrição do vídeo.
Top comments (0)