Codificação Segura - Desafios na Segurança da Informação

• Vulnerabilidades de segurança em código
• Código-fonte aberto e ataques à cadeia de abastecimento
• Controlo de segurança da informação 8.28 codificação segura
• Princípios de codificação segura
• Conclusão
• Revisão da ISO 27001: O que a atualização significa para a sua certificação?
• DQS - Simplesmente alavancando a Segurança.

Vulnerabilidades de segurança em código

Software de sistema operacional, software aplicativo ou firmware em um sistema embarcado são componentes elementares de qualquer infraestrutura digital. No entanto, a aceleração crescente e a pressão de prazo em projetos de digitalização geralmente levam à negligência de aspectos imperativos de segurança da informação. Os requisitos de desenvolvimento de software geralmente são centrados na função e enfatizam aspectos construtivos, de modo que a visão destrutiva de possíveis vulnerabilidades de segurança é diametralmente oposta aos objetivos de desenvolvimento reais: muitos programadores simplesmente também carecem de uma visão estruturada e aguçada da segurança cibernética.

Sob essas condições, as equipes de desenvolvimento têm dificuldade em revisar continuamente e proteger consistentemente a codificação de seu software, como evidenciado pelas muitas vulnerabilidades que a MITRE Corporation sem fins lucrativos publica todos os anos em seu CVE (Vulnerabilidades e exposições comuns). Os patches de segurança regulares de fabricantes de software conhecidos são um indicador da tarefa de Sísifo de fechar bugs relevantes para a segurança, quanto mais identificá-los antes mesmo de serem lançados no mercado.

Código fonte aberto - um caso especial

Ao codificar software autodesenvolvido, os programadores gostam de recorrer a bibliotecas e módulos de código aberto. As vantagens práticas são óbvias: se você não precisa reinventar a roda repetidamente, você se beneficia desse impulso tecnológico, desenvolvimento rápido, custos de desenvolvimento mais baixos, mais transparência por meio de código-fonte aberto e maior interoperabilidade por meio de padrões e interfaces abertos. 

Também costuma-se dizer que o código de código aberto oferece um alto grau de segurança porque o código foi validado por muitos usuários e a inteligência de enxame da comunidade de código aberto permite a correção rápida e eficiente de bugs. 

Na prática, essa confiança agora deve ser avaliada de forma diferenciada e crítica. O exemplo mais sério é a vulnerabilidade de segurança de dia zero Log4Shell na biblioteca de log amplamente usada Log4J para aplicativos Java, que foi descoberta em novembro de 2021. Você deve ter ouvido falar sobre o nível de alerta vermelho emitido pelo Escritório Federal Alemão de Segurança da Informação (BSI ) para Log4Shell. A biblioteca Log4J, distribuída como um quase-padrão de funcionamento confiável por meio da Apache Foundation, estabeleceu-se em muitos sistemas desde 2013 - incluindo serviços da Web conhecidos, como Amazon AWS.

A complexidade dessas bibliotecas bem desenvolvidas e também mantidas fornece implicitamente funcionalidades poderosas das quais um desenvolvedor importador geralmente não tem conhecimento em seu próprio novo desenvolvimento combinado, mas que podem ser exploradas por invasores.

Outro fator de insegurança dos componentes de código aberto são os chamados ataques à cadeia de suprimentos, ou seja, vulnerabilidades incorporadas pretendidas por atores mal-intencionados que se apresentam como parte da comunidade de código aberto e auxiliam no desenvolvimento de código. Essa vulnerabilidade é uma maneira extremamente eficiente para os hackers atacarem um grande número de organizações de usuários downstream. Não é de admirar, então, que esse vetor de ataque esteja crescendo rapidamente: um estudo Sonatype diagnosticou um aumento de 650% ao comparar 2020 e 2021.

Controle de segurança da informação 8.28 codificação segura

