0
0
Como arquiteto-chefe e co-fundador de uma empresa de segurança de aplicativos, acho que uma parte importante da jornada de startup está refletindo sobre a evolução tanto no meu desenvolvimento pessoal quanto no meu setor em geral. Em 2008, quando o PCI-DSS se tornou um elemento de negócios integral para as empresas em Israel, participei de muitas certificações iniciais e testemunhei a luta que as empresas tiveram em se tornar compatíveis.
Meu papel principal envolvia as partes do PCI relacionadas às aplicações, incluindo testes de penetração. Enquanto me sentava nos escritórios de um dos maiores prestadores de cuidados de saúde de Israel uma tarde, lembro-me de revisar uma lista tediosa e aparentemente interminável de perguntas, o que deixou nossa equipe cada vez mais intrigada. Em vez de obter insights e informações, lembro-me de sair do escritório com mais perguntas do que respostas.
Uma coisa ficou muito clara para mim a partir dessa experiência: os critérios que os padrões de segurança esperavam que as empresas cumprissem não eram viáveis. Eles não foram realistas em 2008, e eles não são realistas hoje. O padrão PCI-DSS exigia coleta abrangente de evidências e avaliação excessiva e multidisciplinar de todos os ativos em escopo. A indústria levou anos para adotar a estratégia adequada para lidar com os requisitos do PCI-DSS, que era isolar o ambiente de PCI e reduzi-lo ao mínimo.
Um Buzzword
Não é coincidência que, ao mesmo tempo, o ciclo de vida de desenvolvimento de software seguro (SSDLC) se tornou a nova palavra de ordem da indústria. Ao anexar segurança a cada etapa de desenvolvimento, sua premissa fazia sentido: garantir o envolvimento da segurança desde o início, a fim de minimizar erros e garantir o processo de desenvolvimento. O SSDLC tornou-se o “go-to” para muitos, devido ao aumento da migração em nuvem e à adoção em larga escala de aplicativos móveis. Ele até sobreviveu a DevOps liberando o poder de, bem, DevOps e metamorfoseando SSDLC para o loop de entrega e operação infinita que usamos hoje.
Quando as iniciativas de privacidade atingem o acelerador total, todos nós testemunhamos novamente o quão difícil era (e ainda é) para as empresas dominar padrões de controle como o GDPR. No entanto, desta vez, minimizar o escopo não era uma opção. De repente, muitas equipes experimentaram em primeira mão o impacto da má concepção e da dívida de segurança quando lutaram para atender aos novos requisitos regulatórios.
Para aqueles de nós que têm feito cócegas e cutucado nas últimas duas décadas, isso não é uma surpresa. Apesar das melhores intenções, é impossível instrumentar a segurança em todas as etapas de todos os projetos, e é cada vez mais difícil criar aplicativos resilientes a hackers avançados (e testadores de penetração). Honestamente, é desafiador o suficiente para construir aplicativos sem bugs ou tempo de inatividade, por isso as expectativas dos reguladores e da indústria em geral devem ser ajustadas.
Simplificando, não há recursos humanos suficientes para lidar, e os desenvolvedores estão muito ocupados para serem incomodados. Surpreendente ou não, essa lacuna incorpora a relação disfuncional entre a segurança e o desenvolvedor.
Entrando em seus hackers
Hackers de elite como aqueles por trás dos ataques do SolarWinds, entre na mente do desenvolvedor e crie uma jogada sofisticada que explora pontos fracos na fabricação de software. Hackear aplicativos é a busca por erros que os desenvolvedores são obrigados a cometer.
Idealmente, com treinamento adequado, comunicação interna eficaz, design de segurança e rigorosos processos de teste, esses erros serão limitados, restringindo o impacto. Mas, como todos sabemos, a vida real nem sempre se alinha com as defesas mais rigorosas.
Grandes desenvolvedores não pensam em segurança. Os desenvolvedores pensam em recursos, prazos, dimensionamento e velocidade. Os desenvolvedores pensam em termos de incidentes de produção e tempo de inatividade. Mas, acima de tudo, os desenvolvedores são fabricantes, e é preciso experiência, intenção real e tomada de decisão ativa para permitir que a segurança entre em sua zona criativa.
Os profissionais de segurança muitas vezes subestimam a quantidade de esforço que os desenvolvedores investem na proteção de suas aplicações. Os desenvolvedores implementam constantemente diferentes camadas de resiliência a erros e falhas e são constantemente barrados por inúmeros requisitos de produto, sucesso do cliente, marketing e todos os outros stakeholders da organização.
Wolf
Um dos meus projetos implicava a construção de um programa escalável para uma empresa com mais de mil desenvolvedores. Depois de um processo de tributação e horas de discussões, finalmente concordamos em um acordo de nível de serviço de segurança. Um engenheiro chefe sorriu e disse, na minha direção: “Veja, a segurança gosta de ter o centro do palco!” Eu rapidamente entendi que a segurança sempre desempenhará o papel de lobo chorão, quer pretenda ou não.
Por outro lado, quando você mostrar aos desenvolvedores essa vulnerabilidade de zero-day, todo mundo vai chorar “Fogo!” e certifique-se de apagá-lo. Apesar do que os desenvolvedores podem acreditar, algumas vulnerabilidades apresentam uma ameaça real e potencialmente debilitante à continuidade dos negócios. É por isso que eles precisam de segurança, quer gostem de admitir ou não.
Então, aqui está a linha de fundo: o ciclo de vida de segurança não é o ciclo de vida de um desenvolvedor. Atividades como modelagem de ameaças e testes de penetração são cruciais para o nível de segurança, mas exigem muitos recursos mais difíceis de escalar. Especialmente quando se opera em um modelo SSDLC, a sobrecarga de gerenciamento irá atrasá-lo ainda mais. Por outro lado, embora a automação simples com testes de segurança de aplicativos seja uma estratégia eficaz para coletar feedback quantitativo em relação ao seu software, é improvável que seja adotada pela organização sem uma governança rigorosa ou uma cultura de segurança abrangente.
A segurança opera em alinhamento com o ciclo de vida de desenvolvimento de software, mas também se estende além dele. Isso permanece verdadeiro, pois a equipe do AppSec continua desafiando todos os aplicativos, incluindo aplicativos legados. O AppSec vai além do próprio código para avaliar a composição do software, os pipelines de CI e o tempo de execução. O AppSec atua para avaliar as mudanças que seus desenvolvedores fazem, mas também presta atenção continuamente a novos ataques e vulnerabilidades, independentemente de o desenvolvimento acontecer internamente.
A AppSec tem seu próprio ciclo de vida. E é diferente de um desenvolvedor.
FONTE: DARK READING