DEV Community: Leão de Chácara

Criando meu próprio Github Actions para a área de AppSec

michelleamesquita — Mon, 03 Apr 2023 16:42:35 +0000

Olá pessoal, tudo bem? 😊

Hoje resolvi trazer esse tema, pois na área de AppSec/DevSecOps é muito importante conhecer outras ferramentas que possam ajudar na integração e checagens de segurança durante a fase de desenvolvimento de um software.

O que é Github Actions?

Ele serve para você automatizar de forma fácil todo o processo de desenvolvimento de software, utilizando o conceito CI/CD por meio do workflow (build, teste e deploy ) no seu repositório.

O mais interessante é que você pode criar uma action e compartilhar no Github Marketplace e assim, qualquer pessoa poderá usar a sua action!

Achei essa ideia sensacional, principalmente se você quiser criar um código, como no nosso caso, que será para encontrar vulnerabilidade no código. Assim, não precisaremos passar por todos steps como clonar o repositório do projeto, instalar dependências ou Docker para o projeto específico, para depois executá-lo!

Agora que entendemos para o que serve o Github Actions, precisamos criar a nossa Action. Para isso, termos que ter em mente que precisamos criar um arquivo chamado action.yml e que o mesmo precisa estar no diretório principal (root). Dessa forma, será entendido pelo Github que esse é o arquivo que dará origem a nossa action.

name: 'SAST validator'
author: 'michelleamesquita'
description: 'Using python to verify vulnerabilities into code'
inputs:
  path:
    required: true
    default: "."
  language:
    required: false
runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - -d=${{ inputs.path }}
    - -l=${{ inputs.language }}

Nesse arquivo, é importante entendermos que possuem alguns parâmetros importantes que serão usados para a criação da minha action utilizando container (Docker).

inputs : é utilizado para passar os parâmetros que serão passados no argumento argumento (docker run sast -d=. -l=python) . Então, "path" recebe o valor de "python", no exemplo.
runs : é a parte principal do actions. Ele serve para definir o tipo de runner, que no nosso caso é 'docker'. Assim precisamos passar parâmetros específicos do Docker. Por exemplo a imagem e os argumentos que serão os inputs setados previamente.
Caso queiram ver os demais exemplos, segue a documentação do Github também 😊

Para utilizarmos essa action em outros projetos, será necessário publicar no Marketplace. Para isso, colocarei os passos abaixo: (só não reparem no número da versão que criei, pois estava apenas testando na época 😅)

Link para minha Action no Marketplace: https://github.com/marketplace/actions/sast-validator

Link para o meu repositório no Github:
https://github.com/michelleamesquita/sast-validator

Para criar tags no versionamento, segue as linhas de código:

➜ git tag -a -m “My first action release” v40 ➜ git push - follow-tags

Para adicionar a action no repositório, será necessário criar esse diretório: .github/workflows/ , onde será necessário passar um arquivo yaml, como no exemplo abaixo:

on:
  push:
    branches:
    - main

jobs:
  sast_job:
    runs-on: ubuntu-latest
    name: SAST Validator
    steps:
      - name: Checkout repository content
        uses: actions/checkout@v2 

      - name: SAST validator
        uses: michelleamesquita/sast-validator@v40
        with:
          options: -v $PWD/:/app
          path: .
          language: python

Nesse código acima, é importante entender que precisamos utilizar a actions/checkout@v2 para poder ler o arquivo do diretório corrente do projeto que usará o sast-validator.
Utilizamos o parâmetro options para compartilhar o volume entre o container e a máquina virtual linux (Ubuntu) que está sendo utilizada para rodar esse job.

Por fim, quando houver um push na branch Main, o código que analisa vulnerabilidades irá avaliar essa branch.

Assim, o código de validador de vulnerabilidades (SAST Validator), foi utilizado como prova de conceito para encontrar potenciais vulnerabilidades. No entanto, é importante salientar que é necessário o analista de segurança validar. Como também, podemos aumentar a quantidade de regras e também para linguagens específicas, onde utilizei o RegEx para realizar esses testes.