Para salvaguardar o processo de desenvolvimento de software em tempo hábil, a Organização Internacional para Padronização (ISO - comitê ISO/IEC JTC 1/SC 27) incluiu "Codificação Segura" como um novo controle 8.28 na nova ISO/IEC 27002 e ISO/IEC 27001:2022, Normas do Anexo A. A finalidade da medida técnica de codificação segura é a proteção preventiva do software.

Um nível mínimo de segurança é criado desde a fase de redação com base em normas processuais, minimizando assim o número de possíveis vulnerabilidades de segurança no software. A estrutura regulatória para geração segura de código deve ser aplicada de forma holística tanto ao código do programa da própria empresa quanto ao software de terceiros e fontes de código aberto. Princípios notáveis ​​para implementação são Segurança por Design Menor Privilégio, que também devem ser considerados na codificação. 

Princípios de codificação segura

A Medida 8.28 aborda os chamados princípios de codificação segura várias vezes. A orientação sobre o que eles podem ser é fornecida por várias organizações e institutos que publicam regularmente guias e práticas recomendadas para codificação segura. Estes incluem, por exemplo, as Práticas de Codificação Segura da Fundação OWASP, as Normas de Codificação Segura da Equipa de Resposta a Emergências Informáticas (CERT) do Instituto de Engenharia de Software (SEI), e o catálogo alemão do BSI de medidas para a segurança de aplicações web. Apesar das diferentes fontes, as elaborações apresentam muitos paralelos, por exemplo no que diz respeito aos seguintes pontos:

• Validação da entrada de dados 
• Protegendo a autenticação e o gerenciamento de senhas 
• Controle de acesso seguro
• Código simples e transparente
• Medidas e componentes criptográficos testados de forma sustentável 
• Tratamento de erros e registo
• Proteção de dados
• Modelagem de ameaças

Na norma ISO/ISO 27002:2022, as ações recomendadas para o Controle 8.28 são divididas em três seções, "Planejamento e pré-codificação", "Durante a codificação" e "Verificação e manutenção", cujos principais conteúdos são descritos abaixo.

Planejamento e pré-codificação

Tanto o desenvolvimento de novos códigos quanto a reutilização de códigos exigem a aplicação de princípios de codificação seguros - independentemente de o código ser escrito para software interno ou para produtos e serviços externos. Isso requer a avaliação das expectativas específicas da organização e a definição de princípios reconhecidos com antecedência. Além disso, as ações recomendadas para planejamento e pré-codificação levam em consideração práticas e erros de codificação comuns e históricos conhecidos que podem levar a vulnerabilidades. 

A configuração de ferramentas de desenvolvimento, como baseadas em regras em ambientes de desenvolvimento integrado (IDE), deve impor a criação de código seguro. Bastante crítica é a qualificação dos desenvolvedores e sua familiaridade com arquiteturas seguras e padrões de programação. A inclusão de especialistas em segurança da informação na equipe de desenvolvimento é óbvia. 

Durante o processo de codificação

Durante o processo de codificação, práticas de codificação e técnicas de programação estruturada desempenham um papel primordial, levando em consideração o caso de uso específico e suas necessidades de segurança. Técnicas de design inseguras - por exemplo, senhas codificadas - devem ser consistentemente proibidas. O código deve ser adequadamente documentado e revisado para melhor eliminar bugs relacionados à segurança. A revisão do código deve ocorrer durante e após o desenvolvimento, por meio de teste de segurança de aplicativo estático (SAST) ou similar. Os métodos de teste estático suportam a abordagem de deslocamento à esquerda ("teste cedo e com frequência"), deslocando à esquerda no ciclo de vida, testando o código visível para conformidade com as regras antecipadamente. 

Isso permite a identificação antecipada de código corrompido, conexões com arquivos ou classes de objeto específicas ou lacunas no nível do aplicativo que podem ser abusadas para interação despercebida com programas de terceiros como vulnerabilidades exploráveis. Antes que o software seja colocado em operação, o Controle 8.28 exige uma avaliação das superfícies de ataque e a implementação do princípio do privilégio mínimo. Deve ser avaliada a análise realizada dos erros de programação mais comuns e a documentação da sua correção.

