Forem: brmartin | Bruno Martins

Compreendendo o SAMM

brmartin | Bruno Martins — Fri, 12 Jul 2024 21:13:38 +0000

Quem trabalha com desenvolvimento de aplicações ou segurança cibernética possivelmente já ouviu falar da OWASP e seus principais projetos. Nesse artigo vou falar um pouco sobre o Software Assurance Maturity Model - SAMM.

OWASP

Se essa é a primeira vez que escuta sobre a OWASP, convido-o a visitar o site oficial e ler um rápido artigo que escrevi há um tempo. Uma breve descrição seria:

A OWASP (Open Web Application Security Project) é uma fundação sem fins lucrativos dedicada ao aprimoramento da segurança de software. Por meio de projetos de código aberto colaborativos, uma vasta rede de comunidades locais globais, dezenas de milhares de membros e conferências educacionais de destaque, a OWASP Foundation se destaca como uma referência para desenvolvedores e profissionais de tecnologia que buscam proteger a web.

Portanto, a OWASP é conhecida por seus recursos, ferramentas e documentações, que são amplamente utilizados por profissionais de segurança da informação.

Projeto SAMM

Sobre o SAMM eu diria que o objetivo desse framework é entender o ponto de maturidade que a empresa avaliada se encontra no momento da entrevista e em qual ponto se deseja chegar, em termos de práticas de segurança. A partir desse entendimento, formular ou melhorar, e implementar uma estratégia com processos definidos adaptados ao apetite de riscos da Organização, que pode ser integrada ao Software Development Lifecycle (SDLC) existente.

Essa avaliação pode ser realizada de forma externa, através de um avaliador externo, ou através de uma autoavaliação realizada por uma equipe interna de segurança. A representação de todos os stakeholders é fundamental para o sucesso da atividade.

A estrutura do framework é dividida em 5 áreas de negócios com cada uma subdividida em três práticas de segurança: Governança (Estratégia e Métricas / Política e Conformidade / Educação e Orientação), Design ( Avaliação de Ameaça / Requisitos de Segurança / Arquitetura Segura), Implementação (Construção Segura / Implantação Segura / Gestão de Defeitos), Verificação (Avaliação de Arquitetura / Testes Orientados a Requisitos / Teste de Segurança), Operações (Gestão de Incidentes / Gestão Ambiental / Gestão Operacional).

Por fim, para cada prática de segurança, o SAMM define dois fluxos (stream) e três níveis de maturidade.

É importante destacar, que este modelo necessita de reavaliações contínuas. O monitoramento e ajustes das práticas é um ponto crucial para a melhoria contínua.

A planilha de Assessment Interview
Na primeira aba, estão os campos que deverão ser respondidos com base nas respostas dadas na entrevista.

A segunda aba apresenta o Scorecard. Facilitando a visualização da pontuação atingida e quais pontos necessitam de melhorias.

Na terceira aba encontramos o Roadmap, onde são descritas as ações e iniciativas a serem implementadas em cada fase do processo de maturidade, com base na avaliação inicial de maturidade (scorecard) e nos objetivos de segurança da organização.

E por fim, na última aba o Roadmap Chart é a representação visual do roadmap.

Como busquei o entendimento

Venho estudando muitos assuntos importantes para os profissionais de AppSec e o tema atual tem sido o SAMM. Dentro desse tópico, o conteúdo em vídeo (em português) do Eduardo B. Santos, MSc com teoria e demonstração prática como também o curso oficial (em inglês) do SAMM têm me ajudado bastante a consolidar conceitos que venho aplicando nas aulas do Luiz Henrique Custódio, onde tivemos a oportunidade de colocar a mão na massa e praticar em estudos de caso.

Prática

Durante o treinamento da Conviso, o Luiz Henrique Custódio nos desafiou a realizar um assessment utilizando o SAMM. O SAMM disponibiliza uma planilha Assessment Interview, para ser utilizada como guia da entrevista de assessment. Estudos de caso e uma documentação extensa também estão disponíveis no site oficial do projeto OWASP SAMM.

Divididos em grupos, nossa tarefa era ler a documentação do estudo de caso e fazer perguntas pontuais ao cliente imaginário.

Esta atividade consistia em analisar uma empresa fictícia chamada CNVS BANKING, uma empresa especializada em serviços bancários com um quadro de 500 colaboradores, sendo 50 profissionais na equipe de TI.

Lembrando que não existem respostas certas ou erradas, fomos analisando o texto do estudo de caso e, na falta de informações, questionávamos o Luiz, nosso cliente imaginário, para maiores entendimentos.

Em situações reais, é aconselhável que se realize uma entrevista por área de negócio, mas com participantes plurais, ou seja, de áreas distintas que estejam envolvidas naquele ponto. Dessa forma, começamos não apenas a avaliar, mas entender a dor de cada um.

Embora a atividade de preencher a planilha seja muito simples, ela se torna desafiadora quando obter as informações do ambiente o mais fidedignas possíveis é algo muito complexo. Aqui não se buscam evidências.

