SecDevOps, OWASP ou ISO-24772?

É fato que o pessoal gosta e usa muito OWASP Top10, que precisaremos consertar e priorizar muita vulnerabilidade e vício fundamental herdado do passado (SQLi existe há 25 anos), mas que tal expandir os horizontes e possibilidades além do universo OWASP?

A ISO-24772 (e suas 11 subpartes) pode ser sua aliada nessa empreitada, atualmente com diversas partes publicadas, outras em WD (Working Draft) e parte delas ainda com o nome diferente no comitê original responsável, oferecem possibilidades ótimas e os comitês estão cada vez mais engajados na cobertura desse assunto e expansão das linguagens.

A ISO/IEC 24772 - Information technology — Programming languages — Guidance to avoiding vulnerabilities in programming languages through language selection and use ISO/IEC 27000, tem previsão de disponibilizar novas partes (além das 11 atuais), colaborando com a missão de tornar seu desenvolvimento seguro desde a escolha da linguagem, na origem de todo produto orientado a software. Atualmente, as partes e linguagens oferecidas oferecem uma boa cobertura e suportam:

• Part 1: Language-independent guidance (atualizada há menos de 15 dias)

• Part 2: Ada

• Part 3: C,

• Part 4: Python

• Part 5: PHP

• Part 6: Spark

• Part 7: Ruby

• Part 8: Fortran

• Part 9: Cobol (removed)

• Part 10: C++

• Part 11: Java

São ótimas referências para expandir os atuais programas orientados aos devios mais comuns (tipo OWASP TOP10, Critical Controls) que, embora seja um excelente início, nem sempre aprofundam as validações em níveis mais profundos, como classes, métodos, funções, recursos inseguros, problemas conhecidos e recorrentes no contexto de cada uma das linguagens existentes (esperados por exemplos, para conseguir e certificar em níveis mais altos de EAL - Evaluation Assurance Level).

Mas ela pode ajudar em algo mais? Se você é pesquisador, profissional da área ofensiva, revisor de código, security champion, piloto de ferramenta, eis um material que você deveria conhecer em profundidade. Mas, o que mais poderiamos fazer para minimizar código ruim, inseguro e vulnerabilidades críticas?

Gerar vulnerabilidade de forma inconsciente é característica intrínseca do ser humano, seja por descuido, por velocidade, desconhecimento ou outros fatores e isso independe da qualidade do programador/desenvolvedor, uma vez que nem todas as variáveis estão ao seu alcance.

E o que pode ser feito, independentemente da linguagem para reduzir os problemas associados a codificação?

• Escolha da Linguagem de Programação
  Entender a importância da linguagem é primordial, assim como todos os recursos e componentes que esta lhe oferece. Linguagens mais modernas tendem a ter mecanismos mais modernos de identificação, menor quantidade de vulnerabilidades inerentes (e.g., Rust e Go, que eliminaram falhas conceituais mais conhecidas) versus linguagens com maior granularidade e controle manual (como C, C++ e Java).

  No geral, não há muita opção e ou você conhece e acredita nos recursos/componentes de Segurança da linguagem ou constrói os seus próprios. Lembra do Bernstein e Venema? Pois é, eles não acreditavam e construíam seus próprios pacotes/ferramentas.

• Modelagem de Ameaças e Identificação de Requisitos de Segurança
  Saber como simular e identificar possíveis ameaças de acordo com o contexto do seu desenvolvimento, produto e linha de negócio é diferencial. Em paralelo, saber escolher os requisitos de segurança durante o design do programa e a fase de arquitetura faz diferencial tremenda. Existem diversos frameworks que podem ajudar com esse tema, então, adote um e depois adapte a sua necessidade (mas tenha algum modelo definido).

  Se gosta de abordagens ágeis, recomendamos conhecer o MVSP, criada pelo Google como membro fundador,e agora em consórcio com parceiros tecnológicos de vanguarda como a Salesforce, NetFlix, CISA, Okta, Slack, Vanta, BitSight, SecureScoreCard, SafeBase, TerraTrue e SecureFrame. No consórcio, a OmniSec tem o prazer de colaborar com o como a primeira empresa da América Latina aceita no consórcio - veja artigo sobre aqui. Não gostou? Avalie OWASP SAMM, PCI-SSF e SSA SSF.

