Filosofia de segurança shift-left promove a ideia de que as organizações devem antecipar a maioria dos processos de segurança para as fases de design e desenvolvimento do ciclo de vida de desenvolvimento de software. Esse ideal é fortemente promovido em programas de DevOps e DevSecOps como uma forma de detectar problemas de qualidade ou segurança precocemente e corrigi-los antes que cheguem à produção, onde os impactos se tornam mais dispendiosos. Com razão, muitas organizações adotaram totalmente o shift-left para tentar obter esses benefícios e economias de custos.
Um foco específico dentro do shift-left é a "segurança do pipeline de compilação", que exige que as equipes integrem ferramentas de segurança aos pipelines de CI/CD e aos fluxos de trabalho de desenvolvedores baseados em git. Proteger pipelines de compilação requer uma gama de ferramentas de segurança, incluindo análise de dependências, análise estática, análise dinâmica, validadores de esquema, fuzzers e scanners de vulnerabilidade. O tipo de ferramenta de segurança necessária varia de acordo com os artefatos que passam pelo pipeline, o que deve ser compilado e onde deve ser entregue.
As organizações frequentemente enfrentam dificuldades com dois aspectos da segurança do pipeline de compilação:
- A cobertura "total" exige a obtenção de vários tipos de ferramentas de teste de segurança — Algumas organizações tentam reduzir custos optando por ferramentas de código aberto gratuitas, parcial ou totalmente. As decisões variam de acordo com a conscientização, os orçamentos de segurança e a tolerância ao risco.
- As ferramentas devem ser integradas e automatizadas para atender ao pipeline — Não basta escanear, encontrar problemas e gerar um relatório. O resultado final da varredura de segurança deve ser compreensível e adaptar-se aos processos de CI/CD.
Mesmo que você consiga satisfazer esses requisitos, vários outros problemas surgem para as organizações com a visão míope de que proteger o pipeline de compilação é o objetivo final de uma estratégia de segurança de API.
A varredura de vulnerabilidades é uma commodity de baixo valor
Ferramentas de avaliação e gerenciamento de vulnerabilidades (VA/VM) dominam o cenário em muitas organizações de segurança. Esse tipo de varredura de rede e infraestrutura é extremamente comum nas organizações, pois tem sido promovido como uma prática recomendada de TI e segurança há décadas. Alguns fornecedores de VA/VM afirmam que também cobrem aplicações, mas isso geralmente se limita a identificar vulnerabilidades em pacotes de software comerciais ou de código aberto. Essas ferramentas também podem ser úteis para identificar alguns tipos de configurações incorretas de servidores ou cargas de trabalho. No entanto, elas pouco fazem para avaliar a segurança de suas aplicações e APIs personalizadas. É comum ver o VA/VM como a abordagem padrão em programas de segurança, em vez de uma abordagem formalizada de segurança de aplicações com ferramentas criadas para esse fim, como as ferramentas de teste de segurança de aplicações (AST).
Se o VA/VM é a ferramenta que permite escanear a infraestrutura de produção em busca de vulnerabilidades conhecidas, o SCA é a ferramenta que permite escanear componentes para identificar dependências externas vulneráveis no código-fonte da aplicação ou na infraestrutura como código. As varreduras de SCA podem ser acionadas como parte de commits de código, executadas como parte de compilações, iniciadas como parte da entrega (por exemplo, instanciando uma carga de trabalho conteinerizada) ou executadas continuamente em produção para detectar desvios. O SCA também se tornou uma commodity, podendo ser encontrado como recursos integrados em suítes AST, incluído em ofertas baseadas em git, como GitHub e GitLab, e incorporado na infinidade de ofertas de proteção de carga de trabalho. Também existem muitas alternativas de código aberto para SCA. Mesmo que o SCA funcione apenas como um verificador básico de dependências, isso pode fornecer uma segurança "suficientemente boa" para muitas organizações.
Escanear imagens de contêineres ou registros de contêineres em busca de vulnerabilidades publicadas e bem conhecidas é trivial em comparação com a análise em tempo de execução e a detecção de anomalias. Até mesmo as ofertas de proteção de carga de trabalho devem fornecer varredura contínua em tempo de execução para serem benéficas. A varredura em busca de dependências vulneráveis não é apenas um ponto no tempo ou uma varredura de pipeline. O desvio de ambiente é comum nas "operações do dia a dia" e quanto mais tempo uma aplicação ou sua infraestrutura de suporte existir. Se você se aprofundar no problema das dependências aninhadas ou transitivas, verificar se o código vulnerável é realmente explorável o levará a um mundo complexo de análise estática estendida, análise dinâmica, fuzzing, análise em tempo de execução e análise comportamental.
Há mais nos problemas de segurança do que apenas CVEs
Vulnerabilidades e exposições comuns (CVE) IDs cobrem vulnerabilidades conhecidas em pacotes de software e hardware publicados. Esses tipos de problemas de segurança são mais facilmente identificados por ferramentas de varredura. As técnicas comuns incluem escanear faixas de endereços IP de rede em busca de serviços ativos, consultar informações de banner de servidor, identificar o software em execução nos hosts e avaliar cabeçalhos nas respostas do servidor.
Enumeração de fraquezas comuns (CWE) IDs são categorias mais amplas de fraquezas em software, sendo o sistema de classificação mais apropriado para problemas em aplicações e APIs desenvolvidas internamente. Eles são menos conhecidos, mas também definidos de forma mais ampla, o que significa que um determinado problema em sua aplicação personalizada pode ser mapeado para vários IDs CWE. Infelizmente, isso complica a pontuação de risco e o rastreamento de correções, mas é a realidade do desenvolvimento personalizado. Mesmo as organizações que compram mais software do que desenvolvem acabam criando código personalizado para integrar sistemas e trocar dados. CWE é a taxonomia mais relevante para os tipos de problemas de segurança que você pode estar criando inadvertidamente ao compilar ou integrar código. Se você está olhando apenas para CVEs, está perdendo a visão geral.
Dependências vulneráveis conhecidas que você referencia no código ou na infraestrutura como código tornam-se parte de suas cargas de trabalho em execução. Como resultado, a maioria das organizações acaba com uma mistura de CWEs, CVEs e muito mais. Embora essas sejam taxonomias bem definidas do MITRE e do NIST, elas não cobrem tudo. Também há uma latência inerente na comunicação e divulgação de vulnerabilidades. Não existe necessariamente uma "correção" para a latência de relatórios de CVE. É um subproduto do processo de autorrelato, do tempo médio para detectar problemas, de acordos coordenados de divulgação de vulnerabilidades e da logística de coordenação das partes responsáveis.
Os segredos obscuros do AST
Existe um problema óbvio que ninguém quer comentar quando se trata das limitações das ferramentas de AST:
Ferramentas de análise estática e dinâmica não conseguem detectar falhas de lógica de negócio.
Isso simplesmente não é possível devido à própria concepção dessas ferramentas. A lógica de negócio é exclusiva da sua organização e da forma como você projeta e programa suas APIs. Como resultado, o código que representa sua lógica de negócio raramente segue padrões bem definidos nos quais assinaturas ou regras possam ser criadas. Essa limitação é semelhante às armadilhas dos mecanismos de proteção contra ameaças em gateways de API e WAFs.
O AST, que pode instrumentar e analisar aplicações ou APIs em nível de código durante a execução (como o IAST), pode ser capaz de descobrir subconjuntos de vulnerabilidades de escalonamento de privilégios. Testes de segurança baseados em instrumentação podem oferecer uma cobertura limitada para quebra de autorização em nível de objeto e quebra de autenticação . No entanto, a maioria das ofertas dos fornecedores não testa a autenticação ou autorização profundamente, limitando-se a verificações superficiais, como a detecção de formas fracas de autenticação, como acesso básico ou digest. Ou a ferramenta de AST pode analisar como as credenciais são inseridas, transmitidas ou armazenadas, o que, novamente, é apenas uma pequena parte do quebra-cabeça. Tecnicamente, testar vulnerabilidades de escalonamento de privilégios exige múltiplas execuções de uma ferramenta de DAST contra uma determinada aplicação e sua API. Infelizmente, o tempo é um recurso escasso em muitas organizações que adotam DevOps e buscam janelas de lançamento cada vez mais curtas. As ferramentas de DAST são conhecidas por levarem muito tempo para serem executadas, sendo piores que o SAST e ligeiramente melhores que o fuzzing.
As ferramentas de DAST também não foram criadas para testes de API web. Elas geralmente exigem um front-end para iniciar as solicitações da aplicação, como JavaScript sendo executado em um navegador ou um binário móvel rodando em um dispositivo. As ferramentas de DAST detectam problemas interceptando, analisando e manipulando o tráfego. Parte desse tráfego pode ser de APIs, mas as ferramentas de DAST não possuem o contexto de como essas APIs funcionam. Escanear APIs REST de forma eficaz exige muito cuidado e manutenção com o DAST, de forma semelhante ao treinamento de um WAF. A configuração do scanner pode ser parcialmente informada pela documentação da API ou definida manualmente, mas é necessária para que a ferramenta de DAST consiga analisar um endpoint de API de forma minimamente inteligente. Mesmo assim, um DAST pode tentar detectar vulnerabilidades ou fraquezas que não são relevantes no mundo das APIs, como painéis de controle de administrador ocultos ou ataques de força bruta em diretórios de URL. Cabe ao profissional ajustar ainda mais a configuração do scan do DAST e suprimir essas regras. No entanto, esse ajuste exige conhecimento especializado do sistema e de todas as suas APIs.
Em resumo, as organizações precisam recorrer à análise em tempo de execução e ao estabelecimento de linhas de base do comportamento das APIs para identificar o amplo espectro de ataques a APIs e abusos de lógica de negócio. A análise estática e a dinâmica sempre tiveram suas limitações. O problema é agravado no mundo das APIs.
As limitações dos validadores de esquema
Como uma forma de análise estática, os validadores de esquema de API são frequentemente apresentados como a solução amigável ao DevOps para a segurança no pipeline de build. O argumento de venda geralmente é: "Forneça suas definições de esquema, nós escaneamos suas APIs, garantimos que estejam em conformidade e verificamos se há vulnerabilidades."
Existem vários problemas com a abordagem de validação de esquema:
- Nem tudo precisa ser definido no esquema da API: Formatos de especificação de API como OpenAPI (OAS) e Swagger não exigem que você defina todos os campos ou funções na documentação da API. É comum que os desenvolvedores esqueçam de documentar algo completamente, especialmente se não estiverem trabalhando com ferramentas de design de API como o Postman.
- Muitas organizações são negligentes com a documentação: Os seres humanos são notoriamente ruins em documentar, especialmente em documentar tudo detalhadamente. A falta de documentação não é um problema específico dos desenvolvedores. O OAS pode ajudar por ser autodocumentável, mas ainda exige esforço manual. Algumas ferramentas também podem ser melhores que outras na geração da definição OAS.
- Desvio de API (API drift): Desvios entre a especificação original e o que está em produção são comuns. Divergência de API reflete um dos maiores problemas que as organizações enfrentam com processos de revisão de design seguro e modelagem de ameaças. Às vezes, o que você pretende construir acaba sendo muito diferente do produto final.
A validação e aplicação de esquemas é o antigo paradigma da segurança positiva com uma nova roupagem. Em vez de as equipes de segurança terem que criar regras ou assinaturas, o ônus é transferido para as equipes de desenvolvimento. A mistura de CWEs e CVEs inevitavelmente voltará a aparecer. Assim como seus equivalentes em AST, os validadores de esquema ainda não conseguem detectar falhas de lógica de negócios e também podem deixar passar exposições de dados confidenciais.
A ilusão de espelhos de produção
Ambientes de não produção que espelham a produção são necessários para executar certos tipos de AST de forma eficaz, incluindo DAST e IAST. Infelizmente, esses ambientes de teste costumam ser um luxo para muitas organizações. É provável que existam discrepâncias entre a produção e a não produção se todos os elementos não estiverem totalmente conteinerizados e prontos para implantação. Plataformas de contêineres e service meshes podem facilitar a criação de ambientes conforme a necessidade, mas essas tecnologias exigem uma curva de aprendizado enorme. Organizações que não estão tão avançadas em sua maturidade de DevOps têm dificuldade em implantá-las e operacionalizá-las. Também existem restrições de custo ou licenciamento para manter um ambiente de não produção totalmente funcional que espelhe a produção. A nuvem pode parecer uma resposta, já que é fácil criar instâncias efêmeras em provedores de serviços em nuvem, mas as despesas com computação em nuvem aumentam rapidamente.
Na ausência de ambientes de não produção funcionais, algumas organizações optam por executar ferramentas DAST ou IAST em produção. Embora os fornecedores afirmem que uma determinada ferramenta é razoavelmente segura para produção, muitas organizações sacrificam a profundidade ou a precisão da verificação ao desativar certos tipos de testes e limitar varreduras recursivas que poderiam resultar em uma interrupção do serviço. Esse tipo de concessão reduz ainda mais a eficácia limitada das ferramentas de AST quando se trata de APIs.
A automação bem-sucedida de testes de segurança não pode existir sem a automação de testes não relacionados à segurança
Automatizar seus testes de segurança em cadeias de ferramentas de desenvolvimento, sistemas de controle de versão e pipelines de build exige disciplina em muitas práticas que não são de segurança. Uma boa cobertura de código e de testes não pode ser alcançada sem um gerenciamento adequado de dados de teste, ambientes de teste semelhantes à produção, testes unitários definidos, scripts de automação de testes funcionais (por exemplo, Appium, Selenium) e muito mais.
Os dados, ferramentas e processos necessários para o sucesso na automação de testes são de responsabilidade compartilhada entre as equipes de identidade, I&O, QA e desenvolvimento. Para algumas organizações, o QA pode nem existir. Em muitos casos, essa função foi significativamente reduzida ou eliminada por completo. E, supondo que todos esses fundamentos de automação de testes estejam em vigor, é ainda mais raro que as equipes de segurança colaborem com as equipes de aplicação para fazer uso de tudo isso.
A colaboração entre segurança e outras áreas é inexistente em algumas organizações, e a maturidade de DevOps pode ser menor. Equipes de TI isoladas e o isolacionismo podem persistir, a menos que a organização tenha adotado uma iniciativa mais ampla de transformação digital. Essas abordagens de vários anos vão além da simples busca por ferramentas de pipeline para resolver um problema. A transformação digital envolve reformular radicalmente como a organização funciona, que tipo de cultura ela incentiva, como recruta talentos e muito mais. Metodologias ágeis e práticas de DevOps geralmente estão entrelaçadas com a transformação, mas existem muitos pilares que levam anos para serem dominados. Muitas equipes de segurança continuam a operar de forma independente das equipes de desenvolvimento para manter o foco em outros riscos de segurança que afetam suas organizações. O atrito entre as equipes de desenvolvimento, operações e segurança também é mais comum do que gostaríamos de pensar.
Lidando com a mentalidade de linha de montagem
Nós, como profissionais de qualquer função de TI, não trabalhamos em fábricas. Em alguns círculos, essas abordagens de pipeline e programas de DevOps são às vezes chamados de fábricas de software. O conceito de fábrica de software promove a mentalidade de linha de montagem, exceto pelo fato de que não somos máquinas ou operários produzindo coisas. Muitos também argumentariam que operários de fábrica nem sempre são trabalhadores felizes. Se um trabalhador está infeliz, isso impacta diretamente a qualidade (e a segurança). Qualquer forma de código deve ser vista como imperfeita, já que somos humanos criando-o. Ainda não atingimos o ponto de virada em que as máquinas geram o código por conta própria. O código também evolui com o tempo, com muitas mãos tocando uma base de código ao longo de sua vida útil. O código também passa por muitos conjuntos de scanners ao longo do tempo e ainda pode ser de baixa qualidade, explorável ou passível de abuso. Inúmeras organizações que servem como modelo de DevOps com pipelines de build seguros ainda sofreram ataques de API resultando em perda de dados, impactos na privacidade, problemas de segurança, danos à marca e muito mais.
A Toyota é frequentemente citada como uma história de sucesso ágil, sendo pioneira na manufatura enxuta e no pensamento ágil. A Toyota também capacitou os trabalhadores da linha de montagem a interromper a produção puxando um cordão andon se observassem um problema. Os veículos da Toyota foram assolados por problemas de aceleração não intencional durante anos na década de 2000. Especialistas revisaram posteriormente o código-fonte da Toyota para os inúmeros sistemas embarcados e testemunharam que os problemas de aceleração não intencional foram provavelmente causados por código espaguete, não por tapetes intrusivos ou pedais de acelerador presos, como alegado originalmente. Mesmo que você descarte esse evento como resultado de corrupção ou de objetivos de negócios que se sobrepõem à segurança pública, esses ainda são fatores que resultaram na violação de protocolos de segurança estabelecidos e padrões de desenvolvimento.
Problemas encontrados durante os testes de segurança devem ser registrados como bugs ou defeitos, inevitavelmente indo para um backlog, ou você deve interromper o pipeline e reprovar o build. Reprovar builds excessivamente atrasa os ciclos de lançamento. Outros aspectos do lançamento em produção também se desenrolam. Sabemos se os problemas são realmente exploráveis ou passíveis de abuso? Qual severidade e prioridade devem ser atribuídas a um problema detectado? Até onde no backlog de defeitos o problema detectado deve ir? Você interrompe um lançamento em produção por problemas de severidade potencialmente baixa que podem ou não ser exploráveis?
Provavelmente existe mais de um pipeline
A maioria das organizações possui uma mistura de pilhas tecnológicas que envolvem diferentes linguagens de programação e processos de desenvolvimento. É provável que haja uma combinação de arquiteturas monolíticas e de microsserviços, pilhas tecnológicas legadas e modernas, e metodologias em cascata (waterfall) e ágeis. Essa mistura leva inevitavelmente a múltiplos pipelines de compilação para as organizações, bem como a uma visibilidade ou controle reduzidos sobre esses pipelines. Alguns fatores contribuintes incluem:
- Parte do código e o(s) pipeline(s) pelo(s) qual(is) ele passa podem estar fora do seu controle.
- Um pipeline de compilação formalizado pode ser inexistente se a parte responsável não estiver adotando CI/CD.
- Muitas organizações terceirizam ou transferem o desenvolvimento para o exterior, total ou parcialmente.
- Os esforços de desenvolvimento são frequentemente fragmentados, com equipes separadas de front-end e back-end, ou equipes dedicadas a certos subconjuntos de funcionalidades.
- Plataformas de baixo código (low-code) podem não fornecer fluxos de trabalho e serviços de compilação formalizados, ou os artefatos de código podem ser uma incógnita.
As realidades do desenvolvimento de aplicações corporativas, integração e engenharia de sistemas resultam inevitavelmente em múltiplos pipelines de compilação. Quanto mais pipelines existirem, mais difícil se torna para a segurança obter visibilidade, conectar ferramentas ou exercer controle. Unificar todas as compilações em um único pipeline é irrealista para a maioria das organizações, uma vez que frequentemente existem necessidades de negócio legítimas para diferentes pilhas tecnológicas.
Pense nos pipelines sob uma nova perspectiva
As melhores práticas e ferramentas para proteger o próprio pipeline de compilação ainda estão em estágio inicial. As organizações às vezes negligenciam a segurança dos serviços de CI/CD, ou as ferramentas não são projetadas adequadamente para garantir a integridade de tudo o que passa por um pipeline. Os vários serviços de VCS, CI e CD também são aplicações em si, frequentemente construídas sobre APIs. Eles também podem ser atacados de várias maneiras, o que coloca em risco tudo o que passa pelo seu pipeline. Equipes que operam dentro do pipeline podem suprimir verificações ou resultados para liberar código. Riscos inerentes à cadeia de suprimentos pioram à medida que você obtém código ou dependências de terceiros. Parceiros ou fornecedores também podem fornecer código personalizado que não faz parte do seu pipeline, mas que acaba entrando no código compilado ou no sistema completo da organização. Todos esses fatores impactam potencialmente a qualidade e a segurança de tudo o que se move através de seus pipelines.
É importante lembrar que a varredura de pipelines inclui verificações para todas as formas de código, mas também controles que podem ser auditados programaticamente. As práticas de DevOps vão além do código-fonte da aplicação, incluindo também infraestrutura como código (IaC) e política como código (PaC). Assim como a funcionalidade é habilitada por mais do que apenas o código da aplicação, o mesmo vale para a segurança, e muitos controles de segurança existem fora do código. Itens que você valida nos pipelines podem simplesmente envolver a confirmação de que um determinado controle de segurança em tempo de execução está habilitado e configurado adequadamente em IaC ou PaC.
Conclusão
Estabelecer e obter a adoção de abordagens de pipeline de compilação seguro é um esforço de vários anos para as organizações. E nenhum esforço de pipeline seguro pode ter sucesso sem atingir um certo nível de maturidade em DevOps. Dizem que DevOps é uma jornada por um motivo. Leva anos para amadurecer seus processos e cadeias de ferramentas. Mais importante ainda, leva tempo para obter a adoção de todas as personas de TI dentro e fora da organização. No entanto, os atacantes não se importam com sua jornada de DevOps e, nesse meio tempo, estão contornando controles de acesso, explorando fraquezas e abusando da lógica de negócio.
As abordagens de "shift-left" e de pipeline de compilação seguro têm seus méritos. No entanto, as organizações devem aceitar o risco de que existem muitos tipos de problemas de segurança que simplesmente não podem ser detectados como parte de varreduras automatizadas de design, desenvolvimento e tempo de compilação. Organizações maduras em suas estratégias de segurança de API e programas de DevSecOps admitem que, na melhor das hipóteses, estão detectando apenas uma parte dos problemas de segurança com uma determinada ferramenta de varredura. Os problemas detectáveis limitam-se a vulnerabilidades e fraquezas que seguem padrões bem definidos. Muitos problemas de segurança só se manifestam em tempo de execução, como parte do sistema completo e dentro da arquitetura corporativa.
A análise de comportamento em tempo de execução é um caminho a seguir para as organizações e uma forma de se protegerem contra o amplo espectro de problemas e ataques de API. Qualquer oferta deve fornecer detecção e prevenção precoces, parando os atacantes antes que eles consigam explorar ou abusar de suas APIs. A Plataforma de Proteção de API da Salt Security foi construída para evitar as muitas armadilhas das abordagens tradicionais de varredura e mitigações em tempo de execução. A Plataforma de Proteção de API da Salt é:
- Ciclo de vida completo, fornecendo capacidades para as fases de design, compilação e tempo de execução para fortalecer e proteger suas APIs contra o amplo espectro de padrões de ataque a APIs.
- Integrada, trabalhando com seus investimentos tecnológicos existentes e minimizando o impacto nos fluxos de trabalho de todas as personas que interagem com APIs
- Informada por ML, trazendo inteligência especializada em múltiplos domínios de segurança críticos para a segurança de APIs e que, de outra forma, seriam difíceis de contratar
- Automatizado, aprendendo a sua lógica de negócios exclusiva e os padrões de design de API para oferecer insights de segurança personalizados automaticamente
Para saber mais sobre como a Salt pode ajudar a proteger sua organização contra riscos de API, você pode falar com um representante ou agendar uma demonstração personalizada.