Verificação e manutenção

Mesmo após o lançamento do software, o tópico da codificação segura permanece relevante. Isso inclui atualizações seguras, bem como verificações de vulnerabilidades conhecidas no código. Além disso, erros e suspeitas de ataques devem ser documentados para que os ajustes necessários possam ser feitos prontamente. Em qualquer caso, o acesso não autorizado ao código-fonte deve ser impedido de forma confiável por ferramentas adequadas. 

Código-fonte aberto

Na área de verificação e manutenção, a Medida 8.28 lista ainda instruções explícitas para o uso de ferramentas e bibliotecas externas, como software de código aberto. Esses componentes de código devem ser gerenciados, atualizados e mantidos em inventários. Isso pode ser feito, por exemplo, por meio de uma lista de materiais de software (SBOM). Um SBOM é um registro formal e estruturado dos pacotes e bibliotecas de um software e suas relações entre si e dentro da cadeia de suprimentos, em particular para acompanhar o código reutilizado e os componentes de código aberto. O SBOM suporta manutenção de software e atualizações de segurança direcionadas. 

Conclusão

O código seguro é uma base elementar para interromper ataques em potencial. O novo Control 8.28 leva em consideração esse insight sofrido e atualiza o papel fundamental da codificação segura em sua importância para a segurança da informação. No entanto, como a medida contém um grande número de recomendações detalhadas de ação e é tecnicamente exigente, a sua implementação envolverá um nível de esforço comparativamente elevado – o que deve ser tido em conta desde a fase de planeamento. 

Com a visão profissional de nossos auditores experientes, apoiamos você na implementação adequada da medida. Com nossa experiência em auditoria e certificação de mais de 35 anos, somos seu parceiro de contato ideal e teremos prazer em ajudá-lo com o tema segurança da informação e certificação de acordo com os padrões ISO/IEC 27001:2022. 

Revisão da ISO 27001: O que a atualização significa para a sua certificação?

A versão nova da ISO/IEC 27001 foi publicada em 25 de outubro de 2022. Isto resulta nos seguintes prazos de transição:

Última data para auditorias iniciais/recertificação de acordo com a “antiga” ISO 27001:2013 

• Após 30 de abril de 2024, a DQS realizará auditorias iniciais e de recertificação apenas de acordo com a nova norma ISO/IEC 27001:2022

Transição de todos os certificados existentes de acordo com a "antiga" ISO/IEC 27001:2013 para a nova ISO/IEC 27001:2022

• Há um período de transição de 3 anos a partir de 31 de outubro de 2022 
• Os certificados emitidos de acordo com ISO/IEC 27001:2013 ou DIN EN ISO/IEC 27001:2017 são válidos até 31 de outubro de 2025, o mais tardar, ou devem ser retirados nesta data

DQS: simplesmente alavancando a Segurança.

Devido aos períodos de transição, as empresas têm tempo suficiente para adaptar seu SGSI de acordo com os novos requisitos e certificá-lo. No entanto, a duração e o esforço de todo o processo de mudança não devem ser subestimados - especialmente se você não tiver pessoal especializado suficiente. Se você quiser estar do lado seguro, você deve lidar com o problema o mais cedo possível e recorrer a especialistas experientes, se necessário.

Como especialistas em auditoria e certificação com mais de 35 anos de experiência, temos o prazer de apoiá-lo na avaliação de seu status atual, talvez como parte de uma auditoria delta. Informe-se com nossos numerosos auditores experientes sobre as mudanças mais importantes e sua relevância para sua organização. Juntos, discutiremos seu potencial de melhoria e o apoiaremos até que você receba seu novo certificado. Aproveite nossa competência em segurança da informação! Estamos ansiosos para ouvir de você.