O propósito principal não é auditar, mas gerar um autoconhecimento, buscando autonomia e aprendizado para elevação da maturidade do ambiente. Como consequência, cria-se uma cultura de proximidade entre equipes de desenvolvedores, de segurança e demais áreas envolvidas, onde uma enxerga a dor da outra, e o entendimento do propósito de se buscar uma elevação da maturidade.

Não trarei todas as avaliações de maturidade para não me estender muito, mas durante essa atividade alguns pontos me chamaram atenção, como o fato do time de DevOps afirmar que a modelagem de ameaças está em elaboração, porém o time de desenvolvimento não saber do que se trata. Notei uma falta de proximidade e comunicação entre as equipes, a qual levará a uma entrega que possivelmente criará atritos e ausência de engajamento. Assim, uma baixa pontuação foi atingida em Design.

Pelo lado positivo, as documentações de boas práticas de gerenciamento de secrets e o processo de priorização, realizado pelo analista de Appsec responsável pelo squad, garantindo que as particularidades de cada projeto sejam tratadas de acordo, no meu entendimento elevaram o nível de maturidade das práticas de segurança na Implementação.

Pude constatar após a atividade prática, a importância da realização das entrevistas e o uso do SAMM para a elevação da maturidade de segurança no desenvolvimento de software. Ele nos traz uma visão mais clara do ambiente de uma determinada empresa e ajuda no planejamento dos próximos passos para tornar uma aplicação mais segura possível.

A melhor maneira de entender o SAMM é começar a usá-lo.

SAMMwise

O readme do repositório do projeto assim o define:

“SAMMwise é um Web App de código aberto para calcular a pontuação de Maturidade de um indivíduo, empresa ou projeto usando o modelo SAMM. O aplicativo o orienta pela avaliação, permite que você salve e reutilize avaliações concluídas anteriormente e apresenta os resultados em um estilo semelhante à planilha.”

Seria então uma forma mais “moderna” de adoção do SAMM. Se desejar saber um pouco mais sobre a ferramenta, aconselho a leitura do artigo do Diego Pereira, Utilizando SAMMWise.

OpenCRE

Nesse período de estudo tive a grata surpresa de descobrir o OpenCRE.

O projeto Open Source "OpenCRE" integra todos os padrões e diretrizes de segurança no nível de requisitos em um recurso unificado e harmonizado. Usar o OpenCRE com o SAMM oferece benefícios como acesso a recursos adicionais, comparação com outros padrões de segurança e eliminação de lacunas entre diferentes estruturas de segurança.

Para quem já está surfando a onda das IAs, eles oferecem também um chatbot.

Em um cenário onde a cibersegurança é vital, o SAMM é um guia valioso para proteger aplicações de forma eficaz.

Em meus estudos não encontrei a planilha em português, porém quem tiver ou souber da existência de uma tradução do material seria interessante compartilhar nos comentários. Afinal, esse é o propósito de comunidades como a OWASP, ambientes colaborativos em prol da evolução da segurança da web.

Aproveito para deixar como sugestão de leitura, uma série de artigos que explicam ponto a ponto a estrutura do framework SAMM.

Programa de segurança de aplicações baseado no OWASP SAMM

Aproveitem!

Defense-in-Depth: Por que essa estratégia é importante?

brmartin | Bruno Martins — Tue, 14 Mar 2023 17:49:26 +0000

1. O princípio da Defesa em Profundidade

O princípio de Defesa em Profundidade é uma estratégia de segurança da informação e cibernética que se baseia na aplicação de várias camadas de controles de segurança para proteger os ativos de uma organização. Baseia-se na ideia de que, se uma camada de segurança falhar, as outras camadas ainda poderão proteger o ativo.

Tem como objetivo criar um ambiente seguro que seja resiliente a ataques e possa detectar e responder rapidamente a quaisquer incidentes de segurança.

Se um invasor externo derrubar uma linha de defesa ou uma ameaça interna comprometer parte da rede de uma organização, outras medidas de segurança podem ajudar a limitar e mitigar os danos a toda a rede.

1.2 Pilares

Existem três partes principais de qualquer estratégia de defesa em profundidade, que são:

Controles físicos: medidas de segurança que impedem o acesso físico a sistemas de TI, como vigilância, câmeras de segurança, leitores de impressão digital e portas trancadas.
Controles técnicos: medidas de segurança que protegem a segurança da rede e outros recursos de TI usando hardware e software, como sistemas de proteção contra intrusões, firewalls de aplicativos web (WAF), gerenciamento de configurações, proxy, scanners da web, gestão de identidades e acessos, antivírus e anti-malwares, sistemas de prevenção de perda de dados, sistemas de autenticação de dois fatores, biometria, gerenciadores de senhas, redes privadas virtuais, criptografia de dados, sistemas de backups etc.
Controles administrativos: medidas de segurança que se referem às políticas e procedimentos direcionados aos funcionários de uma organização e seus fornecedores e parceiros comerciais. Os exemplos incluem: políticas de privacidade e proteção de dados, gerenciamento de riscos de colaboradores terceiros, parceiros comerciais e fornecedores, políticas de treinamento e conscientização de segurança, adoção de metodologias para promover a melhoria contínua e garantir as melhores práticas etc.