Espero que tenham gostado 💜👩‍💻

Application Security com OpenSource. É possivel?

Johny Ramos — Thu, 09 Mar 2023 00:44:57 +0000

Fala Devs!

Entregar software seguro hoje em dia é uma obrigação de toda empresa. Mas será que sempre temos recurso para analisar o que estamos produzindo? A empresa, está disposta a investir em Segurança? Se não está, qual alternativa temos para contornar esta situação?

Bom, são com essas perguntas que inicio a minha primeira publicação aqui no DEV.to, com base numa apresentação que efetuei para a comunidade do Discord Menina de CyberSec, iniciativa da Sabrina Ramos.

Já trabalhei em empresas que o quesito segurança sempre era visto como um gasto/custo. Já cheguei a observar entregas de software com credenciais chumbadas em código, com intuíto de "facilitar" a conexão com o banco de dados. Sem contar outras inumeras situações de total despreocupação com o tema. Talvez por desconhecimento, talvez por pensar "estamos em um nicho pequeno, quem vai se importar conosco?".

Se você passa ou passou por isso, seus problemas acabaram! Apresento abaixo algumas ferramentas OpenSource para executar um ciclo de desenvolvimento de software seguro (SSDLC). Assim, sem a necessidade inicial de investir em ferramentas enterprise, você pode analisar todo seu produto e corrigir as vulnerabilidades encontradas em tempo de desenvolvimento.

Vamos lá:

- OWASP THREAT DRAGON - Threat Model
OWASP Threat Dragon é uma ferramenta de modelagem de ameaças que ajuda a identificar e mitigar possíveis ameaças de segurança em seus aplicativos. Ele fornece uma interface gráfica amigável que permite criar e modificar modelos de ameaças usando as metodologias como STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) e DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability).

- OWASP DEPENDENCY CHECK / TRACK - SCA
O Dependency Check / Track são ferramenta de Software Composition Analysis (SCA) que ajudam as organizações a identificar e gerenciar vulnerabilidades nas dependências de seu software. Eles permitem que você examine seus projetos para identificar as bibliotecas, estruturas e outros componentes de terceiros dos quais seu código depende.

- SONARQUBE - SAST & QA
SonarQube é uma plataforma de inspeção contínua de qualidade de código, análise de código e análise de código estático. Ele fornece um conjunto de ferramentas para analisar a qualidade do código, identificar bugs, vulnerabilidades de segurança e code smells (más práticas de codificação). Atende inúmeras linguagens de mercado, é possivel integração com CI/CD e pode ser personalizada para atender os níveis de qualidade que deseja.

- OWASP ZAP - DAST
O ZAP (Zed Attack Proxy) é um scanner de segurança de aplicativos Web/API de código aberto amplamente utilizado e uma ferramenta de teste de penetração. Ele foi projetado para ajudar profissionais de segurança e desenvolvedores a testar a segurança de aplicativos Web e encontrar vulnerabilidades. É possivel automatizar as análises, interceptações, verificar vulnerabildiades como SQLi, XSS, etc.

- JENKINS - Pipeline
Jenkins é um servidor de automação usado para automatizar vários aspectos do ciclo de vida de desenvolvimento de software, incluindo criação, teste e implantação de aplicativos de software. Jenkins é altamente personalizável e extensível, pode ser integrado a uma ampla variedade de ferramentas e sistemas de software. Permite aos usuários gerenciar e configurar sua instâncias, incluindo criação e agendamento de compilações, configuração de ambientes de compilação e configuração de plugins. Jenkins também oferece suporte a um rico ecossistema de plug-ins, que permite aos usuários estender e personalizar suas funcionalidades de várias maneiras.

