0
0
A DevOps assumiu em grande parte o mundo do desenvolvimento de software corporativo. O mashup de desenvolvimento de software e operações de TI trouxe versões de software mais rápidas e desenvolvimento de aplicativos mais responsivo para muitas organizações. E sabemos a grande questão que sobrou na mente de todos: Que lições a segurança de TI pode aprender com tudo isso?
Agora, algumas organizações aprenderam a lição de que queriam envolver a segurança em toda a bondade de DevOps, então o DevSecOps nasceu. Mas este artigo é sobre as lições que a equipe de segurança pode aprender mesmo que não estejam prontas para serem completamente assimiladas nas organizações de desenvolvimento e operações. Há coisas que devOps puros fica certo – coisas que podem tornar o grupo de segurança melhor?
A resposta, em muitos casos, é “claro que existem”. Não há dúvida real de que o ambiente de negócios muda mais rapidamente do que era antes, e 2020 levou para casa a lição de que mudanças profundas podem ser necessárias em um cronograma intensamente curto. O hewing para a disciplina DevOps ajudaria quando essas mudanças rápidas são necessárias? Vamos descobrir.
As meia dúzia de lições desta lista foram compiladas a partir de nossa pesquisa sobre como desenvolvedores de software e profissionais de segurança estão usando conceitos de DevOps, conferências ágeis e devOps que participamos e conversas com profissionais de segurança no último ano. Elespodem ser considerados por qualquer equipe de segurança de TI, independentemente da filosofia de segurança de sua organização. A maioria pode ser adotada sem alterar fornecedores ou ferramentas, e a maioria nem precisaria de um re alinhamento radical com outros grupos de TI. O que eles exigem é estar disposto a ver a segurança de uma perspectiva diferente – uma que coloca agilidade e capacidade de resposta no mesmo nível que a maioria das outras prioridades de segurança e reconhece que proteger contra a ameaça de hoje é tão importante quanto proteger contra o perigo do ano passado.
Segurança é Software
O que significa tratar tudo como software? No contexto de DevOps e segurança, ele pode ajudar se você pensar sobre segurança de TI e métodos modernos de desenvolvimento de software. Quebre-o, e faz muito mais sentido.
O desenvolvimento moderno de software (e por extensão, software moderno) é o produto de muitos módulos, bibliotecas e componentes diferentes reunidos para fazer um todo significativo. O autor de qualquer componente em particular é muito menos importante do que se o componente é adequado para a tarefa em mãos, confiável e devidamente controlado para compatibilidade e segurança. Isso significa que a segurança pode ser construída a partir de componentes “melhores da raça” que se reúnem através de APIs e protocolos padrão, implantados na configuração que faz mais sentido para a organização. E esses não são os únicos benefícios.
Talvez a característica mais importante da segurança como software seja que quando um único componente muda para atender ao cenário de ameaça em mudança, ele pode ser atualizado sem exigir uma mudança por atacado na infraestrutura de segurança. Assim como alguns aplicativos em nuvem agora vêem várias versões enviadas todos os dias, uma infraestrutura de segurança modelada por software pode mudar tão rapidamente quanto os atores de ameaças exigem, sem o perigo de reconfigurar e reiniciar toda a pilha de segurança.
Segurança deve correr
As equipes de segurança tradicionalmente costumavam configurar para o teste anual de penetração, seguidas de uma autópsia, planos, revisões e, finalmente, mudanças em ferramentas e táticas. Quando os atacantes estavam em um horário bastante relaxado, este era um grande plano. Permitiu uma consideração cuidadosa de cada mudança, entrada de todos os envolvidos e testes rigorosos antes de qualquer implantação. Também era glacial em seu ritmo. Hoje, as geleiras estão recuando e o plano deve mudar a segurança uma vez a cada 12 meses ou mais.
Os sprints usados pelos desenvolvedores de software permitem mudanças bem definidas e de pequeno alcance em um ritmo rápido. Com uma meta definida e duração definida (que pode ser de um dia a algumas semanas), os sprints podem oferecer às equipes de segurança uma disciplina para responder a CVEs únicos, novas técnicas de ataque ou revisões para malware.
A grande lição do sprint é que toda mudança não tem que lidar com todas as questões. Permitir que os membros da equipe se concentrem em um único problema de cada vez e lidem bem com isso significa que, ao longo de um mês, um quarto ou um ano, muitas falhas de segurança são corrigidas sem que nenhum deles tenha que esperar por um longo ciclo de atualização e revisão.
Construir uma cadeia de ferramentas de segurança
Uma das marcas da metodologia ágil de desenvolvimento na qual tanto DevOps se baseia é que ele enfatiza indivíduos e interações sobre processos e ferramentas. Tudo bem, mas o fato é que as ferramentas são necessárias para implementar até mesmo uma disciplina orientada para as pessoas. Em DevOps, isso significa construir uma cadeia de ferramentas para apoiar a disciplina em vez de depender de uma única ferramenta na qual cada interação e processo humano deve se encaixar.
A abordagem modular do desenvolvimento, quando aplicada à segurança, significa que haverá uma série de ferramentas – uma cadeia de ferramentas – para defender várias partes da infraestrutura e do processo de negócios, em vez de uma única ferramenta de segurança que tenta fazer tudo. A vantagem dessa abordagem é que a melhor ferramenta pode ser selecionada para cada componente e etapa de processo a ser defendida. A desvantagem é que ele tende a levar a um ambiente de segurança muito mais complexo do que aquele que depende de um único fornecedor ou ferramenta.
Isso não significa que os membros da equipe de segurança estão condenados a manter o controle de 27 monitores diferentes em suas mesas. Existem SIEMs (gerentes de incidentes de segurança e eventos) e consoles de segurança que podem gerenciar e orquestrar amplas faixas de segurança corporativa. Isso significa, porém, que as equipes de segurança precisarão estar conversantes em várias interfaces e ferramentas diferentes para serem seguras. A boa notícia é que mudanças nas configurações e implantações podem ser gerenciadas em sprints, de modo que apenas um precisa ser tocado de cada vez.
Implantação contínua
No método de desenvolvimento de cachoeiras que uma vez definiu o software corporativo, a implantação foi um único marco. Uma vez implantado, o aplicativo foi entregue às operações e a equipe de desenvolvimento comemorou outro sucesso estrondoso. Da mesma forma, na segurança, a implantação foi um evento em que havia uma data “go-live” para novos hardwares ou softwares. Uma vez implantadas, as ferramentas seriam monitoradas e usadas, mas só mudariam de forma programada e bem considerada. Não é mais.
A implantação contínua significa que cada componente em uma infraestrutura de segurança está sujeito a alterações no final de qualquer sprint. Se uma nova ferramenta ou tática de ataque aparecer, as ferramentas serão rapidamente reconfiguradas e reimplantas em resposta. Nunca há qualquer “estado de descanso” para a defesa- tudo está operacional e esperando para ser reconfigurado para o mais novo cenário de ameaça.
Alguns profissionais estão inquietos com uma infraestrutura de segurança que nunca é concluída. Isso significa que não há “fundação” de hardware ou software que seja uma rocha imutável na qual a defesa é construída. Em vez disso, tudo está em um estado constante de redesenvolvimento e reconfiguração, mudando tão rapidamente e com tanta frequência quanto os atacantes exigem. Para os profissionais de segurança, porém, isso é uma boa notícia, pois significa que as vulnerabilidades de zero-day têm muito poucos dias para serem exploradas e novos ataques se tornam notícias antigas muito rapidamente.
Ouvir/Contar as Histórias
Gostaria de ouvir uma história? Histórias – simples declarações de resultado desejado contadas no idioma do usuário – são a base para melhoria e desenvolvimento em DevOps. A ideia de histórias deve fazer parte da prática de segurança que desenvolve novos processos, tecnologias, políticas e planos de treinamento para o empreendimento.
O que precisa ser protegido? Porque? O que acontece se não estiver protegido? E que tipo de processo de negócio (ou produtividade humana) deve interromper a proteção? Estes são todos os tipos de perguntas que uma história deve responder. E aqui está a peça crítica: Essas perguntas devem ser respondidas por uma história de usuário porque são os indivíduos que entendem o impacto nos negócios da segurança solicitada.
O ponto mais importante das histórias no DevOps é evitar que os desenvolvedores de software restrinem os usuários a processos improdutivos. Em segurança, o objetivo deve ser infligir atrito mínimo de processo em usuários legítimos, ao mesmo tempo em que imponha o máximo de atrito aos atacantes. Se a segurança não abordar o problema do ponto de vista do usuário — não ouvir a história do usuário — então o resultado provavelmente será o máximo de atrito no processo dos usuários com impacto mínimo sobre os atacantes.
Testes contínuos, melhoria contínua
O objetivo final dos devops é levar a TI corporativa para a evolução contínua e melhoria. Idealmente, incorporar conceitos DevOps em segurança corporativa aproxima todo o caso dos ideais da Six Sigma do que do processo bastante confuso de evolução. Para chegar lá, porém, requer que o desenvolvimento constante incorpore melhoria constante verificada por testes constantes.
Entende-se que o teste é um processo caro e disruptivo, especialmente quando o teste em questão é algo como um teste de caneta em toda a empresa. Embora essas principais verificações do sistema sejam críticas, eles não são os únicos testes que importam. Assim como os sprints se concentram em características únicas ou vetores de ataque, os testes podem ser estritamente focados e ainda serem de uso significativo.
Os profissionais de segurança devem ser instados a incorporar testes rigorosos como parte de seu processo de implantação, assim como os desenvolvedores de software incorporam testes como parte dos deles. Idealmente, os testes devem envolver os mesmos usuários cujas histórias foram usadas para construir os processos, políticas e técnicas aprimoradas na implantação. A construção cuidadosa de melhoria contínua no sistema dá à infraestrutura geral a maior chance de se tornar melhor em uma base consistente do que nos ajustes e partidas que permitem muito espaço para os atacantes passarem.
FONTE: DARK READING