Explicação de como expandir a segurança da API do modelo de defesa em profundidade para o modelo de confiança zero

“A pandemia colocou imensa urgência nas empresas para que todos os tipos de projetos de transformação digital fossem executados o mais rápido possível, e esse é quase certamente um fator determinante por trás desse aumento nos ataques”, disse.

— Peter Klimek , Diretor de Tecnologia da Imperva .

As APIs DYKT são usadas há mais de 20 anos. Desde então, as APIs evoluíram drasticamente — de um conjunto limitado de empresas que usam APIs para atender a necessidades específicas para, recentemente, uma coleção infinita de casos de uso em ambientes DevOps de todos os tamanhos. As APIs podem ser encontradas em desenvolvimentos de aplicativos — desenvolvimento ágil, conectando clientes e parceiros com serviços e impulsionando iniciativas de transformação digital.

Mas em relação à segurança cibernética, de acordo com a pesquisa da ProgrammableWeb , uma média de 220 novas APIs foram adicionadas todos os meses desde 2019 . No entanto, com uma adoção mais ampla, as APIs expõem dados mais confidenciais hoje do que nunca, tornando-as um alvo valioso para ataques.

Este post é uma introdução sobre como mapear os requisitos de API Security, desde Defense-in-Depth até Zero Trust Model.

Histórico - O estado da segurança da API

Antes de entrar em como proteger a API, vamos examinar o cenário atual de ameaças da API Security. De acordo com o relatório State of API Security da Salt Security:

• Ataques de API aumentaram 681% nos últimos 12 meses
• 95% dos entrevistados tiveram um incidente de segurança de API no último ano
• 34% dos entrevistados não possuem nenhuma estratégia de segurança de API
• 62% dos entrevistados reconheceram a desaceleração do lançamento de um novo aplicativo devido a preocupações com a segurança da API

Resumindo, podemos dizer que a maioria das empresas não está preparada para um ataque baseado em API. Além disso, a confiança na segurança existente e nas ferramentas de gerenciamento de API, por exemplo, firewalls de aplicativos da Web (WAFs) e gateways de API, poderia ter evitado efetivamente incidentes de segurança e fornecido uma falsa sensação de segurança.

E quanto a Shift-Esquerda?

O relatório destaca que as táticas shift-left não estão ajudando, pelo menos na segurança da API. Mais de 50% dos entrevistados disseram que as equipes de desenvolvedores, DevOps ou DevSecOps são responsáveis pela segurança da API. As empresas que gastam mais em esforços de pré-implantação incluem:

• práticas recomendadas de codificação segura,
• escaneamento de código e
• teste manual

No entanto, 85% reconheceram que suas ferramentas de segurança são ineficazes na prevenção de ataques de API - provando que essas práticas de segurança DevOps, embora importantes, não são suficientes.

Então, qual proteção uma organização deve criar ou adotar para se defender contra ataques de API? Para responder a essa pergunta, primeiro precisamos entender os ataques comuns contra a API.

O atual cenário de ameaças

No relatório recente sobre segurança de API do Google Cloud , as fontes de ameaças de segurança de API são:

1. APIs mal configuradas (40%),
2. APIs, dados e componentes desatualizados (35%),
3. Spam, abuso, bots (34%).

De acordo com outro estudo do Imperva Research Labs , o ataque mais significativo é o Remote Code Execution (RCE) ou Remote File Inclusion (RFI), que saltou 271%. Os hackers usam ataques RCE ou RFI para roubar informações da empresa, comprometer servidores e desfigurar sites ou até mesmo assumir o controle dos sites.

Outras vulnerabilidades de API são, de acordo com o top 10 da OWASP API Security:

• API DDOS fan-out,
• ataques de API de dia zero,
• credenciais roubadas,
• violações de perímetro,
• movimentação lateral de brechas,
• vazamento de dados na saída, ou
• sequestro de recursos

Cibersegurança: a API é o novo endpoint