- AQUA TRIVY - Container
Trivy é um scanner projetado para detectar vulnerabilidades em imagens de contêiner e outros artefatos, como pacotes de sistema operacional e dependências de aplicativos. É uma ferramenta leve e fácil de usar que pode ser integrada aos pipelines de DevOps para ajudar a automatizar a verificação de vulnerabilidades e melhorar a segurança de aplicativos em contêineres.

- DEFECT DOJO - Vulnerability Management
DefectDojo é uma ferramenta de gerenciamento de vulnerabilidade que ajuda as equipes de segurança a gerenciar o processo de teste de segurança para seus aplicativos de software. Ele permite que as equipes de segurança rastreiem e gerenciem vulnerabilidades descobertas durante vários estágios do ciclo de vida de desenvolvimento de software, incluindo teste, implantação e produção. Como um agregador de informações, permite integração com email, pipelines, ferramentas de versionamento, boards de tarefas e ainda gera relatórios e dashboards

- TRUFFLE HOG - Secret Sniffer
Trufflehog é uma ferramenta de segurançabusada para pesquisar informações confidenciais, como chaves de API, chaves criptográficas e outros segredos, que podem ter sido acidentalmente fixados em repositórios de código. Funciona escaneando o conteúdo dos repositórios de código, incluindo histórico de commits e ramificações, procurando padrões que correspondam a Secret Keys conhecidas e outras informações confidenciais. O Trufflehog pode procurar chaves em uma ampla variedade de tipos de arquivo, incluindo arquivos de código, arquivos de configuração e arquivos binários.

Com toda essa stack de ferramentas, você pode criar um ciclo de desenvolvimento seguro, permitindo que seu produto seja entregue ao seu cliente com o menor risco de ter uma brecha de segurança. Há outras ferramentas e Frameworks que podemos utilizar, mas este artigo já está grande demais... apresento uma outra hora!

Espero que essas informações possam servir para seu dia-a-dia e para deixar de lado as desculpas da sua empresa de que não tem dinheiro para ferramentas de segurança.

Até a próxima!

Automações na área de AppSec 🤖

michelleamesquita — Tue, 28 Feb 2023 22:50:58 +0000

Olá, pessoal.
Tudo bem?

Esse é o meu primeiro post utilizando a plataforma dev.to! Eu possuo um blog no Medium também, onde falo de AppSec/DevSecOps caso queiram ler, mas dependendo, futuramente, eu possa adicionar alguns artigos que escrevi lá aqui também. 😊

Sem mais delongas, gostaria de tratar um pouco sobre o assunto automações para a área de AppSec.

Começo com esse texto pois dentro dessa vasta área de Application Security, existe espaço para todos trabalharem, desde conscientização dos desenvolvedores ou mesmo adição de ferramentas na pipeline!

No entanto, o foco hoje é na parte de secure code review! Isso é importante de ser falado pois muito se fala de adição de ferramentas de SAST, DAST e SCA. No entanto, as ferramentas trazem bastante falso positivos. Assim, temos que exercitar bem a lógica de programação para validarmos o output que a ferramenta retorna. Como também, questionar se a ferramenta está validando todos os pontos que ela deveria checar.

Dessa forma, o secure code review é extremamente necessário para validar e confirmar o que o SAST retorna. Isso porque as ferramentas possuem diversas lógicas internas com expressões regulares, mas que nem sempre identificam que um ponto foi tratado (falso positivo) ou não retornam todos os pontos que estão vulneráveis!

Além disso, é interessante pensar e entender na lógica que uma ferramenta de SAST funciona. Nesse caso, trouxe como exemplo o Checkmarx, na imagem abaixo, é que ela analisa o input da ferramenta (parâmetros), output (saída para o usuário) e através disso, ele busca se existe um sanitizador (algo que modifique a entrada do usuário) para a vulnerabilidade XSS. Caso exista essa regra na ferramenta, ele entende que a vulnerabilidade foi tratada.