Img/Fonte: Imperva

1.3 Segurança em camadas

A segurança em camadas refere-se ao uso de vários produtos e práticas de segurança para proteger uma organização contra um vasto spectrum de ameaças físicas e cibernéticas.

No geral, uma arquitetura de defesa em profundidade é composta por sete camadas de proteção.

1- Política, procedimentos e conscientização

Trata-se da camada responsável por implementar as políticas e os procedimentos que irão governar as práticas de segurança da informação e segurança cibernética de uma empresa, bem como as ações de conscientização, treinamento e educação dessas práticas em geral que deverão ser seguidas e desempenhadas por todos os funcionários, fornecedores e parceiros comerciais da empresa.

2- Segurança física

Considerada a primeira barreira de proteção de uma infraestrutura de TI, a camada de segurança física tem como objetivo garantir que as ameaças não tenham acesso físico aos ativos tangíveis, como pessoas, servidores, desktops, dispositivos de rede – switches, roteadores, racks de telecomunicação, racks de redes – path panels, painéis de controle elétricos, painéis de controle de climatização, dispositivos de armazenamento de dados e outros recursos valiosos.

3- Segurança de perímetro

A camada segurança de perímetro, tem como objetivo implementar a proteção necessária entre o ambiente externo e a infraestrutura de TI interna da empresa. A defesa de perímetro permite a entrada de dados autorizados, bloqueando o tráfego suspeito.

Esta camada é composta por mecanismos e ferramentas de proteção de borda tais como: roteadores, switches layer 3, appliances de firewall, sistemas de IDS e IPS e sistemas DLPs. Além de esquemas como DMZ – zonas desmilitarizadas de rede, sistemas de proxy e conversão de endereços de rede (NAT), VPN, dentre outras tecnologias de proteção.

4- Segurança de rede interna

A camada de segurança de rede interna deve possuir mecanismos e ferramentas de proteção capazes de lidar com a identidade e autenticação dos usuários da rede, autorizando ou não, o acesso destes usuários aos recursos computacionais e de redes disponíveis na infraestrutura de TI, protegendo os dados e informações que navegam pela rede, além de outros mecanismos e ferramentas que exerçam funções relacionadas a filtros que permitam analisar de forma consistente todos os pacotes de dados que circulam pela mesma.

5- Segurança de host

A camada de segurança de host, concentra-se em manter a proteção dos hosts (computadores, notebooks, smartphones, servidores, etc) e respectivamente dos sistemas operacionais que controlam estes hosts.

Para manter a segurança dos hosts fortalecida algumas ações são importantes. Atualização dos sistemas operacionais, remoção de funcionalidades e recursos desnecessários e redução da superfície de ataque.

6- Segurança da aplicação

A camada de segurança aplicação tem como objetivo garantir a segurança e proteção de aplicativos, sistemas de informação e demais outras aplicações contra diversas ameaças.

7- Segurança de dados

Trata-se da camada de segurança mais profunda da estratégia de defesa em profundidade e tem como principal objetivo proteger um dos ativos de TI mais valiosos que a empresa possui, os “dados”.

Img/Fonte: TechTarget

1.4 Segurança integrada

Garante que vários produtos de segurança funcionem entre si para melhorar sua capacidade de detectar e mitigar ameaças. Uma estratégia de segurança pode ser em camadas, mas não integrada, enquanto uma estratégia de segurança integrada é em camadas por natureza.

2. Fazendo uma analogia (relembrando minha época de aviação)

Em segurança da aviação aborda-se com frequência o modelo do queijo suíço, que vejo ter importância também na segurança cibernética.

No modelo do queijo suíço, as defesas de uma organização contra falhas são modeladas como uma série de barreiras, representadas como fatias (camadas, na defesa em profundidade) de queijo e, quanto mais fatias há, mais segurança haverá.

Porém, orifícios (vulnerabilidades) nas fatias de queijo representam pontos fracos individuais em partes individuais do sistema e variam continuamente em tamanho e posição em todas as fatias. Quando esses orifícios se alinham, ocorre o acidente (em segurança cibernética, o vazamento de dados, exploit, etc).

James Reason propõe que todo perigo possui barreiras e salvaguardas, e que na ocasião de um acidente é importante detectar como e porque estas barreiras falharam.

Conclusão

Conforme visto acima, introduzir mecanismos e ferramentas de proteção em camadas e de forma integrada são essenciais para a manutenção da disponibilidade, integridade e confidencialidade dos ativos de uma organização. Não é possível acabar com as ameaças, mas mitigar seus efeitos ou eliminar as vulnerabilidades cabe à organização.

Como você trata ou trataria esse tema na sua empresa? Deixe aqui nos comentários.

Até o próximo artigo!

Conhecendo a Área de Segurança Cibernética

brmartin | Bruno Martins — Tue, 07 Mar 2023 14:26:49 +0000

Resolvi publicar esse texto para ajudar a esclarecer algumas dúvidas de pessoas que se interessam por segurança cibernética, mas não sabem exatamente qual caminho seguir.