Conforme mencionado acima, a primeira razão para o aumento do risco de segurança das APIs é a explosão da adoção - muitas APIs em um ambiente. Por exemplo, um aplicativo Kubernetes tem centenas de pods e microsserviços. Cada um deles está gerenciando meia dúzia ou mais APIs. (Esse é um cenário típico em um ambiente DevOps).

Agora, acrescente que essas cargas de trabalho de microsserviços (e, portanto, as chamadas de API) são temporárias, executadas em nuvens, escritas em vários idiomas e usam protocolos diferentes. Ou, resumindo, as APIs criam um ambiente complexo e desafiador para a equipe de segurança supervisionar a operação da API.

Em segundo lugar, as APIs nunca foram feitas para serem expostas ao mundo exterior. No entanto, foi isso que enfrentamos com as vulnerabilidades encontradas nas pilhas de protocolos de rede. Esses desenvolvedores nunca imaginariam que suas obras seriam adotadas na escala atual. Como resultado, as APIs têm vulnerabilidades e riscos inatos incorporados a elas.

Em terceiro lugar, os ataques e violações têm se tornado cada vez mais sofisticados, especialmente aqueles executados na fase de pós-autenticação e autorização. Eles também são mais profundos na carga útil de dados da API.

Portanto, há uma necessidade de olhar para a segurança além da autenticação e autorização, também da aplicação e da camada de carga de dados da API. Uma maneira de fazer isso é pensar na API Security como análoga à nossa tradicional segurança de endpoint.

DiD (defesa em profundidade), de novo!

Problemas de segurança também acontecem em nossa vida diária fora dos computadores. Desde os primórdios da história da humanidade, vários países vêm explorando e praticando múltiplos mecanismos de defesa e fortificações. Essas experiências e ideias também se aplicam à segurança de terminais, redes e APIs.

Digamos que o Endpoint Software seja análogo ao castelo:

• A autenticação de identidade é igual à prova de identificação dos comandantes, e
• Honeypots (ou iscas em guerra) atraem atacantes para longe de alvos de alto perfil.
• Dentre essas estratégias de guerra, uma das formas mais eficazes é a Defesa em Profundidade (DiD).

A abordagem DiD pode ser dividida em duas áreas:

1. Defesa de limite (assinaturas antimalware)
2. Detecção/ Prevenção de Intrusão (IDS/ IPS/ EDR)

Explicarei a segurança da API com essas áreas DiD uma a uma.

1# Defesa de Limite

A defesa de limite é o tipo mais básico de defesa. Quase todas as empresas investem em defesas de fronteiras. Na segurança de endpoint, usamos assinaturas e listas de negação de IP para nos defender contra métodos de ataque conhecidos.

Como linha de frente de proteção, essa camada visa impedir 90% de todos os ataques, não direcionados e iniciados por indivíduos não qualificados que não possuem conhecimento técnico sólido ou mentalidade de hacker. Nesse cenário, a defesa de limite pode resistir bem a esses ataques indiscriminados.

Em API Security, o WAF está fazendo um excelente trabalho nessa área. Ele oferece recursos padrão para defesa de limite:

· Listas de permissão e negação de IP,

· Motor de regras WAF,

· Limitação de taxa, e

· injeção de falhas/fuzzing.

Quando combinado, pode bloquear quase todos os ataques de commodities.

2# Detecção de Intrusão (++)

A visibilidade da segurança é um elemento crítico da prevenção de ataques. Depois que um hacker violou o perímetro, precisamos de uma maneira adequada de identificar qual arquivo/processo/tráfego provavelmente está relacionado ao ataque mal-intencionado. No Endpoint Software, temos IDS/IPS baseado em host para inspecionar todas as solicitações que passam pelo portão frontal.

Alguns outros métodos de detecção, como detecção de APT e aprendizado de máquina, podem ser mais intuitivos para avaliar contra ataques direcionados.

Outras formas típicas de implementar a análise do comportamento são:

· Honeypots,

· EDR (Endpoint Detection and Response), e

· Inteligência de ameaças (arquivo e processo).

Entre todos esses métodos, os honeypots são um dos mais antigos (desde o início das guerras). Ao atrair alguns alvos de alto valor para armadilhas/chamarizes, eles podem analisar o comportamento do inimigo e até mesmo ajudar a localizá-los. Hoje em dia, adotamos essas táticas e as transformamos em técnicas de engano.

No mundo moderno, as soluções de segurança de API fornecem combinações das técnicas mencionadas; por exemplo, os artefatos coletados em honeypots podem ser enviados para o feed de inteligência de ameaças para WAF ou consumo de aplicativos da Web e proteção de API (WAAP). Nesta camada, temos técnicas semelhantes para aumentar a visibilidade e a velocidade para parar um ataque:

· Honeypots de rede

· NDR (detecção e resposta de rede) e

· Inteligência de ameaças (carga útil e rede).

Usar bots para executar ataques de "enchimento de credenciais" é outra tática de ataque comum. Ele tenta roubar ativos de alto valor. A estratégia é encontrar uma maneira de obter informações de login, como e-mails/senhas vazados, e depois tentar acessar as localizações da rede em lotes (movimento lateral). De longe, a defesa mais eficiente para combater o preenchimento de credenciais vem da fonte: identifique o bot de usuários reais para interceptar todas as solicitações feitas pelo bot.

Assim, algumas ferramentas AppSec também fornecem recursos anti-bots, um tipo específico de detecção de comportamento como parte da segurança da API.

Quando a segurança da API atende a zero confiança

Não estou dizendo que o DiD é inútil. Soluções de segurança de API e aplicativos, como proteção WAF para organizações contra ataques de commodities. No entanto, conforme mencionado, a API cria um ambiente complexo e a configuração incorreta piora o problema.

Com um perímetro não esclarecido, pode ser necessário mais do que uma abordagem DiD. O Zero Trust essencialmente coloca obstáculos em todos os lugares para os invasores, impossibilitando que eles se movam lateralmente dentro do ambiente.

A confiança zero é uma estrutura e estratégia de segurança abrangentes. Requer etapas de verificação rígidas e unificadas para todos os terminais, BYODs (Bring Your Own Devices), servidores, APIs, microsserviços, armazenamento de dados e serviços internos.

A ideia principal do Zero Trust é transformar o ponto de aplicação centralizado em vários micro pontos de verificação em todos os caminhos de seus aplicativos , incluindo APIs. Seja uma solicitação externa de acesso interno, um telefone celular ou um PC, uma chamada API ou solicitação HTTP, um funcionário comum ou um CEO, ninguém é confiável.

Para atingir efetivamente tal objetivo sem parar ou desacelerar seus aplicativos, a orquestração e a automação seriam as etapas determinantes críticas.

Por que a orquestração e a automação são cruciais para a segurança da API Zero Trust?

ZTA, NIST SP800–207 | imagem do autor

Para explicar a necessidade dos dois, vamos dar uma olhada mais de perto em um pilar da Zero Trust Architecture — confiança de acesso do usuário/dispositivo . Esse método de defesa é semelhante a mostrar seu passaporte no posto de controle do aeroporto e suas carteiras de identidade para comprar álcool.

Sem a identidade e autoridade correspondentes, é impossível entrar no sistema relacionado. É aqui que um API Gateway entra em ação, pois fornece alguns recursos importantes de autenticação:

• Rotação automática de chaves
• Integração com vários sistemas de autenticação, como OKTA e Auth 2.0
• Suporta criptografia TLS e mTLS de tráfego

Existem dois componentes principais da confiança do usuário e do dispositivo:

• Gerenciamento de identidade e acesso
• API Gateway com segurança integrada

Imagine adicionar equipamentos de identificação em todos os centros de transporte , como aeroportos e ferrovias de alta velocidade. Você também deve entender todas as rotas de e para todos os centros de transporte e implementar salvaguardas.

