{"id":8704,"date":"2023-03-03T10:49:38","date_gmt":"2023-03-03T13:49:38","guid":{"rendered":"https:\/\/www.flane.com.pa\/blog\/?p=8704"},"modified":"2024-09-23T16:43:42","modified_gmt":"2024-09-23T19:43:42","slug":"como-abordar-a-modelagem-de-ameacas","status":"publish","type":"post","link":"https:\/\/www.flane.com.pa\/blog\/pt\/como-abordar-a-modelagem-de-ameacas\/","title":{"rendered":"Como abordar a modelagem de amea\u00e7as"},"content":{"rendered":"Reading time: <\/span> 15<\/span> minutes - <\/span><\/span>

Neste post, eu vou fornecer algumas dicas sobre como integrar a modelagem de amea\u00e7as ao ciclo de vida de desenvolvimento de aplica\u00e7\u00f5es da sua organiza\u00e7\u00e3o. Existem muitas orienta\u00e7\u00f5es excelentes sobre como executar as partes processuais da modelagem de amea\u00e7as, e abordarei brevemente quais s\u00e3o elas e suas metodologias. No entanto, o principal objetivo deste post \u00e9 ampliar a orienta\u00e7\u00e3o existente com algumas dicas adicionais sobre como lidar com as pessoas e os componentes do processo em sua abordagem de modelagem de amea\u00e7as, o que, na minha experi\u00eancia, ajuda muito a melhorar os resultados de seguran\u00e7a, a propriedade da seguran\u00e7a, a velocidade de entrada no mercado e a felicidade geral de todos os envolvidos. Al\u00e9m disso, fornecerei algumas orienta\u00e7\u00f5es espec\u00edficas para quando voc\u00ea estiver usando a\u00a0Amazon Web Services (AWS).<\/p>\n

Vamos come\u00e7ar com uma introdu\u00e7\u00e3o sobre modelagem de amea\u00e7as.<\/p>\n

Por que usar a modelagem de amea\u00e7as<\/strong><\/h2>\n

Sistemas de TI s\u00e3o complexos, e v\u00e3o se tornando cada vez mais complexos, assim como sua capacidade; oferecendo mais valor comercial e maior satisfa\u00e7\u00e3o e engajamento do cliente. Isso significa que as decis\u00f5es de design de TI precisam levar em conta um n\u00famero cada vez maior de casos de uso e precisam ser pensadas de forma a mitigar poss\u00edveis amea\u00e7as \u00e0 seguran\u00e7a que podem levar a resultados impactantes nos neg\u00f3cios, incluindo acesso n\u00e3o autorizado a dados, nega\u00e7\u00e3o de servi\u00e7o e uso indevido de recursos.<\/p>\n

Essa complexidade e o n\u00famero distinto de casos de uso normalmente tornam ineficaz o uso de abordagens n\u00e3o estruturadas para encontrar e mitigar amea\u00e7as. Em vez disso, voc\u00ea precisa de uma abordagem sistem\u00e1tica para enumerar as potenciais amea\u00e7as aos\u00a0workloads<\/em>, elaborar mitiga\u00e7\u00f5es e priorizar essas mitiga\u00e7\u00f5es para garantir que os recursos limitados de sua organiza\u00e7\u00e3o tenham o m\u00e1ximo impacto na melhoria da postura geral de seguran\u00e7a do\u00a0workload<\/em>. A modelagem de amea\u00e7as foi projetada para fornecer essa abordagem sistem\u00e1tica, com o objetivo de encontrar e resolver problemas no in\u00edcio do processo de design, quando as mitiga\u00e7\u00f5es t\u00eam um custo relativamente baixo em compara\u00e7\u00e3o com o ciclo de vida mais avan\u00e7ado.<\/p>\n

O\u00a0AWS Well-Architected Framework\u00a0destaca a modelagem de amea\u00e7as como uma pr\u00e1tica recomendada espec\u00edfica, dentro do\u00a0Pilar de seguran\u00e7a, na \u00e1rea de\u00a0fundamentos de seguran\u00e7a, sob a pergunta\u00a0SEC 1: como operar de forma segura seu\u00a0workload<\/em>?:<\/p>\n

\u201cIdentificar e priorizar riscos usando um modelo de amea\u00e7a: use um modelo de amea\u00e7a para identificar e manter um registro atualizado de poss\u00edveis amea\u00e7as. Priorize essas amea\u00e7as e adapte seus controles de seguran\u00e7a para prevenir, detectar e responder. Revise e mantenha isso no contexto do cen\u00e1rio de seguran\u00e7a em evolu\u00e7\u00e3o.\u201d<\/p>\n

A modelagem de amea\u00e7as \u00e9 mais eficaz quando feita no n\u00edvel do\u00a0workload<\/em>\u00a0(ou em uma funcionalidade do\u00a0workload<\/em>), a fim de garantir que todo o contexto esteja dispon\u00edvel para avalia\u00e7\u00e3o. O AWS Well-Architected define um\u00a0workload<\/em>\u00a0como:<\/p>\n

\u201cUm conjunto de componentes que, juntos, agregam valor comercial. Um\u00a0workload<\/em>\u00a0geralmente \u00e9 o n\u00edvel de detalhe sobre o qual os l\u00edderes de neg\u00f3cios e tecnologia se comunicam. Exemplos de\u00a0workloads<\/em>\u00a0s\u00e3o sites de marketing, sites de com\u00e9rcio eletr\u00f4nico,\u00a0backends<\/em>\u00a0para aplica\u00e7\u00f5es m\u00f3veis, plataformas anal\u00edticas, etc. Os\u00a0workloads<\/em>\u00a0variam em n\u00edveis de complexidade arquitet\u00f4nica, de sites est\u00e1ticos a arquiteturas com v\u00e1rios armazenamentos de dados e muitos componentes.\u201d<\/p>\n

As principais etapas da modelagem de amea\u00e7as<\/strong><\/h2>\n

Na minha experi\u00eancia, todas as abordagens de modelagem de amea\u00e7as s\u00e3o semelhantes; em um alto n\u00edvel, elas seguem estas etapas de uma forma geral:<\/p>\n

    \n
  1. Identifica\u00e7\u00e3o de ativos, atores, pontos de entrada, componentes, casos de uso e n\u00edveis de confian\u00e7a e inclus\u00e3o deles em um diagrama de design.<\/li>\n
  2. Identifica\u00e7\u00e3o de uma lista de amea\u00e7as.<\/li>\n
  3. Identifica\u00e7\u00e3o de mitiga\u00e7\u00f5es por amea\u00e7a, que pode incluir implementa\u00e7\u00f5es de controle de seguran\u00e7a.<\/li>\n
  4. Cria\u00e7\u00e3o e an\u00e1lise de uma matriz de risco para determinar se a amea\u00e7a foi adequadamente mitigada.<\/li>\n<\/ol>\n

    Para se aprofundar nas pr\u00e1ticas gerais associadas a essas etapas, sugiro a leitura do\u00a0whitepaper<\/em>\u00a0SAFECode Tactical Threat Modeling\u00a0e a\u00a0Open Web Application Security Project (OWASP) Threat Modeling Cheat Sheet. Esses guias s\u00e3o \u00f3timos recursos para voc\u00ea considerar ao adotar uma abordagem espec\u00edfica. Eles tamb\u00e9m fazem refer\u00eancia a uma s\u00e9rie de ferramentas e metodologias que s\u00e3o \u00fateis para acelerar o processo de modelagem de amea\u00e7as, incluindo a cria\u00e7\u00e3o de diagramas de modelo de amea\u00e7a com o\u00a0projeto Threat Dragon\u00a0do OWASP e a determina\u00e7\u00e3o de poss\u00edveis amea\u00e7as com o\u00a0OWASP Top 10,\u00a0OWASP Application Security Verification Standard (ASVS)\u00a0e\u00a0STRIDE. Voc\u00ea pode optar por adotar alguma combina\u00e7\u00e3o deles ou criar o seu pr\u00f3prio.<\/p>\n

    Quando fazer a modelagem de amea\u00e7as<\/strong><\/h2>\n

    A modelagem de amea\u00e7as \u00e9 uma atividade realizada no desenho do projeto. \u00c9 comum que durante a fase de desenho do projeto, voc\u00ea v\u00e1 al\u00e9m da cria\u00e7\u00e3o de um diagrama de arquitetura, e que possivelmente tamb\u00e9m estar\u00e1 construindo um ambiente de Desenvolvimento e\/ou Testes. Essas atividades s\u00e3o realizadas para trazer informa\u00e7\u00f5es que v\u00e3o ajudar a desenvolver seu projeto do ambiente de Produ\u00e7\u00e3o. Como a modelagem de amea\u00e7as \u00e9 uma atividade no momento do desenho do projeto, ela ocorre\u00a0antes<\/em>\u00a0da revis\u00e3o do c\u00f3digo, da an\u00e1lise de c\u00f3digo (est\u00e1tica ou din\u00e2mica) e do teste de penetra\u00e7\u00e3o; tudo isso ocorre posteriormente no ciclo de vida da seguran\u00e7a.<\/p>\n

    Sempre considere amea\u00e7as potenciais ao projetar seu\u00a0workload<\/em>, desde as fases iniciais, que normalmente ocorrem quando as pessoas ainda est\u00e3o escrevendo na lousa\/quadro-branco (seja f\u00edsico ou virtual). A modelagem de amea\u00e7as deve ser executada durante a fase de desenho de um projeto para um determinado recurso de\u00a0workload<\/em>\u00a0ou altera\u00e7\u00e3o do mesmo, pois essas altera\u00e7\u00f5es podem introduzir novas amea\u00e7as que exigem que voc\u00ea atualize seu modelo de amea\u00e7a.<\/p>\n

    Dicas de modelagem de amea\u00e7as<\/strong><\/h2>\n

    Em \u00faltima an\u00e1lise, a modelagem de amea\u00e7as requer reflex\u00e3o, brainstorming, colabora\u00e7\u00e3o e comunica\u00e7\u00e3o. O objetivo \u00e9 preencher a lacuna entre desenvolvimento de aplica\u00e7\u00f5es, opera\u00e7\u00f5es, neg\u00f3cios e seguran\u00e7a. N\u00e3o h\u00e1 atalho para o sucesso. No entanto, observei alguns fatores que t\u00eam impacto significativo na ado\u00e7\u00e3o e no sucesso da modelagem de amea\u00e7as, e \u00e9 o que abordarei nas se\u00e7\u00f5es a seguir.<\/p>\n

      \n
    1. Monte a equipe certa<\/strong><\/li>\n<\/ol>\n

      A modelagem de amea\u00e7as \u00e9 um \u201cesporte de equipe\u201d, porque requer o conhecimento e o conjunto de habilidades de uma equipe diversificada, onde todas as sugest\u00f5es podem ser vistas como iguais em valor. Para todas os tipos de\u00a0personas<\/em>\u00a0listadas nesta se\u00e7\u00e3o, a mentalidade sugerida \u00e9 come\u00e7ar pelas expectativas de seus clientes finais e trabalhar de tr\u00e1s para frente. Pense no que seus clientes esperam desse\u00a0workload<\/em>\u00a0ou de algum recurso do mesmo, tanto em termos de suas propriedades de seguran\u00e7a quanto em manter um equil\u00edbrio entre funcionalidade e usabilidade.<\/p>\n

      Eu recomendo que as seguintes perspectivas sejam abordadas pela equipe, observando que um \u00fanico indiv\u00edduo pode apresentar mais de uma dessas perspectivas:<\/p>\n

      A\u00a0persona<\/em>\u00a0de neg\u00f3cios<\/strong>: primeiro, para manter uma base s\u00f3lida, voc\u00ea vai querer algu\u00e9m que represente os resultados comerciais do\u00a0workload<\/em>\u00a0ou do recurso que faz parte do processo da modelagem de amea\u00e7as. Essa pessoa deve ter um entendimento profundo dos requisitos funcionais e n\u00e3o-funcionais do\u00a0workload<\/em>, e seu trabalho \u00e9 garantir que esses requisitos n\u00e3o sejam afetados indevidamente por nenhuma mitiga\u00e7\u00e3o proposta para lidar com amea\u00e7as. Ou seja, se um controle de seguran\u00e7a proposto (ou seja, mitiga\u00e7\u00e3o) tornar um requisito de aplica\u00e7\u00e3o inutiliz\u00e1vel ou excessivamente degradada, ser\u00e1 necess\u00e1rio mais trabalho para alcan\u00e7ar o equil\u00edbrio certo entre seguran\u00e7a e funcionalidade.<\/p>\n

      A\u00a0persona<\/em>\u00a0do desenvolvedor<\/strong>: \u00e9 algu\u00e9m que entende o projeto atual proposto para os recursos do\u00a0workload<\/em>\u00a0e teve o maior envolvimento nas decis\u00f5es sobre o projeto at\u00e9 o momento. Essa pessoa esteve envolvida em sess\u00f5es de brainstorming, ou whiteboarding do projeto que culminaram neste momento, quando normalmente est\u00e1 pensando em amea\u00e7as ao projeto e poss\u00edveis mitiga\u00e7\u00f5es a serem inclu\u00eddas. Nos casos em que voc\u00ea n\u00e3o est\u00e1 desenvolvendo sua pr\u00f3pria aplica\u00e7\u00e3o interna (por exemplo, aplica\u00e7\u00f5es\u00a0COTS), voc\u00ea traria o propriet\u00e1rio da aplica\u00e7\u00e3o interna.<\/p>\n

      A\u00a0persona<\/em>\u00a0do advers\u00e1rio<\/strong>: Em seguida, voc\u00ea precisa de algu\u00e9m para desempenhar o papel do advers\u00e1rio. O objetivo dessa\u00a0persona<\/em>\u00a0\u00e9 colocar-se no lugar de um invasor e revisar criticamente o projeto do\u00a0workload,\u00a0<\/em>afim de procurar maneiras de tirar proveito de uma falha de design no mesmo para atingir um objetivo espec\u00edfico (por exemplo, compartilhamento n\u00e3o autorizado de dados). Os \u201cataques\u201d que essa pessoa realiza s\u00e3o um exerc\u00edcio mental, n\u00e3o uma explora\u00e7\u00e3o pr\u00e1tica real atrav\u00e9s de c\u00f3digos. Se a sua organiza\u00e7\u00e3o tiver a equipe chamada\u00a0Red Team<\/u>, ela pode ser uma \u00f3tima op\u00e7\u00e3o para essa fun\u00e7\u00e3o; caso contr\u00e1rio, voc\u00ea pode querer que um ou mais membros de sua equipe de opera\u00e7\u00f5es de seguran\u00e7a ou engenharia desempenhem essa fun\u00e7\u00e3o. Outra alternativa \u00e9 trazer um terceiro especializado nessa \u00e1rea.<\/p>\n

      A\u00a0persona<\/em>\u00a0defensora<\/strong>: voc\u00ea precisar\u00e1 de algu\u00e9m para desempenhar o papel de defensor. O objetivo dessa persona \u00e9 ver os poss\u00edveis \u201cataques\u201d projetados pela persona advers\u00e1ria como amea\u00e7as potenciais e criar controles de seguran\u00e7a que atenuem as amea\u00e7as. Essa\u00a0persona<\/em>\u00a0tamb\u00e9m avalia se as poss\u00edveis mitiga\u00e7\u00f5es s\u00e3o razoavelmente gerenci\u00e1veis em termos de suporte operacional cont\u00ednuo, monitoramento e resposta a incidentes.<\/p>\n

      A\u00a0persona<\/em>\u00a0AppSec SME<\/strong>: A\u00a0persona<\/em>\u00a0especialista no assunto (Subject Matter Expert<\/em>\u00a0\u2013 SME) de\u00a0Application Security<\/em>\u00a0(AppSec) deve estar mais familiarizada com o processo de modelagem de amea\u00e7as e os m\u00e9todos de modera\u00e7\u00e3o de discuss\u00f5es, e deve ter um profundo conhecimento e experi\u00eancia em seguran\u00e7a de TI. A modera\u00e7\u00e3o da discuss\u00e3o \u00e9 crucial para o processo geral do exerc\u00edcio, a fim de garantir que os objetivos gerais do processo sejam mantidos no caminho certo e que o equil\u00edbrio adequado entre seguran\u00e7a e entrega do resultado do cliente seja mantido. Em \u00faltima an\u00e1lise, \u00e9 essa pessoa que endossa o modelo de amea\u00e7a e aconselha o escopo das a\u00e7\u00f5es, al\u00e9m do exerc\u00edcio de modelagem de amea\u00e7as e tamb\u00e9m o escopo do teste de penetra\u00e7\u00e3o.<\/p>\n

        \n
      1. Tenha uma abordagem consistente<\/strong><\/li>\n<\/ol>\n

        Na se\u00e7\u00e3o anterior, listei algumas das abordagens populares de modelagem de amea\u00e7as. Sua sele\u00e7\u00e3o n\u00e3o \u00e9 t\u00e3o importante quanto us\u00e1-la de forma consistente em todas as equipes.<\/p>\n

        Ao usar uma abordagem e um formato consistente, as equipes podem se mover mais rapidamente e estimar o esfor\u00e7o com mais precis\u00e3o. Os indiv\u00edduos podem aprender com exemplos, observando modelos de amea\u00e7as desenvolvidos por outros membros da equipe ou at\u00e9 outras equipes, evitando ter de come\u00e7ar do zero.<\/p>\n

        Quando sua equipe estima o esfor\u00e7o e o tempo necess\u00e1rios para criar um modelo de amea\u00e7a, a experi\u00eancia e o tempo gasto com modelos de amea\u00e7as anteriores podem ser usados para fornecer estimativas mais precisas dos cronogramas de entrega.<\/p>\n

        Al\u00e9m da consist\u00eancia na abordagem e no formato, ter consist\u00eancia na granularidade e relev\u00e2ncia das amea\u00e7as que est\u00e3o sendo modeladas \u00e9 fundamental. Mais adiante neste post, descrevo uma recomenda\u00e7\u00e3o para criar um cat\u00e1logo de amea\u00e7as para reutiliza\u00e7\u00e3o em toda a sua organiza\u00e7\u00e3o.<\/p>\n

        Por fim, e mais importante, essa abordagem permite escalabilidade: se um determinado recurso do\u00a0workload<\/em>\u00a0que est\u00e1 passando por um exerc\u00edcio de modelagem de amea\u00e7as estiver usando componentes que tenham um modelo de amea\u00e7a existente, o modelo de amea\u00e7a (ou controles de seguran\u00e7a individuais) desses componentes poder\u00e3o ser reutilizados. Com essa abordagem, voc\u00ea pode efetivamente depender do modelo de amea\u00e7a existente de um componente e desenvolver esse modelo, eliminando o retrabalho.<\/p>\n

          \n
        1. Alinhe-se \u00e0 metodologia de entrega de software<\/strong><\/li>\n<\/ol>\n

          Suas equipes de desenvolvimento de aplica\u00e7\u00f5es j\u00e1 t\u00eam um fluxo de trabalho e um estilo de entrega espec\u00edficos. Atualmente, a entrega no estilo da\u00a0Metodologia \u00c1gil<\/strong>\u00a0\u00e9 a mais popular. A abordagem adotada para modelagem de amea\u00e7as deve se integrar bem com sua metodologia de entrega e ferramentas.<\/p>\n

          Assim como em qualquer outro resultado de entrega, capture as hist\u00f3rias de usu\u00e1rios relacionadas \u00e0 modelagem de amea\u00e7as como parte do\u00a0sprint<\/em>,\u00a0epic<\/em>\u00a0ou\u00a0backlog<\/em>\u00a0do recurso do\u00a0workload<\/em>.<\/p>\n

            \n
          1. Use ferramentas de fluxo de trabalho existentes<\/strong><\/li>\n<\/ol>\n

            Suas equipes de desenvolvimento de aplica\u00e7\u00f5es j\u00e1 est\u00e3o usando um conjunto de ferramentas para dar suporte \u00e0 metodologia de entrega. Isso normalmente inclui ferramentas de colabora\u00e7\u00e3o para documenta\u00e7\u00e3o (por exemplo, uma wiki de equipe) e uma ferramenta de rastreamento de problemas para rastrear erros durante o ciclo de vida de desenvolvimento de software. Procure usar essas mesmas ferramentas como parte de seu fluxo de trabalho de an\u00e1lise de seguran\u00e7a e modelagem de amea\u00e7as.<\/p>\n

            As ferramentas de fluxo de trabalho existentes podem oferecer um \u00fanico local para fornecer e visualizar feedbacks, atribuir a\u00e7\u00f5es e visualizar o status geral dos resultados de modelagem de amea\u00e7as do recurso no\u00a0workload<\/em>. Fazer parte do fluxo de trabalho reduz o atrito de concluir o projeto e permite que a modelagem de amea\u00e7as se torne t\u00e3o comum quanto testes de unidade, testes de controle de qualidade ou outras etapas t\u00edpicas do fluxo de trabalho.<\/p>\n

            Ao usar ferramentas t\u00edpicas de fluxo de trabalho, os membros da equipe que trabalham na cria\u00e7\u00e3o e revis\u00e3o do modelo de amea\u00e7a podem trabalhar de forma ass\u00edncrona. Por exemplo, quando o revisor do modelo de amea\u00e7a adiciona um feedback, o autor \u00e9 notificado e pode responder ao feedback quando tiver tempo, sem ter de reservar um hor\u00e1rio espec\u00edfico para uma reuni\u00e3o. Al\u00e9m disso, isso permite que o\u00a0AppSec<\/em>\u00a0SME trabalhe de forma mais eficaz em v\u00e1rias revis\u00f5es de modelos de amea\u00e7as nas quais possa estar envolvido.<\/p>\n

            Ter uma abordagem e linguagem consistentes, conforme descrito anteriormente, \u00e9 um pr\u00e9-requisito importante para viabilizar esse processo ass\u00edncrono, para que cada participante possa ler e entender o modelo de amea\u00e7a sem ter que reaprender a interpreta\u00e7\u00e3o correta a cada vez.<\/p>\n

              \n
            1. Divida a workload em partes menores<\/strong><\/li>\n<\/ol>\n

              \u00c9 aconselh\u00e1vel decompor (dividir) o\u00a0workload<\/em>\u00a0em recursos e realizar o exerc\u00edcio de modelagem de amea\u00e7as no n\u00edvel do recurso, em vez de criar um \u00fanico modelo de amea\u00e7a para um\u00a0workload<\/em>\u00a0inteiro. Essa abordagem tem v\u00e1rios benef\u00edcios principais:<\/p>\n

                \n
              1. Ter partes menores de trabalho permite um acompanhamento mais granular do progresso, o que se alinha bem com as equipes de desenvolvimento que est\u00e3o seguindo a entrega no estilo\u00a0\u00c1gil<\/strong>, al\u00e9m de oferecer aos l\u00edderes uma vis\u00e3o constante do progresso.<\/li>\n
              2. Essa abordagem tende a criar modelos de amea\u00e7as mais detalhados, o que resulta na identifica\u00e7\u00e3o de mais descobertas.<\/li>\n
              3. A decomposi\u00e7\u00e3o tamb\u00e9m abre a oportunidade para que o modelo de amea\u00e7a seja reutilizado como uma depend\u00eancia para outros recursos do\u00a0workload<\/em>\u00a0que usam os mesmos componentes.<\/li>\n
              4. Ao considerar as mitiga\u00e7\u00f5es de amea\u00e7as para cada componente, no n\u00edvel geral do\u00a0workload<\/em>, isso significa que uma \u00fanica amea\u00e7a pode ter v\u00e1rias mitiga\u00e7\u00f5es, resultando em uma resili\u00eancia aprimorada contra essas amea\u00e7as.<\/li>\n
              5. Problemas com um \u00fanico modelo de amea\u00e7a, por exemplo uma amea\u00e7a cr\u00edtica que ainda n\u00e3o foi mitigada, n\u00e3o se tornam impeditivos de lan\u00e7amento para todo o\u00a0workload<\/em>, mas apenas para o recurso individual.<\/li>\n<\/ol>\n

                A quest\u00e3o ent\u00e3o \u00e9: at\u00e9 que ponto voc\u00ea deve decompor o\u00a0workload<\/em>?<\/p>\n

                Como regra geral, para criar um modelo de amea\u00e7a o seguinte contexto \u00e9 necess\u00e1rio, no m\u00ednimo:<\/p>\n