1. O que é segurança cibernética?

A segurança cibernética é a prática de proteger computadores, redes, aplicações de software, sistemas essenciais e dados de possíveis ameaças digitais.

1.1 Sub áreas

A área de segurança cibernética é muito ampla e se relaciona com diversas outras áreas. A National Cybersecurity Workforce Framework categoriza o trabalho da segurança cibernética em sete categorias. E dentro de cada categoria encontraremos várias áreas de especialização.

Operar e manter inclui proporcionar o suporte, a administração e a manutenção necessários para garantir a segurança e o desempenho do sistema de TI.

Proteger e defender inclui a identificação, a análise e a mitigação de ameaças a sistemas internos e a redes.

Investigar inclui a investigação de evento e/ou crimes digitais que envolvem recursos de TI.

Coletar e operar inclui as operações de negação e fraude especializadas e a coleta de informações de segurança cibernética.

Analisar área responsável pela revisão e avaliação altamente especializadas da entradda de informações de segurança digital para determinar sua utilidade para a inteligência.

Supervisionar e governar proporciona liderança, gestão e orientação para realizar o trabalho de segurança cibernética de forma eficaz.

Provisionar de forma segura inclui a conceitualização, o projeto e a construções de sistemas de TI seguros.

1.2 Roadmaps

Roadmaps são meios interessantes de se buscar tópicos de estudo e iniciar a busca por conhecimento na área. Mas é importante entender qual especialização você deseja buscar para ser mais assertivo na hora de estudar.

Sei que pode ser difícil tomar essa decisão no início, por isso compartilho abaixo dois links de roadmaps elaborados pela comunidade que podem auxiliar.

1.3 Certificações

Outra forma de traçar uma rota de estudos e aprofundar conhecimento é através das certificações. O setor de TI estabeleceu padrões para que os especialistas em segurança cibernética obtenham certificações profissionais que fornecem provas das qualificações profissionais e do nível de conhecimento. Na minha opinião, mais importante que obter a própria certificação será o conhecimento adquirido e especializado.

Abaixo você pode verificar um repositório da comunidade DevSecOps Global, onde pude contribuir, que contém algumas certificações importantes na área de DevSecOps.

Certifications Guide

Busque também aprendizado gratuito através da Cisco e seu programa de CiberEducação.

1.4 Junte-se a organizações profissionais

Participe de organizações de segurança da informação, participe de reuniões e conferências, participe de fóruns e blogs para obter conhecimento com os especialistas.

Confundi?

Posso ter confundindo ainda mais alguns, mas como disse lá em cima, é uma área muito ampla e com diversos caminhos distintos que podem ser seguidos, desde algo mais relacionado a desenvolvimento de sistemas, passando por redes, hardwares, fraudes e até mesmo atividades de conscientização.

Se tiver alguma dúvida, quiser ajuda para buscar alguma informação ou dar uma sugestão, deixe aqui nos comentários abaixo.

Até o próximo artigo!

WAF: o que é e qual sua função

brmartin | Bruno Martins — Thu, 02 Mar 2023 21:53:42 +0000

O Web Application Firewall é uma ferramenta utilizada para ajudar a proteger os aplicativos web, formando uma camada de proteção, atuando na camada 7 (camada de aplicação) do modelo OSI, ou seja, ele fica localizado entre a aplicação e a internet. Sua principal função é fornecer segurança, garantindo que determinadas ações de chamadas, sejam elas de entradas ou saídas, sejam barradas de acordo com as regras pré-definidas.

O WAF funciona como um proxy reverso que protege o servidor contra exposição, garantindo que nenhum cliente se comunique diretamente com esse, gerando os logs, realizando o balanceamento de carga e fazendo uma proteção a mais da rede. Ou seja, ele monitorara, filtra e bloqueia automaticamente o tráfego de dados maliciosos

Os WAFs protegem as aplicações voltadas para a Internet contra ataques como resultado da inteligência integrada contra ameaças que agrega várias fontes e regras de detecção do Open Web Application Security Project (OWASP)

(Fonte: CloudFlare)

Um WAF pode operar com uma lista de bloqueio protegendo contra ataques conhecidos. Chamamos essa forma de Modelo de Segurança Negativo. Em contrapartida há o Modelo de Segurança Positivo que opera com uma lista de permissões.

Existem 3 tipos de WAF:

WAFs de rede -> Geralmente é um hardware instalado localmente.
WAFs de host -> Baseado em hospedagem que pode ser integrado ao software e traz como vantagem uma maior possibilidade de personalização com um custo baixo.
WAFs na nuvem -> Os WAFs hospedados na nuvem geralmente são administrados pelos provedores do serviço.

Sugestão

Para um melhor entendimento sobre WAF é importante conhecer as camadas de protocolos, modelos OSI e TCP/IP, onde cada uma (camada) desempenha uma determinada função.

Se ficou alguma dúvida, deixe nos comentários.

Até o próximo!

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á!

Eu me associei à OWASP

