Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA
Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?
Há muitas lições de segurança que podem ser aprendidas nos dias que cercam a violação da Equifax em março.
Três dias em março de 2017 surgiram continuamente em conversas do DevSecOps que li em foruns da comunidade Cloud e DevSecOps. Enquanto a maioria das pessoas amarra os três dias que antecederam o dia 10 de março à violação da Equifax, eu gravei tudo de uma forma muito diferente.
Primeiro, enquanto a Equifax foi violada em 10 de março, devido ao uso de componentes Struts vulneráveis conhecidos, eles não foram os únicos violados naquele dia. Adicione o GMO Payment Gateway do Japão, o Canada Revenue Service e o Canada Statistics à lista. Saia por mais três dias até 13 de março e você poderá adicionar o Japan Post e o Okinawa Power. Um mês depois, o India Post também foi violado. Tudo resultou do uso de versões conhecidas de Struts vulneráveis.
Agora, deixe-me mapear isso de volta para as práticas do DevSecOps. Três dias em março de 2017 surgiram continuamente em conversas do DevSecOps que li em foruns da comunidade Cloud e DevSecOps.
De acordo com o mais recente relatório Accelerate: State of DevOps da DORA, 7% das organizações de DevOps podem implantar sob demanda várias vezes ao dia.
O prazo para mudanças nessas mesmas organizações é inferior a uma hora. Em teoria, se uma dessas organizações descobrisse a vulnerabilidade do Struts em 7 de março e soubesse onde elas estavam usando as versões ruins, elas poderiam implantar rapidamente as alterações em seus ambientes de produção – ficando à frente de seus adversários.
Além dessas organizações de DevOps de “elite” estão os 48% conhecidos como “de alto desempenho”. Dado o mesmo conjunto de circunstâncias, essas organizações podem implantar mudanças entre um dia e uma semana. Se eles podem se mover mais rápido que três dias, eles estão à frente dos adversários.
Se for mais lento que três dias, eles correm risco. Todas as organizações fora da “elite” e “de alto desempenho” estão sempre em risco porque não podem implantar mudanças mais rapidamente do que seus adversários. Por isso que o modelo de varias mudanças simples e poucas complexas é adotado pela NetFlix, Uber, etc…
Este não é um problema novo. De fato, no 4º Relatório Anual da Cadeia de Fornecimento de Software, divulgado hoje pela Sonatype, mostramos que o tempo médio entre descoberta e exploração de vulnerabilidades foi reduzido em 93,5% – ou quatro vezes – nos últimos anos. Além disso, o relatório também aborda situações em que os adversários injetam vulnerabilidades conhecidas em versões de código aberto para torná-las exploráveis no segundo em que são implantadas.
Em 2017, pode-se considerar “três dias” como a nova normal para o lead time das mudanças no DevSecOps. Em 2018, essa janela fechou para “um segundo”. Os adversários não são apenas espertos, mas também são rápidos e criativos.
Não se engane, sua organização pode se proteger com as práticas corretas, cultura e ferramentas para apoiar sua iniciativa DevSecOps. Mas perceba, a barra está sendo definido mais alto a cada ano – não apenas por seus próprios membros e líderes de equipe -, mas por aqueles que podem causar estragos em sua reputação e clientes bem merecidos.
Convido-o agora a ler o Relatório da Cadeia de Fornecimento de Software 2018/2019 da Sonatype, que lançará nova luz sobre o DevSecOps e as práticas de desenvolvimento de código aberto que afetam sua organização.
Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?
