São inúmeras palestras e promessas milagrosas. Pessoas citam os touchpoints de Gary McGraw e o processo de SDL da Microsoft como se fossem íntimos e tenham implementado em vários cenários e organizações, sem contar a falácia da ISO/IEC 15.408, que muitos acreditam cegamente ser uma proposta para segurança em desenvolvimento.
Tudo isto para buscar ser "cool" e/ou tentar abocanhar uma fatia de um mercado que vem surgindo. A pesquisa, o estudo e disseminação de conhecimento são super importantes, mas que, os que se aventuram pelo tema tenham convicção de uma coisa: não é nenhum pouco simples e fácil implementar e ter bons resultados com processos de SDL.
Wagner, você está traindo "o movimento"? Você não acredita mais em segurança em desenvolvimento?
Muito pelo contrário, acredito e muito, mas sei muito bem o caminho a ser percorrido e as dificuldades que encontrarei. Há pelo menos cinco anos eu estudo e vivencio como consultor, a realidades das organizações frente à segurança de software.
Muitas organizações não conseguem justificar mais uma área de desenvolvimento interno, como irão justificar o investimento em segurança de software? Os sábios logo dirão: Cobre do fornecedor o processo de SDL.
Sim, você pode cobrar do fornecedor, só não se assuste se o seguinte cenário lhe for apresentado: Eu cobro R$ 500,00 por hora de desenvolvimento, com segurança eu preciso incluir um pequeno adicional, fica R$ 600,00 por hora.
Como diria o Zé: não existe almoço grátis! Alguém tem que pagar a conta.
Como equacionar esta dificuldade de justificar e conscientizar as empresas a investir recursos em segurança em desenvolvimento?
Não existe resposta pronta, sugestões como: conscientize, treine, mostre o ROI, etc... Servem para uns e não servem para outros. Se eu pudesse sugerir algo, eu começaria pelo básico, não acredite em soluções milagrosas, não acredite em quem lhe promete entregar o que você não conseguiu a vida toda em um mês de trabalho e ao preço de um almoço.
Um processo como este leva tempo e no mínimo os seguintes aspectos devem ser considerados:
- Compliance é o mínimo do requerido, não espere que esta demanda justifique o processo de segurança em desenvolvimento;
- Identifique de que maneira a sua organização é afetada pela insegurança de software;
- Tenha ciência que a maioria dos impactos relacionados a incidentes envolvendo falhas de software impacta indiretamente a organização e os valores são intangíveis. A famosa fórmula de ROI pode não lhe ajudar nestes cenários;
- Envolva todos no processo, não seja apenas o auditor que aponta as falhas e cobra uma solução;
- Não trate um processo de SDL como um projeto que você desenvolve meia dúzia de documentos e está feito. Busque a melhoria contínua, crie e acompanhe métricas que possam viabilizar e melhorar o processo.
Com estes pontos você terá muito trabalho, a parte fácil é desenhar os fluxos e escrever cartilhas e procedimentos.
[Update - 25 de Setembro] O Fernando Cima escreveu um post com excelentes referências para quem deseja implementar um SDL: Retorno Sobre o Investimento de um Processo Seguro de Desenvolvimento
2 comentários:
Wagner, a maior dificuldade é que muitas organizações não tem sequer um processo de desenvolvimento de software. Não dá para tornar seguro algo que não existe... ;)
Vish, esqueci de incluir um tópico:
1 - Primeiro tenha um processo de desenvolvimento de software.
:)
Postar um comentário