brmartin | Bruno Martins — Sat, 18 Feb 2023 13:57:07 +0000

Quem é a OWASP?

A Open Web Application Security Project ® (OWASP) é uma fundação sem fins lucrativos que trabalha para melhorar a segurança do software. Por meio de projetos de software de código aberto liderados pela comunidade, centenas de comunidades locais em todo o mundo, dezenas de milhares de membros e importantes conferências educacionais e de treinamento, a OWASP Foundation é a fonte para desenvolvedores e tecnólogos protegerem a web.

Por que se associar?

Para responder a essa pergunta podemos ter os mais variados motivos. Primeiramente, é uma forma de colaborar financeiramente com a Fundação para que possam continuar desenvolvendo atividades que agregam enormemente na missão de proteção da web.

Eu particularmente decidi me associar por achar que pode ser um alavancador para a carreira na área de segurança e desenvolvimento. Ao se tornar membro você tem a possibilidade de aumentar sua rede de contatos, ter descontos em treinamentos e eventos, oportunidades de voluntariado, contribuição em projetos, etc.

Após me associar, tive acesso a benefícios que, particularmente, achei muito interessantes. Passei a ter gratuitamente conta de dois ambientes de treinamentos online chamados SecureFlag e Security Journey e uma conta na Ubiq.

SecureFlag

Os desenvolvedores localizam, exploram e corrigem manualmente o código de aplicativos vulneráveis executados em ambientes de desenvolvimento acessados por meio de um navegador da web. A plataforma oferece treinamento 100% prático, sem perguntas de múltipla escolha, e usa um mecanismo capaz de testar ao vivo as alterações do código para medir a eficácia, exibindo instantaneamente se o código foi corrigido e concedendo pontos após a conclusão do exercício.

Security Journey

Por meio de desafios e competições, o Security Journey ajuda você a progredir em uma missão orientada por mapas para obter cinturões e conquistas de nível superior . Os alunos podem ver seu progresso em sua jornada à medida que aumentam seus conhecimentos de segurança.

Ubiq Security

Criptografe seus dados mais confidenciais antes que eles saiam do aplicativo, para que a camada de armazenamento – e os adversários – vejam apenas o texto cifrado. A criptografia nativa do lado do cliente do aplicativo protege os dados contra invasores sofisticados, ataques à cadeia de suprimentos e ameaças internas.

Como encontrá-los

Se você também achou interessante e gostaria de saber mais sobre o trabalho feito pela OWASP, visite os links que deixei abaixo:

Projetos OWASP
Comunidades Locais
OWASP Top 10
OWASP SAMM

Você sabia? - Curiosidades JAVA

brmartin | Bruno Martins — Fri, 17 Feb 2023 21:42:29 +0000

Bytecode, o código de máquina da JVM, tem esse nome por um simples motivo.

A máquina virtual Java entende um conjunto de comandos, que também são chamados de opcodes (operation code), e cada opcode possui o tamanho de exatamente 1 Byte. Daí surgiu o nome Bytecode, que nada mais é do que um opcode de 1 Byte.

Uma explicação além...

Há alguns anos atrás as linguagens, como o Visual Basic da Microsoft por exemplo, eram muito específicas para determinados SOs, hardwares, configurações e tudo mais. Ou seja, o código precisava ser reescrito diversas vezes a cada necessidade diferente.

Assim, Gosling para tentar resolver esse problema, desenvolveu a Máquina Virtual Java (JVM). Um intermediário que traduz ou instrui o sistema operacional acerca dos comandos a serem enviados e recebidos.

O código Java, quando compilado, gera um formato chamado bytecode Java, de extensão .class, que é lido pela JVM.

Um exemplo de bytecode:

 Code:
   0: new              
   3: dup
   4: invokespecial    
   7: astore_1
   8: aload_1
   9: ldc             
   11: putfield        
   14: return

Interessante, não?

Princípios de Segurança Cibernética

brmartin | Bruno Martins — Thu, 16 Feb 2023 19:06:02 +0000

Todos os dados precisam de alguma forma de segurança, mesmo os dados que não são confidenciais (como dados destinados à exibição pública) precisam de proteção para garantir a disponibilidade.

Vou começar apresentando os três pilares da Segurança da Informação.

1. CIA Triad

Confidentiality (confidencialidade) - A característica dos dados ou informações quando não são disponibilizados ou divulgados a pessoas ou processos não autorizados.

Exemplos de quebra de confidencialidade: escalonamento de privilégios e quebra de senhas.

Integrity (integridade) - A propriedade da informação pela qual ela é registrada, usada e mantida de forma a garantir sua integridade, precisão, consistência interna e utilidade para um propósito declarado.

Exemplos de quebra de integridade seria quando um funcionário tenta alterar a planilha de pagamentos sem permissão para tal ou,
quando um attacker utiliza a técnica Man-in-the-middle e intercepta o tráfego de rede, ficando no meio da comunicação e monitorando tudo o que está acontecendo.

Availability (disponibilidade) - Garantir acesso oportuno e confiável e uso de informações por usuários autorizados.