Como as ferramentas possuem uma lista de regras pré-setadas, é importante que o analista de AppSec também crie suas próprias regras de acordo com as vivências na área, até para confirmar ou analisar se existem pontos também críticos. Embora as ferramentas na pipeline já agilizem muito o processo, precisamos ter esse entendimento que é necessário realizar nossa própria análise também.

Para isso, eu desenvolvi um script que funciona como um grande RegEx, onde eu crio as minhas regras para validar ainda mais pontos.

Segue o link no Github para quem quiser contribuir também 😎.
https://github.com/michelleamesquita/sast-validator

Eu criei regras para algumas das principais vulnerabilidades que vejo acontecer no dia-a-dia. Como também, separei por algumas funcionalidades como autenticação, upload de arquivos e reset/conexão de bancos com senhas. Quando falamos de code review, esse é um ponto super importante para entender aonde procurar por vulnerabilidades: funcionalidades da aplicação.

Funcionamento da aplicação:

Comando:
python3 sast.py -d PATH -l Language (optional)

Output:

Espero que gostem! 💜👩‍💻

Modelagem de Ameaças -Decompondo o Aplicativo

brmartin | Bruno Martins — Sun, 26 Feb 2023 21:27:35 +0000

TL:DR
Neste artigo utilizei um aplicativo que estou desenvolvendo academicamente para praticar a modelagem de ameaças e exemplificar a teoria ao longo do texto. Essa primeira etapa da Modelagem corresponde à decomposição do sistema.

Etapa 1: Decompor o aplicativo

Existem muitas vulnerabilidades e ameaças possíveis e é improvável que seu aplicativo encontre todos eles. Também é improvável que sua empresa precise abordar todos eles. A modelagem de ameaças ajuda a identificar onde sua equipe precisa concentrar esforços.

Todos os desenvolvedores, designers de software e arquitetos devem se esforçar para incluir a modelagem de ameaças em todo ciclo de vida de desenvolvimento de software. Mas primeiramente concentre-se no que você está trabalhando no momento.

Eu utilizarei para estudo prático um aplicativo Fintech, voltado para usuários que desejam planejar de forma flexível seus orçamentos e gerenciar o dia a dia de suas finanças, que estou desenvolvendo academicamente.

Dito isso, é importante que se decomponha todo o sistema e faça perguntas para que se encontre onde as vulnerabilidades se encontram. A primeira etapa no processo de modelagem de ameaças se preocupa em entender o aplicativo e como ele interage com as entidades externas.

Identifique o design do aplicativo

Entender o design do aplicativo é fundamental para realizar a modelagem de ameaças. Se você estiver muito familiarizado com o design do aplicativo, poderá identificar fluxos de dados adicionais e limites de confiança em todo o processo de modelagem de ameaças.

Identifique os casos de uso, defina os pontos de entrada do aplicativo e os níveis de confiança, mesmo que permaneçam inalterados como resultado do projeto.
Identifique atores, ativos, serviços, funções e fontes de dados.
Documente a movimentação de dados (em movimento e em repouso) via Diagrama de Fluxo de Dados.
Documente todos os dados trocados e sua classificação.

Uma compreensão completa de como o sistema foi projetado também o ajudará a avaliar a probabilidade e o impacto potencial de qualquer ameaça específica que você identificar.

Decomponha e modele o aplicativo

É importante que se tome nota do processo para que em um eventual momento se possa consultar o que foi feito. Baseado no Processo de Modelagem de Ameaças da OWASP, iniciamos a documentação com a etapa 1 - decompondo o aplicativo, conforme segue abaixo:

1. Informações de identificação

Nome do Sistema : O nome do aplicativo examinado.
Versão do aplicativo : A versão do aplicativo examinado.
Descrição : Uma descrição de alto nível do aplicativo.
Proprietário do documento : o proprietário do documento de modelagem de ameaças.
Participantes : os participantes envolvidos no processo de modelagem de ameaças para este aplicativo.
Revisor : O(s) revisor(es) do modelo de ameaça.

Exemplo prático:

Nome: ContabiLivre
Versão: v0.1
Descrição: Aplicativo web de planejamento financeiro pessoal, capacitado com sincronização de saldo bancário e despesas de cartão de crédito.
Proprietário do documento: Bruno Martins

Os ítens 4 e 5 não foram preenchidos pois pratiquei sozinho e não tive a oportunidade de ter um revisor. Porém são dois ítens de extrema importância para uma boa elaboração do modelo de ameaças.

2. Dependências externas

Dependências externas são itens externos ao código do aplicativo que podem representar uma ameaça ao aplicativo.

As dependências externas devem ser documentadas da seguinte forma:

ID : um ID exclusivo atribuído à dependência externa.
Descrição : uma descrição textual da dependência externa.

Exemplo prático:

ID	Descrição
1	Tela de login do usuário através de um browser onde autenticará seus dados para acesso
2	Acesso ao banco de dados com informações do perfil
3	API de conexão com saldo bancário
4	API de conexão com cartão de crédito

3. Pontos de entrada

Os pontos de entrada definem as interfaces por meio das quais invasores em potencial podem interagir com o aplicativo ou fornecer dados a ele.

Os pontos de entrada devem ser documentados da seguinte forma:

ID : Um ID exclusivo atribuído ao ponto de entrada. Isso será usado para fazer referência cruzada do ponto de entrada com quaisquer ameaças ou vulnerabilidades identificadas.
Nome : um nome descritivo que identifica o ponto de entrada e sua finalidade.
Descrição : Uma descrição textual detalhando a interação ou processamento que ocorre no ponto de entrada.
Níveis de confiança : o nível de acesso necessário no ponto de entrada. Eles serão cruzados com os níveis de confiança definidos posteriormente no documento.

Exemplo prático:

ID	Nome	Descrição	Nivel de Confiança
1	Login	Tela de acesso ao perfil do usuário.	Request HTTP
2	Acesso ao Banco de Dados	Armazenamento de dados dos usuários	O time de desenvolvimento tem credenciais de acesso
3	Utilização do App	Manuseio e utilização das informações contidas no aplicativo	Qualquer pessoa que tiver acesso ao telefone da pessoa pode mexer no app.

4. Pontos de saída

Em muitos casos, as ameaças habilitadas pelos pontos de saída estão relacionadas às ameaças do ponto de entrada correspondente. Muitas vezes poderá, inclusive, ter múltiplas saídas, uma vez que a interação com o ponto de entrada pode mudar.

Exemplo prático:

ID Entrada	Ponto de Saída
1	Response HTTP
2	O acesso é somente leitura, a única pessoa que faz alterações no banco é quem cuida dos bancos de dados.
3	Caso faça login, o app receberá o token de sessão e armazenará ele.

Se você já tiver o código do aplicativo e tiver conhecimento técnico total sobre o funcionamento do mesmo, também poderá indicar os pontos de entrada e sáida conforme abaixo:

ID Entrada: 1
Descrição Entrada:
GET /usuario/$ID_USUARIO/perfil-usuário HTTP/1.1
Host: contabilivre.com.br

Authorization: $TOKEN_DE_SESSAO

Descrição Saída:
    HTTP/1.1 200 OK
    Content-Type: text/html

    $HTML_PERFIL_USUARIO

5. Ativos

O sistema deve ter algo que interesse ao invasor e esses itens ou áreas de interesse são definidos como ativos. Os ativos são essencialmente os alvos dos invasores, ou seja, são a razão pela qual as ameaças existirão.

Os ativos envolvidos no fluxo de informações devem ser definidos e avaliados quanto ao seu valor de confidencialidade, integridade e disponibilidade.

Os ativos são documentados no modelo de ameaça da seguinte forma:

ID : Um ID exclusivo é atribuído para identificar cada ativo. Isso será usado para fazer referência cruzada do ativo com quaisquer ameaças ou vulnerabilidades identificadas.
Nome : um nome descritivo que identifica claramente o ativo.
Descrição : uma descrição textual do que é o recurso e por que ele precisa ser protegido.
Níveis de confiança : o nível de acesso necessário para acessar o ponto de entrada é documentado aqui. Eles serão cruzados com os níveis de confiança definidos na próxima etapa.

Considere dados em trânsito e dados em repouso

Embora os dados em repouso às vezes sejam considerados menos vulneráveis do que os dados em trânsito, os invasores geralmente consideram os dados em repouso um alvo mais valioso do que os dados em movimento.

Proteger dados confidenciais em trânsito e em repouso é fundamental para as empresas modernas, pois os invasores encontram maneiras cada vez mais inovadoras de comprometer os sistemas e roubar dados.

6. Níveis de confiança

Os níveis de confiança representam os direitos de acesso que o aplicativo concederá a entidades externas.

Os níveis de confiança são documentados no modelo de ameaça da seguinte forma:

ID : Um número exclusivo é atribuído a cada nível de confiança. Isso é usado para fazer referência cruzada do nível de confiança com os pontos de entrada e ativos.
Nome : um nome descritivo que permite identificar as entidades externas que receberam esse nível de confiança.
Descrição : Uma descrição textual do nível de confiança detalhando a entidade externa que recebeu o nível de confiança.

Exemplo prático:

ID	Nome	Descrição
1	Usuário	Proprietário do perfil logado
2	Credenciais de Acesso ao Banco de Dados	Usuário e senha compartilhado com o time de desenvolvimento para acesso ao banco, possui permissão de leitura e escrita.
3	Desenvolvedores(as)	Equipe técnica com acesso ao ambiente para modificar ou corrigir o sistema.
4	Acesso SSH ao servidor	Precisamos rever como é esse acesso. Mas sabemos que o sistema de versionamento o usa para publicar o sistema.

7. Diagramas de fluxo de dados

Todas as informações coletadas nos permitem modelar com precisão o aplicativo por meio do uso de Diagramas de Fluxo de Dados ( DFDs ). Os DFDs nos permitirão entender melhor o aplicativo, fornecendo uma representação visual de como o aplicativo processa os dados.

A quantidade de informações a serem incluídas no diagrama de fluxo de dados depende de alguns fatores-chave:

Tipo de sistema que você está construindo - Os sistemas que não lidam com dados confidenciais ou são usados apenas internamente podem não precisar de tanto contexto quanto um sistema externo.
Contexto necessário de sua equipe de segurança - As equipes de segurança são precisas com o que procuram nos modelos de ameaças. Fale com sua equipe de segurança para confirmar a camada de profundidade necessária.

Considerações Finais

Existem algumas metodologias para modelar as ameaças a um sistema e cabe a cada equipe definir qual a mais apropriada para o caso.

No próximo artigo seguirei no Threat Modeling Process da OWASP com a etapa 2: determinar e classificar as ameaças.

Até lá.

Referências:

Threat Modeling Process OWASP
Curso de Modelagem de ameaças: identifique riscos na concepção do software - Alura
O papel do dev no processo de modelagem de ameaças | Izabela Matos - AppSec to Go
Curso Learning Threat Modeling for Security Professionals - LinkedIn Learning
Threat Modeling in 2021 with Adam Shostack - DevSecCon (Youtube)

Terminologias Utilizadas em Modelagem de Ameaças

brmartin | Bruno Martins — Sat, 25 Feb 2023 15:11:37 +0000

Em modelagem de ameaças utilizam-se algumas terminologias que podem não ser familiares para alguns profissionais, principalmente em início de carreira. Por isso achei útil compartilhar o guia abaixo:

