DevSecOps requisitos seguranca evil stories
No primeiro post da série eu abordei de forma geral “o que é o DevSecOps” e o que devemos fazer. Agora vamos entrar em como realmente fazer isso.
Bom por princípio todo time que está desenvolvendo algo utilizando metodologias ágeis possui um backlog de coisas que devemos fazer. Se estamos falando em trazer a equipe de segurança para o início do projeto eles tem que ser envolvidos também no backlog e com isso adicionar suas histórias.
Imagina que nossa aplicação é igual nosso filho, nós queremos sempre o melhor para ela, então precisamos desde cedo pensar na sua segurança. Para isso precisamos também adicionar no nosso backlog histórias que contemplem informações específicas da segurança desse novo sistema ou funcionalidade que estamos adicionando.
Essas histórias são conhecidas como Evil Stories.
Mas temos que tomar cuidado. Alguns itens relacionados a segurança não devem ser tratados como evil stories, como por exemplo: XXS, Injeção de comandos SQL, Injeção de comando de S.O., tentativas de força bruta entre outras. Esses são requisitos não funcionais que podem ser endereçados de outras maneiras que veremos a frente, como por exemplo treinamentos de desenvolvimento seguro, ferramentas de análise estática de código, ferramentas de teste de penetração.
Com as evil stories nós temos que colocar validações que o time de segurança poderá desenvolver especificamente para essa aplicação. E elas devem ser pensadas como um invasor.
E ideia principal é pensar como o alguém que quer danificar o sistema.
Essa pessoa pode ser um hacker, alguém que quer fraudar algum processo do software, pessoa que quer danificar o sistema, um administrador de S.O. que tem um privilégio maior e acidentalmente pode criar problemas para o sistema e até mesmo um sistema externo que pode nem sempre se comportar de maneira esperada.
E com isso deveremos traçar as atividades a fim de validar que o sistema não sofra desses ataques. Essas atividades compreendende desde desenvolver alguém método de segurança como também implementar testes que sempre validem o tipo de invasão identificado.
Um modelo que podemos usar seria:
Como (alguém que quere invadir/danificar o sistema) Eu não posso fazer (alguma coisa ruim)
Exemplos:
Como um Hacker, eu gostaria de roubar os cartões de crédito dos usuários para que eu possa vender no mercado negro
Como um Hacker, eu gostaria de invadir a conta de um usuário específico para que eu possa ter acessa a informações detalhadas do negócio.
Como um Hacker, eu posso enviar um cabeçalho HTTP com dados inválidos para que eu possa acessar funcionalidades e dados que eu não tenho acesso.
Como um Hacker, eu posso enviar dados inválidos na URL para acessar dados ou funcionalidades que eu não tenho acesso.
E agora você me diz: Já tinha pensado em usar esse tipo de histórias para melhorar o sistema?!
Espero que tenha gostado e se tiver alguma dúvida específica me manda um e-mail ou deixe nos comentários.
Até a próxima, Claudio Romão
-
Tags:
- DevSecOps
- Requisitos
- DevOps
24/05/2020 | Por Claudio Romão | Em Técnico | Tempo de leitura: 3 mins.