Um exemplo de quebra de disponibilidade é o ataque DoS (Negação de Serviço), onde ocorre um bombardeamento em um sistema com uma quantidade esmagadora de tráfego fazendo com que o mesmo fique indisponível.

2. Controle de Acesso

Identificação

Envolve fazer uma reivindicação de identidade. O usuário faz uma declaração, mas pode estar fazendo uma declaração falsa.

A identificação eletrônica geralmente utiliza usernames.

Autenticação (Authentication)

Processo de controle de acesso que compara um ou mais fatores de identificação para validar que a identidade reivindicada por um usuário ou entidade é conhecida pelo sistema.

Existem 3 métodos comuns de autenticação:

Algo que você conhece (ex: senha)
Algo que você tem (ex: tokens)
Algo que você é (ex: biometria)

Existem dois tipos de autenticação. O uso de apenas um dos métodos é conhecido como Autenticação de Fator Único (SFA). A concessão de acesso após a demonstração ou exibição bem sucedida de dois ou mais métodos é conhecida como Autenticação Multifator (MFA).

Autorização

Garante que uma ação é permitida. Serviços de autorização determinam quais recursos os usuários podem acessar, juntamente com as operações que os usuários podem executar.

Geralmente assume a forma de listas de controle de acesso que detalham as permissões especificas que são concedidas a um usuário individual ou grupo de usuários.

Accouting

Mantém controle sobre o que os usuários fazem, incluindo o que acessam, a quantidade de tempo que acessam os recursos e as alterações feitas.

3. Riscos

Riscos são a combinação de uma ameaça e uma vulnerabilidade. Ocorrem quando um ambiente contém uma vulnerabilidade e uma ameaça correspondente que pode explorar essa vulnerabilidade.

Gerenciamento de Risco

Um ativo é algo que precisa de proteção.
Uma vulnerabilidade é uma lacuna ou fraqueza nesses esforços de proteção. É uma fraqueza ou falha inerente em um sistema ou componente que, se desencadeada ou atuada, pode causar a ocorrência de um evento de risco. Poderá ser explorada por uma ameaça.

Exemplos de vulnerabilidades: ausência de patches, regras frágeis de firewall, configurações incorretas.

Uma 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.
* Vetor de Ameaça: O meio pelo qual um ator de ameaça realiza seus objetivos. Método que um invasor usa para chegar ao seu alvo.
* Agente de ameaça: Um indivíduo ou grupo que tenta explorar vulnerabilidades para causar ou forçar a ocorrência de uma ameaça.
Probabilidade de ocorrência é um fator ponderado com base em uma análise subjetiva da probabilidade de uma determinada ameaça ser capaz de explorar uma determinada vulnerabilidade ou conjunto de vulnerabilidades.

Avaliação de risco (Risk Assessment)

A avaliação de riscos  é definida como o processo de identificação, estimativa e priorização de riscos para as operações de uma organização (incluindo sua missão, funções, imagem e reputação), ativos, indivíduos, outras organizações e até mesmo a nação.

Tratamento de risco (Risk Treatment)

Analisa e implementa possíveis respostas para controlar o risco.

Risk Transference - A transferência de risco é a prática de transferir o risco para outra parte, que aceitará o impacto financeiro do dano resultante da realização de um risco em troca de pagamento. Normalmente, esta é uma apólice de seguro.

Risk Avoidance - A prevenção do risco é a decisão de tentar eliminar totalmente o risco. Mudar as práticas de negócios para tornar um risco irrelevante.

Risk Acceptance - Aceitação de risco é não tomar nenhuma ação para reduzir a probabilidade de ocorrência de um risco.

Risk Mitigation - A mitigação de riscos é o tipo mais comum de gerenciamento de riscos e inclui a tomada de ações para prevenir ou reduzir a possibilidade de um evento de risco ou seu impacto.

Prioridades de risco (Risk Priorities)

Quando os riscos forem identificados, é hora de priorizar e analisar os principais riscos por meio da análise de risco qualitativa e/ou análise de risco quantitativa.

Um método eficaz para priorizar o risco é usar uma matriz de risco, que ajuda a identificar a prioridade como a interseção da probabilidade de ocorrência e impacto.
Ao tomar decisões com base nas prioridades de risco, as organizações devem avaliar a probabilidade e o impacto do risco, bem como sua tolerância a diferentes tipos de risco.

Tolerância ao risco (Risk Tolerance)

O nível de tolerância ao risco varia entre as organizações e até internamente: departamentos diferentes podem ter atitudes diferentes em relação ao risco aceitável ou inaceitável.

4. Controles de Segurança

Os controles de segurança referem-se aos mecanismos físicos, técnicos e administrativos que atuam como salvaguardas ou contramedidas prescritas para um sistema de informação para proteger a confidencialidade, integridade e disponibilidade do sistema e de suas informações.

Controles físicos (physical controls)

Os controles físicos atendem às necessidades de segurança baseadas em processos usando dispositivos físicos de hardware, como leitores de crachás, características arquitetônicas de prédios e instalações e ações de segurança específicas a serem tomadas pelas pessoas.