Ameaça - Uma pessoa ou coisa que toma medidas para explorar (ou fazer uso de) as vulnerabilidades do sistema de uma organização-alvo, como parte de atingir ou promover sua meta ou objetivos.
Atacante: Quem realizou o ataque. Neste caso, o criminoso que invadiu o sistema e roubou os dados.
Ataque - Pode ser real ou hipotético, com base em possíveis ações ou ataques tentados por um cibercriminoso, como um ataque à rede da sua empresa.
Ativo - Coisas importantes para você, informações confidenciais. Por exemplo, dados PCI ou PII. Um ativo é algo que precisa de proteção.
Biblioteca de conteúdo - Uma base de conhecimento de padrões de risco, onde cada padrão consiste em um grupo lógico de ameaças de segurança, pontos fracos e contramedidas.
Contramedidas - Ações que podem ser implementadas para mitigar o impacto ou a probabilidade de uma ameaça.
Controles - São salvaguardas ou contramedidas que você implementa para evitar, detectar, neutralizar ou minimizar possíveis ameaças contra suas informações, sistemas ou outros ativos.
Componentes - Partes que compõem a representação como uma instância do EC2 ou uma API ou ainda uma função dentro de uma aplicação web. Os componentes podem ser aninhados uns nos outros.
Exploit: Conjunto de técnicas e tecnologia que explora uma vulnerabilidade.
Fluxos de dados - Como as informações e os ativos se movem entre os componentes.
Insider: Alguém interno que pode colaborar com o atacante para vazar informações ou comprometer a empresa.
Impacto - É uma medida do dano potencial causado por uma ameaça específica. Dependendo do negócio em que você atua, os ataques que expõem as informações do usuário podem resultar em uma ameaça física de dano ou perda de vida para seus usuários, aumentando consideravelmente o impacto das ameaças que permitiriam tal exposição.
Metadados do projeto - Nome, identificador, descrição, proprietário da coisa que você está modelando como ameaça.
Mitigações - São controles implementados para reduzir a probabilidade ou o impacto de uma ameaça, embora não necessariamente a impeçam completamente.
Modelo - Os modelos podem ser criados do zero ou gerados a partir de projetos pré-existentes para agilizar a criação de futuros modelos de ameaças. Os modelos costumam ser usados para fornecer o esqueleto de um modelo de ameaça para dar aos colegas uma vantagem inicial na análise do diagrama.
Padrões - Cada setor e país tem seus próprios padrões a serem seguidos ou considerados, desde saúde e finanças até organizações governamentais, como por exemplo o RGPD.
Pontuação de risco - Uma métrica para avaliar o nível de risco do seu negócio.
Probabilidade - É uma medida da possibilidade de uma ameaça ser realizada. Uma variedade de fatores pode impactar a probabilidade de uma ameaça ser executada, incluindo quão difícil é a implementação da ameaça e quão gratificante seria para o invasor.
RBAC/Role Based Access Controls - Um meio de restringir o acesso a usuários com base em suas funções, como Admin.
Representações - Uma perspectiva sobre o que está sendo modelado como ameaça, por exemplo, diagrama de arquitetura, diagrama de fluxo de dados, código-fonte, JIRA, interface do usuário.
Relatórios - Periodicamente, ao longo do ciclo de vida de um projeto, as equipes podem querer gerar relatórios executivos para capacitar internamente e fornecer às partes interessadas as informações de que precisam. Eles podem ser gerados para vários casos de uso, como um resumo de conformidade ou um relatório detalhado de todas as contramedidas identificadas
Risco - Riscos são a combinação de uma ameaça e uma vulnerabilidade. Da-se o nome de risco a potencial perda, dano ou destruição de qualquer coisa que seja valiosa para a empresa, como um sistema, reputação, etc.
Trust Zone - Os diferentes níveis de segurança e confiança. Internet x Web x App x Camada de dados.
Unidade de negócios - Um grupo de usuários e produtos dentro do sistema. Com permissões básicas, os usuários têm acesso apenas aos Produtos que estão em sua Unidade de Negócios e limitados à função que lhes foi atribuída.
Versionamento - O versionamento consiste em estratégias para gerenciar as diferentes versões de um código, de um sistema ou de um modelo. É uma forma de administrar as mudanças que são feitas e de garantir mais segurança na transição de uma versão para outra.
Vulnerabilidade - uma fraqueza ou brecha em um de nossos sistemas que pode ser explorado por um atacante e causar danos.

