Obviamente, também não é necessário gastar horas indevidas construindo um back-end como o Fort Knox para o seu aplicativo. Ser um defensor da segurança não significa sempre usar seu chapéu de papel alumínio (embora você pareça ousado), mas significa construir uma quantidade adequada de segurança.
Quanta segurança é apropriada? A resposta, frustrantemente, é: “depende”. A quantidade certa de segurança para seu aplicativo depende de quem o está usando, o que faz e, o que é mais importante, quais coisas indesejáveis ele pode fazer. São necessárias algumas análises para tomar decisões sobre os tipos de riscos que seu aplicativo enfrenta e como você se preparará para lidar com eles. Ok, agora é uma boa hora para vestir seu chapéu de papel alumínio. Vamos imaginar o pior.
Modelagem de ameaças: o pior que poderia acontecer
UMA modelo de ameaça é um termo abafado para o resultado de tentar imaginar as piores coisas que poderiam acontecer a um aplicativo. Usando sua imaginação para avaliar riscos (apropriadamente chamado avaliação de risco) é um método convenientemente não destrutivo para encontrar maneiras pelas quais um aplicativo pode ser atacado. Você não precisa de nenhuma ferramenta; apenas uma compreensão de como o aplicativo pode funcionar e um pouco de imaginação. Você deseja gravar seus resultados com caneta e papel. Para os mais jovens, isso significa o aplicativo de anotações no seu telefone.
Algumas metodologias diferentes para avaliação de riscos de aplicativos podem ser encontradas no mundo do software, incluindo as Publicação Especial NIST 800-30. A estrutura de cada método possui etapas e resultados específicos e entrará em vários níveis de detalhes quando se trata de definir ameaças. Se seguir uma estrutura, escolha primeiro a que você provavelmente concluirá. Você sempre pode adicionar mais profundidade e detalhes a partir daí.
Até avaliações informais de risco são benéficas. Geralmente, sob a forma de um conjunto de perguntas, elas podem ser orientadas para possíveis ameaças, o impacto sobre os ativos ou as maneiras pelas quais uma vulnerabilidade pode ser explorada. Aqui estão alguns exemplos de perguntas abordando cada orientação:
- Que tipo de adversário gostaria de quebrar meu aplicativo? O que eles procurariam?
- Se o controle de x caiu nas mãos erradas, o que um atacante poderia fazer com isso?
- Onde poderia x vulnerabilidade ocorre no meu aplicativo?
Um modelo básico de ameaça explica as considerações técnicas, comerciais e humanas para cada risco. Ele normalmente detalha:
- As vulnerabilidades ou componentes que podem causar o risco
- O impacto que uma execução bem-sucedida do risco teria no aplicativo
- As consequências para os usuários ou organização do aplicativo
O resultado de um exercício de avaliação de risco é o seu modelo de ameaça; em outras palavras, uma lista de coisas que você gostaria muito que não ocorresse. Geralmente é classificado em uma hierarquia de riscos, do pior ao mais suave. Os piores riscos têm o impacto mais negativo e são os mais importantes para se proteger. Os riscos mais leves são os mais aceitáveis - embora ainda sejam um resultado indesejável, eles têm o menor impacto negativo no aplicativo e nos usuários.
Você pode usar essa hierarquia resultante como um guia para determinar quanto de seus esforços de segurança cibernética serão aplicados a cada área de risco. Uma quantidade adequada de segurança para seu aplicativo eliminará (sempre que possível) ou mitigará os piores riscos.
Empurrando para a esquerda
Embora pareça um meme de dança, empurrando para a esquerda refere-se, em vez disso, à construção da maior segurança planejada possível nos estágios iniciais do desenvolvimento de software.
Construir software é como construir uma casa na árvore, apenas sem o agradável ar fresco. Você começa com os componentes básicos de suporte, como anexar uma plataforma a uma árvore. Em seguida, vem o enquadramento, as paredes e o telhado e, finalmente, as tapeçarias e o busto de veados dignos do Instagram, rústicos e modernos.
Quanto mais adiante você estiver no processo de criação, mais difícil e mais caro será fazer alterações em um componente que você já instalou. Se você descobrir um problema nas paredes somente depois que o teto for colocado no lugar, poderá ser necessário trocar ou remover o teto para consertá-lo. Paralelos semelhantes podem ser traçados para componentes de software, apenas sem a mesma facilidade para desembaraçar as peças conectadas.
No caso de uma casa na árvore, é impossível começar com decorações ou até um telhado, pois você não pode suspendê-las no ar. No caso do desenvolvimento de software, infelizmente, é possível criar muitos componentes e abstrações da camada superior sem uma arquitetura de suporte suficiente. Uma abordagem push-left exibe cada camada adicional como agregando custo e complicação. Pressionar para a esquerda significa tentar reduzir ao máximo os riscos à segurança em cada estágio de desenvolvimento antes de prosseguir para o próximo.
Construção de baixo para cima
Ao considerar seu modelo de ameaça nos estágios iniciais do desenvolvimento de seu aplicativo, você reduz as chances de precisar de uma remodelação cara posteriormente. Você pode fazer escolhas sobre arquitetura, componentes e código que suportam os principais objetivos de segurança de seu aplicativo específico.
Embora não seja possível prever todas as funcionalidades que seu aplicativo talvez um dia precise suportar, é possível preparar uma base sólida que permita que funcionalidades adicionais sejam adicionadas com mais segurança. Construir uma segurança adequada, de baixo para cima, ajudará a facilitar os riscos de segurança atenuantes no futuro.