Muitos tipos de mecanismos de controle de acesso físico podem ser implantados em um ambiente para controlar, monitorar e gerenciar o acesso a uma instalação.

Controles técnicos

Controles técnicos (também chamados de controles lógicos) são controles de segurança que sistemas de computador e redes implementam diretamente.

Os controles técnicos podem ser definições de configuração ou parâmetros armazenados como dados, gerenciados por meio de uma interface gráfica do usuário (GUI) de software, ou podem ser configurações de hardware feitas com interruptores, plugues de jumper ou outros meios.

Controles administrativos (administrative controls)

Os controles administrativos (também conhecidos como controles gerenciais) são diretrizes, guias ou conselhos dirigidos às pessoas dentro da organização. Eles fornecem estruturas, restrições e padrões para o comportamento humano e devem cobrir todo o escopo das atividades da organização e suas interações com partes externas e partes interessadas.

5. Governança

O grande desafio da governança é equilibrar os interesses dos diversos envolvidos garantindo a continuidade do negócio e a geração de valor para os acionistas. Em seus valores fundamentais estão: Fairness (senso de justiça), Disclosure (transparência), Accountability (responsabilidade) e Compliance (conformidade).

Regulamentos e leis

Os regulamentos e leis (regulations and laws) são comumente emitidos na forma de leis, geralmente do governo (não confundir com governança) e geralmente acarretam penalidades financeiras por descumprimento.

Um exemplo é o Regulamento Geral de Proteção de Dados (GDPR);

Políticas

As políticas (policies) são implementadas pela governança organizacional, como a gestão executiva, para fornecer orientação em todas as atividades para garantir que a organização suporte os padrões e regulamentos do setor.

Padrões

Os padrões (standards) são frequentemente usados pelas equipes de governança para fornecer uma estrutura para introduzir políticas e procedimentos em apoio aos regulamentos.

Ex1: Organização Internacional de Padronização (ISO);
Ex2: Internet Engineering Task Force (IETF) , existem padrões em protocolos de comunicação que garantem que todos os computadores possam se conectar entre si através das fronteiras

Por exemplo, uma empresa estabelece uma política de senhas. O padrão é que as senhas requerem um mínimo de oito caracteres alfanuméricos maiúsculos e minúsculos, incluindo pelo menos um caractere especial. Um usuário deve alterar a senha a cada 30 dias e um histórico das 12 senhas anteriores garante que o usuário crie senhas exclusivas durante um ano.

Procedimentos

Os procedimentos (procedures) são as etapas detalhadas para concluir uma tarefa que oferece suporte às políticas departamentais ou organizacionais. Os procedimentos definem as atividades explícitas e repetíveis necessárias para realizar uma tarefa específica ou um conjunto de tarefas.

A figura mostra um exemplo do procedimento usado para alterar uma senha.

6. Outros Conceitos Importantes

Privacy (privacidade) -O direito de um indivíduo de controlar a distribuição de informações sobre si mesmo.

Non-repudiation - A incapacidade de negar a realização de uma ação, como criar informações, aprovar informações e enviar ou receber uma mensagem. Impede alguém de negar a verdade.

Criticality (criticidade) - Uma medida do grau em que uma organização depende da informação ou sistema de informação para o sucesso de uma missão ou de uma função de negócios.

Conclusão

A área de cibersegurança é muito ampla, mas os conceitos apresentados acima são uma base importantíssima para qualquer profissional que deseje trabalhar garantindo a confidencialidade, integridade e disponibilidade de seus produtos ou serviços.

Introdução às WEB APIs

brmartin | Bruno Martins — Thu, 16 Feb 2023 13:04:03 +0000

As APIs são os blocos de construção do software moderno porque permitem o compartilhamento de recursos e serviços entre aplicativos, organizações e dispositivos. Uma API é um conjunto de diretrizes ou regras que indicam como os aplicativos interagem. Uma API permite que um aplicativo solicite dados de outro sistema.

Você pode pensar nas APIs como sendo um garçom em um restaurante, servindo como um intermediário entre o cliente e a cozinha.

Um cliente que quer sopa não vai para a cozinha cozinhar. Eles nem precisam saber fazer sopa! Eles só precisam saber como pedir sopa ao garçom e esperar que o garçom traga a sopa de volta . As APIs funcionam da mesma forma, mas há nomes diferentes para os jogadores envolvidos. Em vez de sopa, o solicitante pode solicitar dados ou execução de um serviço.

Cliente = Cliente (solicitante. Ex: navegador, aplicativo web, aplicativo móvel)
Garçom = API (interface simplificada para interagir com o back-end)
Cozinha = Servidor (back-end onde o processamento acontece)

Anatomia de uma solicitação de API

Nome	Descrição
Endpoint	A URL que você solicita
Método	O tipo do pedido (GET, POST, DELETE, etc)
Cabeçalho	Informações adicionais para o cliente ou o servidor
Corpo	Informações enviadas ao servidor

Acessibilidade

As APIs variam no escopo de quem pode acessá-las.