Caso você tenha alguma sugestão de terminologia que não encontrou na lista acima, por favor, deixe nos comentários.

Você também pode ler mais sobre fundamentos de segurança cibernética em outro post que publiquei por aqui.

Modelagem de Ameaças - Introdução

brmartin | Bruno Martins — Wed, 22 Feb 2023 21:43:09 +0000

TL:DR
Neste artigo compartilho uma introdução à Modelagem de Ameaças, a partir dos meus estudos sobre o tema.

Objetivos da Modelagem de Ameaças

Entender quem são seus "inimigos". O que os motiva e quais são seus objetivos.
Conhecer bem o seu próprio sistema.
Criar camadas de proteção.
Mitigar os riscos.

Corrigir um problema de segurança depois que o produto está desenvolvido e em produção pode custar centenas de vezes mais que prevenir ele em sua construção.

Visão Geral

A modelagem de ameaças é uma representação estruturada de todas as informações que afetam a segurança de um aplicativo, analisando através da perspectiva de um invasor em potencial, em oposição ao ponto de vista de um defensor. Em essência, é uma visão do aplicativo e seu ambiente pelas lentes da segurança.

Um modelo de ameaça geralmente inclui:

Descrição do assunto a ser modelado
Suposições que podem ser verificadas ou contestadas no futuro conforme mudanças no cenário de ameaças
Ameaças potenciais ao sistema
Ações que podem ser tomadas para mitigar cada ameaça
Uma forma de validação do modelo e ameaças, e verificação do sucesso das ações tomadas

O processo de modelagem de ameaças pode ser decomposto em três etapas:

Decompor o aplicativo
Determinar e Classificar as Ameaças
Determinar contramedidas e mitigação

Modelagem de ameaças em todo o ciclo de vida

A modelagem de ameaças é melhor aplicada continuamente ao longo de um projeto de desenvolvimento de software. O processo é essencialmente o mesmo em diferentes níveis de abstração, embora as informações fiquem cada vez mais granulares ao longo do ciclo de vida.

Idealmente, um modelo de ameaça de alto nível deve ser definido no início do conceito ou fase de planejamento e, em seguida, refinado ao longo do ciclo de vida. À medida que mais detalhes são adicionados ao sistema, novos vetores de ataque são criados e expostos. O processo contínuo de modelagem de ameaças deve examinar, diagnosticar e abordar essas ameaças.

A atualização dos modelos de ameaças é aconselhável após eventos como:

Um novo recurso é lançado
Ocorre um incidente de segurança
Mudanças arquitetônicas ou de infraestrutura

A estrutura de quatro perguntas a seguir pode ajudar a organizar a modelagem de ameaças:

Em que estamos trabalhando? => Avalie o escopo - Isso pode ser tão pequeno quanto um sprint ou tão grande quanto um sistema inteiro.
O que pode dar errado? => Identifique o que pode dar errado - Isso pode ser tão simples quanto um brainstorm ou tão estruturado quanto usar STRIDE, Kill Chains ou Attack Trees.
O que você irá fazer sobre isso? => Identifique contramedidas ou gerencie riscos - Decida o que você fará com cada ameaça. Isso pode ser para implementar uma mitigação ou aplicar as abordagens aceitar/transferir/eliminar do gerenciamento de riscos.
Fizemos um bom trabalho? => Avalie seu trabalho - Você fez um trabalho bom o suficiente para o sistema em questão?

Considerações Finais

Esse artigo foi uma introdução sobre Modelagem de Ameaças, que terá continuidade nas próximas publicações com os temas Decompondo a Aplicação, Determinando e Classificando Ameaças, e Contramedidas e Mitigação.

Até lá!