Os Softwares vêm dominando o universo corporativo e são muitas vezes diferenciais neste mundo cada vez mais competitivo. Sendo assim, softwares e seus desenvolvedores estão em sua maioria inseridos em uma cultura ágil – e historicamente segurança com a agilidade não têm sido muito companheiras.
Você também pode ouvir esse conteúdo:
Além disso, a segurança tem tido cada vez mais destaque, porém os profissionais de segurança têm ficado gradualmente mais desatualizados no entendimento e compreensão da cultura ágil, criando uma lacuna assustadora na indústria.
Sendo assim, aqui falaremos um pouco sobre as discordâncias entre agilidade e segurança, citando pontos em que isso pode ser evitado, trazendo harmonia entre ambos.
Agilidade
A ideia fundamental por trás da agilidade é cultura. O grande diferencial da agilidade perante as demais metodologias é o foco na constante entrega de valor para o cliente.
Vamos imaginar um sistema com um simples CRUD (Create, Read, Update, Delete) de produtos. A partir dessa ideia, criamos um backlog, ordenado por grau de valor para o cliente – e suponhamos que seja o mesmo CRUD, onde cada ação seria uma história.
Então na planning, nossos desenvolvedores chegam à conclusão de que conseguem entregar uma funcionalidade a cada sprint. Portanto, entregariam o Create, depois Read, em seguida o Update e por fim o Delete.
Ao final de uma sprint, normalmente duas semanas, o cliente conseguiria cadastrar mercadorias. Entretanto, vamos supor que após terminar o Create, o cliente dá uma olhada no mercado em que está inserido e detecta que, melhor do que realizar o Read, Update e Delete de produto, é ter o Create de Clientes.
E que, assim sendo, na sprint seguinte, será feito o Create de Clientes e não o Read de produtos.
Na agilidade, essa mudança é muito bem aceita.
Agora se estivéssemos no mundo sem agilidade? O produto seria entregue apenas após todas as funcionalidades estarem “prontas” e o cliente só perceberia que ele precisa de um “Create” de clientes após esse final, podendo assim perder o “time to market”.
Outro fator que merece ênfase na agilidade é feedback constante. Então, ao final de cada sprint, a equipe se organiza em uma cerimônia de “retrospectiva”, onde é discutido o que foi bom, o que não funcionou e o que é possível melhorar. Assim, na sprint seguinte, é possível colocar em prática essas melhorias. Veja quanto valor a agilidade entrega em apenas uma sprint!
Segurança da Informação
A segurança, em sua maioria, continua com os processos e práticas de projetos em “Cascata”, com requisitos definidos antecipadamente para o sistema como um todo: políticas, documentos, wikis gigantescas. Mas qual o problema disso tudo?
Vejamos os princípios da agilidade:
- INDIVÍDUOS E INTEGRAÇÕES vêm antes de processos e ferramentas;
- SOFTWARES EM FUNCIONAMENTO vêm antes de documentação abrangente;
- COLABORAÇÃO COM O CLIENTE vêm antes de negociação de contratos;
- RESPONDER A MUDANÇAS vêm antes de seguir um plano.
Basicamente, vemos agilidade de um lado e segurança do outro, e esse jogo precisa mudar! A segurança precisa tornar-se um facilitador ao invés de um bloqueador.
Vamos a um exemplo – um desenvolvedor traz uma solução genial que irá agregar muito valor ao produto. Quando ele a apresenta, o pessoal de segurança responde com a seguinte frase: “Não podemos implementar, pois isso irá nos trazer a vulnerabilidade A, B e C”.
E se ao invés disso, o time de segurança tivesse a seguinte ótica: “Que ótima solução! Do ponto de vista de segurança podemos desenvolver, mas para isso, precisamos implementar os controles A, B, C”. Está claro como a abordagem foi totalmente diferente – vemos a segurança parceira e inserindo os controles necessários.
Como mudar o jogo?
Precisamos estreitar o relacionamento, pois DevSecOps também é cultura, que envolve muita interação e facilitar a interação entre as equipes é fundamental para garantir que a segurança não dificulte as entregas, lembrando que as entregas em um time ágil são constantes.
A segurança precisa fornecer orientação rápida e informal, além de respostas a perguntas por meio de mensagens instantâneas ou plataformas de bate-papo, e-mail e, sempre que possível, pessoalmente.
Uma forma de promover esse estreitamento é com as participações nos rituais de agilidade. No momento de criação das histórias pelo PO é fundamental haver alguém com uma visão de segurança para sugerir requisitos de segurança. No refinamento, esses requisitos de segurança serão discutidos junto com os requisitos funcionais, retirando o que não se aplicar e adicionando o que foi esquecido na fase de criação das histórias.
Essas fases são de extrema importância para a segurança da informação, pois nelas serão tratados os requisitos de segurança inerentes à história em questão, não faz sentido uma história ter, por exemplo, 10 requisitos funcionais e 200 requisitos de segurança. Novamente: requisitos realmente precisam fazer sentido para aquela história.
Inserindo o pensamento ágil
A ideia de uma sprint focada somente em requisitos de segurança normalmente não é eficiente, pois significa que o produto, em um primeiro momento, teve sua entrega sem requisitos de segurança, ou seja, foi para produção sem requisitos de segurança e em seguida houve uma sprint para inseri-los, cuja implementação não foi feita em uma sprint inicial. Então o ideal é inseri-los junto com os requisitos funcionais, por isso é primordial definir os requisitos apropriados em cada história.
Na daily, onde o estado da história é analisado, a equipe de segurança deve estar atenta a questões levantadas que possam afetar a segurança e privacidade – no caso de histórias que tenham importância para a segurança, o progresso dessa história precisa ser monitorado.
Durante o desenvolvimento, ter alguém com uma sólida experiência em segurança para realizar “pair programming”.
A segurança também deve estar envolvida nas reviews e retrospectivas, para entender o que foi realizado e os desafios que a equipe enfrentou.
Security Champions
Acima foram listadas algumas ações que poderiam estreitar o relacionamento entre Segurança e Desenvolvedores em um time de agilidade, porém há uma problemática, seria necessário um profissional de segurança à disposição dos times em tempo integral ou quase isso. Outro fator é que, na metodologia ágil, os times precisam ser “autônomos” e depender de uma pessoa de outro time reduz um pouco essa autonomia. Os Security Champions podem resolver esse problema, uma vez que seria um integrante do time, ou as vezes, até mais de uma pessoa, pois a segurança precisa ser tratada por todos, lembrem, a palavra chave aqui é cultura.
Conclusão
Conforme foi visto, existem muitas divergências entre desenvolvedores imersos na agilidade e profissionais de segurança ainda tratando software como projetos Waterfall. Levando em consideração que DevSecOps é uma cultura, assim como a agilidade, os especialistas de segurança podem usufruir da experiência dos ‘agilistas’ em estabelecer essa cultura dentro de seus times e com isso implementar uma cultura de Segurança dentro dos times de desenvolvimento.
Nos próximos artigos iremos falar sobre como OWASP SAMM Agile pode ajudar nessa missão e depois nossas experiências na adoção do framework OWASP SAMM com agilidade.
Autores:
Tiago Zaniquelli – AppSec Specialist
Luciene Oliveira – AppSec Consultant