Em uma grande empresa, haverá centenas de sistemas, dezenas de milhares de APIs e microsserviços e centenas de milhares de clientes. A menos que tenhamos recursos e tempo ilimitados, a equipe de DevOps, Segurança ou Aplicativo não pode definir e adicionar manualmente centenas de milhares de verificações de microidentificação em aplicativos modernos.

Todos os outros pilares da Zero Trust Architecture, Application, Workload e Data também requerem a mesma lógica para adoção. A necessidade é de uma solução que:

1. Utiliza arquitetura moderna,
2. Trabalha em ambientes heterogêneos,
3. Mitiga esses riscos (não apenas as commodities) e
4. Faz tudo isso de maneira automatizada em ambientes multinuvem
5. (opcional) de código aberto, de forma a permitir agilidade tecnológica e criatividade.

Como é a segurança da API Idea Zero Trust?

Para adotar os ambientes complexos e heterogêneos na API, a solução Zero Trust API Security deve poder ser implantada em vários formatos e, assim, suportar diferentes configurações , por exemplo:

• Contêiner Docker,
• Um proxy reverso autônomo,
• Agente para web/servidor de aplicativos ou
• Incorporado no Kubernetes Ingress Controller.

Com o suporte da nuvem e da arquitetura moderna de aplicativos, a automação e a escalabilidade seriam atendidas.

Mas, para manter a orquestração, o “agente” (ou ponto de microaplicação) deve poder ser implantado sobre um aplicativo existente sem alterar a arquitetura existente , garantindo latência mínima e controle máximo.

Depois de considerar os fatores de forma de implantação e arquitetura, também é essencial que o nível de segurança não seja degradado. Para ser genuinamente adotado Zero Trust, o processamento de segurança deve ser feito localmente sem transmitir para outras nuvens ou engines, como um sandbox de nuvem para análise.

Se as partes externas não estiverem sob nosso controle, será difícil verificar a confiança no acesso aos dados/rede. Existem alguns outros benefícios de fazer isso localmente, como:

• Os dados confidenciais não saem do ambiente protegido.
• Você não precisa compartilhar certificados e chaves privadas com terceiros.
• Nenhuma dependência de tempo de atividade de terceiros para processamento de tráfego.

A última parte é considerar a orquestração. Idealmente, precisamos de uma solução que possa ser inserida no ambiente do aplicativo enquanto um orquestrador pode gerenciar esses agentes e cuidar das seguintes operações:

• registro/cancelamento de agentes
• atualização de política
• atualização de configuração
• atualização de software
• registro e
• Sincronização de dados.

Resumindo, o Zero Trusted API Security deve estar em várias formas para infundir em ambientes de aplicativos modernos. Enquanto isso, a melhor solução deve ser capaz de fornecer orquestração e todas as funções de segurança que as soluções tradicionais podem fornecer.

Então, como você sabe, a confiança zero não é perfeita. As soluções de confiança zero não podem se defender totalmente contra ataques de dia zero ou de engenharia social, embora possam reduzir significativamente a superfície e o impacto do ataque.

Palavras Finais

As APIs se tornaram o sistema nervoso central dos aplicativos modernos, trazendo informações e dados críticos de uma parte do aplicativo para outra ou de um aplicativo para outro. Como resultado, a segurança da API deve ser a prioridade ao proteger os aplicativos. Isso é particularmente verdadeiro para APIs públicas, com usuários em todo o mundo acessando componentes de software e dados confidenciais.

A adoção do Zero Trust Framework muda o foco de uma única proteção para diferentes pilares (Usuários, Dispositivos, Redes, Aplicativos e Dados). Isso pode ajudá-lo a garantir que cada parte do acesso à API, seja dentro ou fora do perímetro, esteja sob a abordagem de privilégios mínimos e monitorada continuamente.

Obrigado por ler. Que a InfoSec esteja com você🖖.