• Repositórios de Códigos

  A maioria das plataformas de codificação colaborativa oferecem recursos para avaliação de segurança (build-in ou módulos separados consumidos sob demanda), com checagens mais simples e outros bem elaboradas. Escolha alguns controles reduzidos no início (tanto no repositório quanto nas ferramentas que alimentam e publicam no repositório) e, de acordo com o tempo e maturidade, incremente seus controles, gatilhos, testes e bloqueios.

  Inicie com ferramentas mais simples/FOSS, avalie a capacidade do seu capital humano em se relacionar com as novas regras, com a proposta e os controles, depois, avalie qual processo de SDLC pretende atender e, novamente, quando estiver num grau mais maduro de consumo, aprendizado e resultados, parta para ferramentas mais robustas. Se estive na dúvida de quando esse gatilho é desejado, leia nosso artigo sobre Quadrante Gartner.

• Gerenciamento de Memória e Recursos

  Conhecer as particularidade do gestor de memória, seu gerenciamento de exceções ajuda a evitar corrompimentos, vulnerabilidades de overflow e outras. Em linguagens com gestão protegida e aprimorada de memória, compreender como ela funciona, quais suas limitações e restrições, especialmente em relação à coleta, o processo de destruição e liberação de memória (Garbage Collector) são bem úteis.

  Avalie quais recursos tanto a linguagem, quanto o hardware e o sistema operacional podem lhe oferecer no quesito proteção, em cada uma das camadas e pontos de comunicação/troca.

• Critica de Dados

  Realizar validação rigorosa das entradas dos usuários para evitar injeção de código, abuso de "type casting" de variáveis e outros ataques de entrada (ou manipulações de saída) deve ser pratica recorrente, anexo a tratativas de sanitização em todos os "gatekeepers" dos seus componentes, seja entrada, processamento, armazenamento temporário ou saída.

  Utilizar ferramentas automatizadas que possam testar, estressar, simular padrões esperados, erros e exceções contra todos os componentes de entrada é boa-pratica fundamental em modelos de validações, testes de qualidade e segurança.

• Gerenciamento de Dependências e Bibliotecas Externas

  Entender como gerenciar licenciamento, ciclo de vida dos componentes, relacionamento entre as partes e suas dependências, especialmente em relação a versões e atualizações de segurança, faz diferença imensa na qualidade e segurança do produto final.

  Atualmente, ainda é bem comum encontrar plataformas relevantes e importantes utilizando componentes desatualizados ou até mesmo descontinuados. Use desde os primeiros trechos de códigos, ferramentas de análise de vulnerabilidades de bibliotecas e checagem de dependências, preferencialmente que ofereçam um bom inventariado SBOM - Software Bill of Materials.

• Triple AAA - Autorização por Perfis, Autenticação Segura e Accounting

  Conhecer métodos de autorização, autenticação e rastreabilidade robustos, associados a controle de acesso/perfis e autenticação multifator (MFA), aumenta em muito a segurança em um dos principais vetores de acesso e exploração não autorizada a sistemas.

  Escolha métodos e modelos modernos, seguros, que sejam padrões de mercado e preferencialmente abertos/open. Tenha o "least privilege" e o "need to know" e algum modelo permissionamento (MAC, DAC, RBAC...) como mantra e esteja com seu logging em dia, a prova de possíveis necessidades (evitando que informações sensíveis, payloads, tokens e chaves sejam armazenados - veja nosso artigo sobre Logging).

• Segurança de Comunicações e Criptografia

  Implemente criptografia adequada para proteger dados em trânsito, em uso quando aplicável e em repouso (Data in Transit, in Use, at Rest), além de escolher algoritmos, cifras e bibliotecas seguras.

  Configure corretamente o uso dos protocolos seguros em todos os estados, entenda o impacto de performance desses protocolos por uso de criptografia, se preocupe com a guarda e gestão do seus segredos/certificados e corra de implementações obsoletas e fracas.

• Segurança no Ciclo de Vida de Desenvolvimento - SDLC

  Adote e adapte práticas de desenvolvimento seguro. Não importa qual, mas escolha um, teste seu uso, adapte a sua necessidade e padronize/replique seu uso entre os times. É necessário iniciar com um padrão mínimo para que exista compreensão do modelo, do como ele pode ajudar (ou atrapalhar) no seu dia a dia.

  Adote gatilhos, thresholds de qualidade e cresça gradualmente a revisão de código e testes de segurança (sejam estes estáticos, dinâmicos, interativos ou em tempo de execução). Persiga dia a dia o conceito de "Shift Left" para identificar e corrigir falhas de segurança o mais cedo possível no ciclo de desenvolvimento.

Como exerício ilustrativo, a imagem acima é do "Report of Defense Science Board Task Force on Computer Security - Security Controls For Computer Systems", de 1967. De forma geral, o artigo não pretende ser exaustivo mas ajuda com algumas das principais recomendações "de-facto" do mercado sobre o assunto.

Em conjunto com seu framework/modelo escolhido, oferece uma boa recomendação primordial para quem ainda não tem um modelo adotado e adaptado para uso. Boa codificação!