# Um modelo de ameaças prático para o seu projeto alojado | SwissOctet Insights https://swissoctet.com/pt/insights/threat-model-a-hosted-project/ SwissOctet / Informações / Operações do dia-a-dia Operações do dia-a-dia Aplicado · 6 min de leitura Um modelo de ameaças prático para o seu projeto alojado Mapeie os ativos e os limites de confiança, escolha alguns cenários de falha realistas e transforme-os em controlos que possa testar. Por SwissOctet Editorial Guardar guia Copiar ligação NESTA PÁGINA 01 Defina um âmbito suficientemente pequeno para poder raciocinar sobre ele 02 Desenhe os pontos onde a confiança muda 03 Escolha cenários de falha concretos 04 Priorize pelo impacto e por um percurso credível 05 Teste os controlos num ambiente autorizado 06 Mantenha o modelo ligado à mudança A sua lista de verificação prática Fontes e leitura adicional Voltar à biblioteca A RESPOSTA DIRETA Um modelo de ameaças útil explica o que protege, quem ou o que o pode afetar, onde a confiança muda e como vai reduzir e testar os riscos mais importantes. Comece pelo projeto real em vez de uma lista genérica de ferramentas. 01 Defina um âmbito suficientemente pequeno para poder raciocinar sobre ele Comece com um serviço em funcionamento: um portal de clientes, um site de publicação ou uma aplicação interna. Anote os componentes que opera e os sistemas externos em que se baseia. Um modelo de ameaças deve tornar visíveis os pressupostos, não sugerir que todos os ataques possíveis foram resolvidos. Mantenha a primeira versão suficientemente pequena para que as pessoas que implementam a aplicação a possam explicar sem um consultor separado a interpretar o diagrama. Liste os resultados e os ativos valiosos. Estes podem incluir dados de clientes, acesso de administração, estado de pagamento, conteúdo publicado e a capacidade de restaurar o serviço. A disponibilidade pode ser um ativo mesmo quando a informação é pública. Decida que falhas seriam inconvenientes e quais prejudicariam pessoas ou a organização. Essa distinção ajuda a priorizar controlos em vez de tratar todos os avisos da mesma forma. 02 Desenhe os pontos onde a confiança muda As orientações de modelação de ameaças da OWASP utilizam fluxos de dados e limites de confiança para tornar um design compreensível. Para uma pequena aplicação alojada, desenhe o navegador, o processo web, a base de dados, o administrador, o destino das cópias de segurança e as integrações externas. Marque a informação que circula entre eles. Um pedido que atravessa de um cliente não fidedigno para uma operação privilegiada do servidor merece validação e autorização explícitas. Não parta do princípio de que estar dentro da mesma máquina torna todos os componentes igualmente fidedignos. Um processo de carregamento público não deve ter as mesmas permissões que a administração da base de dados. Uma tarefa de cópia de segurança pode precisar de acesso de leitura sem a capacidade de modificar registos da aplicação em produção. Separar esses papéis torna mais fácil conter o efeito de um componente comprometido e rever as permissões necessárias. 03 Escolha cenários de falha concretos Utilize alguns eventos plausíveis para desafiar o design. Um atacante rouba uma palavra-passe de administrador; um utilizador pede o registo de outro utilizador; um carregamento enche o disco; uma implementação expõe um ficheiro de configuração; uma cópia de recuperação não pode ser restaurada. Descreva a condição inicial, o componente afetado e a consequência. Um cenário específico é mais fácil de testar do que uma instrução ampla para melhorar a segurança. Inclua erros e abuso legítimo de fluxos de trabalho, bem como intrusões externas. Uma nova tentativa pode criar duas operações valiosas, ou dois pedidos podem competir para alterar o mesmo objeto. As orientações da OWASP sobre lógica de negócio destacam estes pressupostos de processo. Verifique quem tem permissão para fazer avançar um fluxo de trabalho para o estado seguinte e se repetir ou reordenar um pedido altera o resultado de forma inesperada. Cenário Controlo a investigar Evidência a recolher Credencial de administração roubada Acesso restrito e um segundo fator quando suportado Um início de sessão não autorizado não pode ser concluído Objeto de outro utilizador solicitado Autorização de objetos no lado do servidor Um teste isolado devolve um resultado negado Disco esgotado por carregamentos Controlos de tamanho, quota e retenção É aplicado um limite antes da falha do serviço Pedido de fluxo de trabalho duplicado Idempotência e limites de transação Um pedido repetido cria um único resultado 04 Priorize pelo impacto e por um percurso credível Para cada cenário, registe o seu impacto potencial e as condições necessárias para que ocorra. Evite fingir que uma pontuação numérica estimada é uma probabilidade precisa. Ainda pode distinguir uma palavra-passe fraca exposta à internet de um evento local altamente condicional. Atribua um responsável e um próximo passo prático aos riscos importantes, para que o modelo crie trabalho que alguém possa realmente concluir. Considere o ciclo de vida da informação, bem como o comprometimento da aplicação. Uma exportação de diagnóstico pode divulgar dados desnecessários durante um funcionamento normal. Um campo de conta retido pode criar exposição muito depois de a sua finalidade terminar. A revisão de privacidade pode, por isso, remover informação ou encurtar a retenção, enquanto a revisão de segurança restringe o acesso ao que resta. Ambas as alterações pertencem ao modelo quando protegem o projeto. 05 Teste os controlos num ambiente autorizado Crie um ambiente de pré-produção com permissões representativas e registos fabricados. Teste acessos negados, limites de pedidos, novas tentativas de fluxos de trabalho e recuperação. Não utilize dados reais de clientes quando dados sintéticos podem demonstrar o comportamento. O objetivo é verificar o controlo, não gerar tráfego de ataque impressionante. Mantenha-se dentro dos sistemas que possui ou está explicitamente autorizado a avaliar. Registe o que passou, o que falhou e o que permanece desconhecido. O resultado de um scanner pode contribuir com evidências, mas não substitui um teste às regras de negócio da aplicação. Do mesmo modo, uma opção de proteção de rede não verifica a autorização de objetos nem o tratamento de ficheiros de segredos. Anexe os resultados úteis ao cenário para que os futuros responsáveis pela manutenção compreendam porque existe um determinado controlo. 06 Mantenha o modelo ligado à mudança Reveja as partes relevantes quando adicionar uma integração, expuser um novo endpoint, alterar um privilégio ou mover dados para outro destino. Não precisa de redesenhar toda a arquitetura por causa de uma pequena edição de texto. O gatilho é uma alteração de pressupostos sobre acesso, informação ou comportamento do sistema. Mantenha o modelo junto da documentação de implementação e recuperação, em vez de o deixar como o resultado de um workshop pontual. O SwissOctet fornece um catálogo de opções de infraestrutura, não um modelo de ameaças de aplicação concluído. Escolha a configuração e as opções que suportam os seus controlos e, em seguida, verifique a implementação que constrói. Um modelo pequeno e mantido, com ações testadas, é mais útil do que uma grande coleção de produtos de segurança sem uma explicação clara dos riscos que abordam. TRANSFORME ISTO EM AÇÃO A sua lista de verificação prática. ✓ Liste os ativos e as consequências da falha. ✓ Desenhe os fluxos de dados e os limites de confiança. ✓ Escolha cenários específicos de intrusão, erro e fluxo de trabalho. ✓ Atribua controlos e responsáveis aos riscos importantes. ✓ Teste com dados sintéticos num ambiente autorizado. ✓ Reveja o modelo quando um pressuposto relevante mudar. Descarregar lista de verificação PERGUNTAS FREQUENTES Os detalhes que importam. Preciso de um quadro formal para começar? + Não. Um pequeno diagrama e um conjunto documentado de cenários podem ser úteis. Um quadro ajuda a garantir que revê os riscos de forma consistente. Um scanner de vulnerabilidades substitui a modelação de ameaças? + Não. Os scanners podem encontrar fraquezas técnicas, enquanto um modelo de ameaças também examina pressupostos de design, permissões e fluxos de trabalho de negócio. Com que frequência devo atualizar o modelo? + Atualize as partes afetadas quando os fluxos de dados, as integrações, os privilégios ou a funcionalidade exposta mudarem, e reveja regularmente os riscos não resolvidos. REFERÊNCIAS PRIMÁRIAS Vá à fonte. Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção. OWASP: Folha de referência de modelação de ameaças cheatsheetseries.owasp.org OWASP: Modelação de ameaças na prática devguide.owasp.org OWASP: Segurança da lógica de negócio cheatsheetseries.owasp.org Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente. LIGUE O CONHECIMENTO Infraestrutura relacionada. Vector VPS Suíça Metal Atlas Suíça Canvas Web Suíça MANTENHA O FIO As suas próximas notas de campo. Explore todos os guias NOTA DE CAMPO / 01 + Operações do dia-a-dia Aplicado Construa uma cópia de segurança que consiga realmente restaurar Escolha um objetivo de recuperação, proteja uma cópia independente e pratique a restauração antes que um incidente force a questão. 4 min de leitura Leia o guia NOTA DE CAMPO / 02 + Operações do dia-a-dia Aplicado Administração segura do Windows RDP sem perder o acesso Separe a acessibilidade de rede, a autenticação e os privilégios e, em seguida, verifique uma rota de recuperação antes de restringir o acesso remoto. 6 min de leitura Leia o guia NOTA DE CAMPO / 03 + Operações do dia-a-dia Aplicado Uma base de endurecimento do Linux VPS que pode manter Administre com segurança, exponha apenas os serviços necessários e estabeleça atualizações e recuperação sem se bloquear a si próprio. 6 min de leitura Leia o guia