Pensar como hacker, saber explorar brechas criando ou editando códigos e entender como falhas de segurança são utilizadas pode ajudar no entendimento e gerenciamento da aplicação de correções e patches
Há dois meses mencionei em um artigo “Avance ao ‘Next Level’ de Segurança” o desafio de manter um sistema ou serviço atualizado mediante o tempo que a vulnerabilidade é descoberta versus o tempo de aplicar uma correção em meados do ano de 2000. Notório que os fabricantes por um lado desenvolviam novas softwares consequentemente traziam novas vulnerabilidades e os mais explorados naquela época era os webservers, seja na plataforma Unix, Linux ou Windows ainda não eram tão maduros. Evidentemente que serviços como DNS, FTP, Telnet, Netbios, entre outros, também eram massacrados.
Crackers usavam suas habilidades para criarem exploits, a fim de explorar vulnerabilidades em serviços de Internet e, na época, como eu trabalhava para um banco americano, foram muitas madrugadas viradas para atualizar o ambiente e corrigir falhas em servidor web. Embora fosse corrido era desafiante e no dia seguinte, uma nova vulnerabilidade aparecia e, para nós, não havia descanso, pois, o objetivo era manter o ambiente sempre atualizado. Ao longo do tempo aprendi a explorar algumas vulnerabilidades criando ou editando alguns códigos com a ideia principal de entender como uma falha de segurança era explorada. Conhecer o lado obscuro foi necessário. Pensar como um hacker foi, acima de tudo, um requisito para me tornar resiliente, capaz de remediar e saber lidar com situações de “tempestades” onde um “zero day” é divulgado ou ocorra uma possível infecção de worm ou ransomware.
Em uma daquelas madrugadas recebi uma ligação do diretor me convocando para ir imediatamente ao banco devido uma infecção de um worm que havia paralisado a rede corporativa. O famoso “Code Red” foi responsável por paralisar milhões de ATMs de muitos bancos ao redor do planeta e, no nosso caso, identificamos que a equipe de desenvolvedores tinha o servidor web “IIS” instalado como padrão nas máquinas com Windows. Tudo que estava na rede foi infectado por esta variante de worm. O resultado foi a virada de noite identificando as máquinas infectadas e corrigindo um por uma. Logo depois veio o “Ninda” para o SQL Server e assim a criatividade foi aumentando ao logo destes anos.
Hoje se fala muito em falhas em todas as camadas, seja no Sistema Operacional, no serviço tipo DNS, SSH ou web, na aplicação web devido uma falha de Injection, XSS ou, indo mais a fundo, uma falha a nível de hardware e processador batizadas de Meltdown e Spectre – e não podemos esquecer as camadas de um virtual machine no ambiente de cloud.
Evidentemente que a experiência vivendo tais situações e trabalhando para grandes corporações, responsável por gerir o processo de gestão de vulnerabilidades, colaborou para pensar fora da caixa e aprender (com os erros) a criar novas estratégias e processos para driblar o desconhecido. Sendo assim, gostaria de compartilhar algumas dicas para gerir um processo de gestão de vulnerabilidade.
Ressalto que a ajuda de frameworks e standards como ISO 27001, PCI-DSS, OWASP, CyberSecurity NIST, etc, irão viabilizar a construção de um processo eficaz e eficiente. Na última semana o Conselho Monetário Nacional do Banco Central tornou vigente a Resolução nº 4.658, de 26/4/2018, que determina uma política de segurança cibernética para todas as instituições financeiras, é evidente que este é mais um elemento para fortalecer o mercado de segurança no Brasil, mas vamos lá com as dicas:
Lista de ativos atualizadas
Tenha em mãos a lista atualizada de todos os ativos de tecnologia da organização incluindo: Sistema Operacional, Aplicações internas e externas, websites com frontend, Internet, mobile applications, Database, software de gerenciamento web, versões de virtual machine, appliances (firewall, IPS, network devices, monitoramento de câmeras) e assegure que todos estão inclusos no processo de gestão de vulnerabilidades.
Classificação de ativos
Todo ativo tem dado, ainda mais agora na era de Big Data, no mais é necessário determinar níveis de classificação da informação nestes ativos, pois irá te ajudar a determinar os requerimentos de segurança para os projetos, sistemas, etc.
Processo e Ferramenta para Gestão de Patches
Assegure que um processo e política de gestão de vulnerabilidades esteja vigente e atualizada. Caso ainda não há possua elabore imediatamente. Use frameworks e standards como o CyberSecurity NIST, ISO 27001, se for do meio bancário a própria Resolução nº 4.658 já determina este requisito. Quanto a ferramenta para gerir o processo, tem inúmeras; a própria Microsoft oferece uma gratuita, seja criativo use planilhas automatizadas ou desenvolva internamente uma ferramenta com painel para consolidar os riscos se o orçamento for curto. Soluções de mercado oferecidas por players de segurança já oferecem um painel atualizado com as vulnerabilidades e CVEs divulgados na comunidade e isso acaba economizando tempo, em vez de ficar consultando diversos sites e analisar boletins de fabricantes. Vale lembrar que sua política precisa ter um critério e matriz de classificação de risco e vulnerabilidade de acordo com os requerimentos do business e relevância.
Suporte do senior management
É vital o suporte da alta administração e, você, como um líder, precisa ter os executivos como parceiros sabendo transmitir a importância dos riscos para a organização. Geralmente dependendo da estrutura da empresa, a TI é responsável por corrigir a falha e aplicar patches. Entretanto, aqui poderá ser o seu calcanhar de Aquiles se você não tiver este grupo como seu parceiro. Lembre-se que uma empresa de Retail não vai querer parar o ambiente para instalar um patch, pois não pretende perder dinheiro, mas é necessário encontrar janelas para remediar a situação. Aqui você precisar ser capaz de talvez usar ferramentas de análise de risco qualitativa e quantitativa para dar visibilidade ao senior management a importância de corrigir o ambiente. Para bancos, com as exigências do Banco Central torna o processo mais acessível.
Conscientize e treine os desenvolvedores
Conscientizar continua sendo a chave principal para convencer e ganhar um parceiro de segurança na sua organização. Tenha foco total em conscientizar principalmente a equipe de TI e DevOps e faça entender que são responsáveis e fazem parte do contexto e que a segurança deve ser levada por todos. Treine sobre o OWASP, secure code, code review, etc e assegure que um processo de SDLC seguro esteja contínuo.
Code Review e Scan de Vulnerabilidades
A tecnologia está cada vez mais avançada e você precisa garantir que a equipe de desenvolvimento esteja preparada, invista em treinamento para desenvolvimento de software seguro, certificações como CSSLP da (ISC)², pentest (OSCP) a nível de aplicação e tenha ferramentas de scan que sejam capazes de checar falhas na camada de aplicação e código incluindo OWASP Top 10 e code review. Lembre-se que uma scan de rede/sistema não é capaz de checar falhas em aplicações web e soluções existem diversas tanto como free e pagas.
Equipe especializada
O time de segurança precisa entender e saber o que está fazendo, tenha profissionais que pensam como um hacker, explore e aprenda com programas bug bounty de gigantes da computação se for aplicável. Ter um colaborador com uma expertise de pentest é valioso.
Cuidado com os Third Parties
Assegure que o processo de gestão de fornecedores está cobrindo todos os parceiros de negócios, cloud providers e provedores de serviços e garanta que o processo de gestão de vulnerabilidades está presente. Se o processo for falho fique de olho e exiga que seja implementado antes de ir para produção.
Introdução da visão na avaliação de riscos de projetos
Introduza no processo de avaliação de risco em projetos a importância de verificar que o sistema, aplicação e/ou ambiente esteja atualizado com o processo ativo dependendo da estrutura na sua empresa. O ISO precisa sempre olhar este processo com prioridade e casar com o processo de gerenciamento de risco e inclua também a avaliação de fornecedores. Certa vez identifiquei um appliance de monitoramento de câmera (CFTV) que rodava na plataforma Windows sem gestão de patches, hardening e sem suporte.
Checklist de segurança ou hardening
Este é um procedimento técnico simples que muitos não fazem. Trocar a senha default de um roteador e configurar adequadamente um servidor web é vital para sobrevivência. É necessário que todo o parque tecnológico possua um procedimento de segurança escrito, formalizado e atualizado pela equipe responsável.
As dicas acima irão ajudar a construir um bom processo de gestão de patches, mas não esqueça de ter uma foto da situação atual da empresa em termos de maturidade de segurança e mais a visualização dos processos críticos de negócios, mapeados por meio do Business Impact Analysis (BIA), que irão contribuir para definir uma boa política e focar no coração da sua organização. Além disso, não confie em todas as soluções de segurança, já houveram ataques criptografados que alguns Web Application Firewall (WAF) não identificaram, sendo assim, a chave é manter-se atualizado, participe de conferências e esteja atento ao que a comunidade hacker está falando.
Em resumo, a forma de aplicar este processo vai variar de empresa para empresa. Se perceber que o desafio seja impossível de alcançar e, mesmo usando habilidades distintas, para convencer a liderança sobre aplicar ou não um patch, talvez esta não seja uma empresa comprometida com a matéria de segurança cibernética, ou a escolha não foi tão certa e está na hora de quebrar o paradigma, seja para mudar a consciência dos executivos ou mudar de companhia. Good luck!
Há dois meses mencionei em um artigo “Avance ao ‘Next Level’ de Segurança” o desafio de manter um sistema ou serviço atualizado mediante o tempo que a vulnerabilidade é descoberta versus o tempo de aplicar uma correção em meados do ano de 2000. Notório que os fabricantes por um lado desenvolviam novas softwares consequentemente traziam novas vulnerabilidades e os mais explorados naquela época era os webservers, seja na plataforma Unix, Linux ou Windows ainda não eram tão maduros. Evidentemente que serviços como DNS, FTP, Telnet, Netbios, entre outros, também eram massacrados.
Crackers usavam suas habilidades para criarem exploits, a fim de explorar vulnerabilidades em serviços de Internet e, na época, como eu trabalhava para um banco americano, foram muitas madrugadas viradas para atualizar o ambiente e corrigir falhas em servidor web. Embora fosse corrido era desafiante e no dia seguinte, uma nova vulnerabilidade aparecia e, para nós, não havia descanso, pois, o objetivo era manter o ambiente sempre atualizado. Ao longo do tempo aprendi a explorar algumas vulnerabilidades criando ou editando alguns códigos com a ideia principal de entender como uma falha de segurança era explorada. Conhecer o lado obscuro foi necessário. Pensar como um hacker foi, acima de tudo, um requisito para me tornar resiliente, capaz de remediar e saber lidar com situações de “tempestades” onde um “zero day” é divulgado ou ocorra uma possível infecção de worm ou ransomware.
Em uma daquelas madrugadas recebi uma ligação do diretor me convocando para ir imediatamente ao banco devido uma infecção de um worm que havia paralisado a rede corporativa. O famoso “Code Red” foi responsável por paralisar milhões de ATMs de muitos bancos ao redor do planeta e, no nosso caso, identificamos que a equipe de desenvolvedores tinha o servidor web “IIS” instalado como padrão nas máquinas com Windows. Tudo que estava na rede foi infectado por esta variante de worm. O resultado foi a virada de noite identificando as máquinas infectadas e corrigindo um por uma. Logo depois veio o “Ninda” para o SQL Server e assim a criatividade foi aumentando ao logo destes anos.
Hoje se fala muito em falhas em todas as camadas, seja no Sistema Operacional, no serviço tipo DNS, SSH ou web, na aplicação web devido uma falha de Injection, XSS ou, indo mais a fundo, uma falha a nível de hardware e processador batizadas de Meltdown e Spectre – e não podemos esquecer as camadas de um virtual machine no ambiente de cloud.
Evidentemente que a experiência vivendo tais situações e trabalhando para grandes corporações, responsável por gerir o processo de gestão de vulnerabilidades, colaborou para pensar fora da caixa e aprender (com os erros) a criar novas estratégias e processos para driblar o desconhecido. Sendo assim, gostaria de compartilhar algumas dicas para gerir um processo de gestão de vulnerabilidade.
Ressalto que a ajuda de frameworks e standards como ISO 27001, PCI-DSS, OWASP, CyberSecurity NIST, etc, irão viabilizar a construção de um processo eficaz e eficiente. Na última semana o Conselho Monetário Nacional do Banco Central tornou vigente a Resolução nº 4.658, de 26/4/2018, que determina uma política de segurança cibernética para todas as instituições financeiras, é evidente que este é mais um elemento para fortalecer o mercado de segurança no Brasil, mas vamos lá com as dicas:
Lista de ativos atualizadas
Tenha em mãos a lista atualizada de todos os ativos de tecnologia da organização incluindo: Sistema Operacional, Aplicações internas e externas, websites com frontend, Internet, mobile applications, Database, software de gerenciamento web, versões de virtual machine, appliances (firewall, IPS, network devices, monitoramento de câmeras) e assegure que todos estão inclusos no processo de gestão de vulnerabilidades.
Classificação de ativos
Todo ativo tem dado, ainda mais agora na era de Big Data, no mais é necessário determinar níveis de classificação da informação nestes ativos, pois irá te ajudar a determinar os requerimentos de segurança para os projetos, sistemas, etc.
Processo e Ferramenta para Gestão de Patches
Assegure que um processo e política de gestão de vulnerabilidades esteja vigente e atualizada. Caso ainda não há possua elabore imediatamente. Use frameworks e standards como o CyberSecurity NIST, ISO 27001, se for do meio bancário a própria Resolução nº 4.658 já determina este requisito. Quanto a ferramenta para gerir o processo, tem inúmeras; a própria Microsoft oferece uma gratuita, seja criativo use planilhas automatizadas ou desenvolva internamente uma ferramenta com painel para consolidar os riscos se o orçamento for curto. Soluções de mercado oferecidas por players de segurança já oferecem um painel atualizado com as vulnerabilidades e CVEs divulgados na comunidade e isso acaba economizando tempo, em vez de ficar consultando diversos sites e analisar boletins de fabricantes. Vale lembrar que sua política precisa ter um critério e matriz de classificação de risco e vulnerabilidade de acordo com os requerimentos do business e relevância.
Suporte do senior management
É vital o suporte da alta administração e, você, como um líder, precisa ter os executivos como parceiros sabendo transmitir a importância dos riscos para a organização. Geralmente dependendo da estrutura da empresa, a TI é responsável por corrigir a falha e aplicar patches. Entretanto, aqui poderá ser o seu calcanhar de Aquiles se você não tiver este grupo como seu parceiro. Lembre-se que uma empresa de Retail não vai querer parar o ambiente para instalar um patch, pois não pretende perder dinheiro, mas é necessário encontrar janelas para remediar a situação. Aqui você precisar ser capaz de talvez usar ferramentas de análise de risco qualitativa e quantitativa para dar visibilidade ao senior management a importância de corrigir o ambiente. Para bancos, com as exigências do Banco Central torna o processo mais acessível.
Conscientize e treine os desenvolvedores
Conscientizar continua sendo a chave principal para convencer e ganhar um parceiro de segurança na sua organização. Tenha foco total em conscientizar principalmente a equipe de TI e DevOps e faça entender que são responsáveis e fazem parte do contexto e que a segurança deve ser levada por todos. Treine sobre o OWASP, secure code, code review, etc e assegure que um processo de SDLC seguro esteja contínuo.
Code Review e Scan de Vulnerabilidades
A tecnologia está cada vez mais avançada e você precisa garantir que a equipe de desenvolvimento esteja preparada, invista em treinamento para desenvolvimento de software seguro, certificações como CSSLP da (ISC)², pentest (OSCP) a nível de aplicação e tenha ferramentas de scan que sejam capazes de checar falhas na camada de aplicação e código incluindo OWASP Top 10 e code review. Lembre-se que uma scan de rede/sistema não é capaz de checar falhas em aplicações web e soluções existem diversas tanto como free e pagas.
Equipe especializada
O time de segurança precisa entender e saber o que está fazendo, tenha profissionais que pensam como um hacker, explore e aprenda com programas bug bounty de gigantes da computação se for aplicável. Ter um colaborador com uma expertise de pentest é valioso.
Cuidado com os Third Parties
Assegure que o processo de gestão de fornecedores está cobrindo todos os parceiros de negócios, cloud providers e provedores de serviços e garanta que o processo de gestão de vulnerabilidades está presente. Se o processo for falho fique de olho e exiga que seja implementado antes de ir para produção.
Introdução da visão na avaliação de riscos de projetos
Introduza no processo de avaliação de risco em projetos a importância de verificar que o sistema, aplicação e/ou ambiente esteja atualizado com o processo ativo dependendo da estrutura na sua empresa. O ISO precisa sempre olhar este processo com prioridade e casar com o processo de gerenciamento de risco e inclua também a avaliação de fornecedores. Certa vez identifiquei um appliance de monitoramento de câmera (CFTV) que rodava na plataforma Windows sem gestão de patches, hardening e sem suporte.
Checklist de segurança ou hardening
Este é um procedimento técnico simples que muitos não fazem. Trocar a senha default de um roteador e configurar adequadamente um servidor web é vital para sobrevivência. É necessário que todo o parque tecnológico possua um procedimento de segurança escrito, formalizado e atualizado pela equipe responsável.
As dicas acima irão ajudar a construir um bom processo de gestão de patches, mas não esqueça de ter uma foto da situação atual da empresa em termos de maturidade de segurança e mais a visualização dos processos críticos de negócios, mapeados por meio do Business Impact Analysis (BIA), que irão contribuir para definir uma boa política e focar no coração da sua organização. Além disso, não confie em todas as soluções de segurança, já houveram ataques criptografados que alguns Web Application Firewall (WAF) não identificaram, sendo assim, a chave é manter-se atualizado, participe de conferências e esteja atento ao que a comunidade hacker está falando.
Em resumo, a forma de aplicar este processo vai variar de empresa para empresa. Se perceber que o desafio seja impossível de alcançar e, mesmo usando habilidades distintas, para convencer a liderança sobre aplicar ou não um patch, talvez esta não seja uma empresa comprometida com a matéria de segurança cibernética, ou a escolha não foi tão certa e está na hora de quebrar o paradigma, seja para mudar a consciência dos executivos ou mudar de companhia. Good luck!
Este artigo foi publicado no portal Security Report.
* Rangel Rodrigues é especialista em Segurança da Informação, CISSP e pós-graduado em Redes de Internet e Segurança da Informação pela FIAP e IBTA, e MBA em Gestão de TI pela FIA-USP
Comentários
Postar um comentário