APIs públicas (também conhecidas como APIs abertas) - consumíveis por qualquer pessoa que saiba sobre a API
APIS privadas - consumíveis apenas dentro de uma organização e não tornadas públicas.
APIs de parceiros - consumíveis entre uma ou mais organizações que possuem um relacionamento estabelecido.

Arquiteturas

Há mais de uma maneira de criar e consumir APIs. Alguns tipos de arquitetura que você pode encontrar são:

REST (Transferência de Estado Representacional)
GraphQLGenericName
WebSockets
webhooks
SOAP (Simple Object Access Protocol)
gRPC (chamada de procedimento remoto do Google)
MQTT (Transporte de Telemetria MQ)

APIs REST

As APIs REST se comunicam por meio de solicitações HTTP para executar operações CRUD (ou criar, ler, atualizar e excluir). Algumas características das APIs REST incluem não armazenar o estado da sessão entre as solicitações, a capacidade de armazenar em cache e a capacidade de enviar e receber vários tipos de dados.

As APIs REST seguem seis princípios de design que são os seguintes:

Separação cliente-servidor
Stateless
Armazenável em cache
Sistema em Camadas
Interface uniforme
Code on Demand (opcional)

Métodos HTTP

O HTTP possui um número fixo de métodos que o cliente pode usar para indicar que tipo de operação deseja realizar por meio da solicitação. Esses métodos de solicitação também são conhecidos como verbos HTTP.

POST - é usada para enviar alguns dados para o servidor. - Create
GET - é usada para solicitar dados de um servidor. - Read
PATCH - é usado para modificar parcialmente um recurso. - Update
PUT - é usado para atualizar todo o recurso no servidor. - Update
DELETE - é usada para excluir o recurso especificado. - Delete
HEAD
TRACE
CONNECT
OPTIONS

GET, POST, PATCH, PUT e DELETE são os mais populares.

Parâmetros de Consulta

Os ingredientes mínimos que você precisa para fazer um pedido são:

um método de solicitação ( GET/ POST/ PUT/ PATCH/ DELETE, etc)
uma URL de solicitação

Os parâmetros de consulta são adicionados ao final do caminho. Eles começam com um ponto de interrogação ?, seguido pelos pares de chave-valor no formato: <key>=<value>. Por exemplo, esta solicitação abaixo pode buscar todas as fotos com orientação paisagem:

GET https://some-api.com/photos?orientation=landscape

Se houver vários parâmetros de consulta, cada um será separado por um e comercial &. Abaixo, dois parâmetros de consulta para especificar a orientação e o tamanho das fotos a serem retornadas:

GET https://some-api.com/photos?orientation=landscape&size=500x400

Às vezes, os parâmetros de consulta são opcionais e permitem adicionar filtros ou dados extras às suas respostas. Às vezes, eles são necessários para que o servidor processe sua solicitação.

Parâmetros de Caminho

Um parâmetro de caminho (ou "variável de caminho") é uma seção dinâmica de um caminho e geralmente é usado para IDs e nomes de entidade, como nomes de usuário.

Os parâmetros do caminho vêm imediatamente após uma barra no caminho. Por exemplo, a API do GitHub permite pesquisar usuários do GitHub fornecendo um nome de usuário no caminho {username}, conforme vemos abaixo:

GET https://api.github.com/users/bruno

* Estas são apenas convenções! Algumas APIs podem solicitar que você passe um ID ou nome de usuário em um parâmetro de consulta como este: /users?username=bruno

Autorização

Algumas APIs exigem autorização (também conhecida como Auth ) para determinado endpoint para permitir uma solicitação.

Existem vários métodos para autorizar uma solicitação. Alguns exemplos são Basic Auth (nome de usuário e senha), OAuth (autorização sem senha) e API Keys (strings secretas registradas para um desenvolvedor a partir de uma API).

As APIs que usam autenticação de chave de API (API Keys) geralmente permitem que os desenvolvedores se inscrevam em um portal de desenvolvedor, onde receberão uma chave de API aleatória que pode ser usada para autorizar suas solicitações para a API. A API Key permite que a API rastreie quem está fazendo chamadas e com que frequência.

Códigos de Status

Quando o servidor retorna uma resposta, um número de três dígitos também é enviado como parte da resposta. Esse número de três dígitos também é conhecido como "código de status".

Nome	Faixa de códigos de status
Informativo	100-199
Bem-sucedido	200-299
Redirecionamento	300-399
Erro do cliente	400-499
Erro de servidor	500-599

O Aprendizado Continua...

Aqui você pode buscar entender os fundamentos básicos de uma WEB API, mas é importante ir além e se aprofundar em cada um dos tópicos do artigo e, principalmente, praticar. Abaixo deixo alguns sites que disponibilizam APIs públicas que podem ser utilizadas em projetos práticos.

Em breve, pretendo publicar mais conteúdos onde aprofundarei em desenvolvimento de APIs. Até lá!

Giphy - https://developers.giphy.com/docs/api/
Any API - https://any-api.com/
Marvel - https://developer.marvel.com/
GitHub - https://docs.github.com/en/rest/reference/users#get-a-user