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 significa a actualização para a sua certificação?
• DQS - Simplesmente alavancar a Segurança.

Vulnerabilidades de segurança em código

O software do sistema operativo, software de aplicação ou firmware num sistema integrado são componentes elementares de qualquer infra-estrutura digital. Contudo, a crescente aceleração e pressão de prazos em projectos de digitalização conduzem frequentemente a uma negligência de aspectos imperativos de segurança da informação. Os requisitos de desenvolvimento de software são geralmente centrados na função e enfatizam aspectos construtivos, de modo que a visão destrutiva de potenciais vulnerabilidades de segurança é na sua maioria diametralmente oposta aos objectivos de desenvolvimento reais: a muitos programadores falta simplesmente também uma visão estruturada e afiada da segurança cibernética.

Nestas condições, as equipas de desenvolvimento têm dificuldade em rever continuamente e assegurar consistentemente a codificação do seu software, como evidenciado pelas muitas vulnerabilidades que a Corporação MITRE sem fins lucrativos publica cada ano na sua lista CVE (Common Vulnerabilities and Exposures). Os patches de segurança regulares, mesmo de fabricantes de software bem conhecidos, são um indicador da tarefa Sisyphean de fechar bugs relevantes para a segurança, quanto mais de os identificar 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 não tiver de reinventar a roda uma e outra vez, beneficia deste impulso tecnológico, desenvolvimento rápido, custos de desenvolvimento mais baixos, mais transparência através de código fonte aberto, e maior interoperabilidade através de normas e interfaces abertas.

Também se diz frequentemente que o código de fonte aberta oferece um elevado grau de segurança, porque o código foi validado por muitos utilizadores e a inteligência de enxame da comunidade de fonte aberta permite uma rápida e eficiente correcção de bugs.

Na prática, esta confiança deve agora ser avaliada de uma forma diferenciada e crítica. O exemplo mais sério é a vulnerabilidade de segurança de dia zero Log4Shell na amplamente utilizada biblioteca de registo Log4J para aplicações Java, que foi descoberta em Novembro de 2021. Poderá ter ouvido falar do nível de alerta vermelho emitido pelo Gabinete Federal Alemão para a Segurança da Informação (BSI) para Log4Shell. A biblioteca Log4J, distribuída como um quase-padrão de funcionamento fiável através da Fundação Apache, estabeleceu-se em muitos sistemas desde 2013 - incluindo serviços web bem conhecidos como o Amazon AWS.

A complexidade destas bibliotecas bem desenvolvidas e também mantidas fornece implicitamente poderosas funcionalidades das quais um desenvolvedor importador muitas vezes desconhece no seu novo desenvolvimento combinado, mas que podem ser exploradas por atacantes.

Outro factor de insegurança dos componentes de código aberto são os chamados ataques de cadeia de fornecimento, ou seja, vulnerabilidades incorporadas pretendidas por actores maliciosos que se apresentam como parte da comunidade de código aberto e ajudam no desenvolvimento de códigos. Tal vulnerabilidade é uma forma extremamente eficiente de os hackers atacarem um grande número de organizações de utilizadores a jusante. Não admira, pois, que este vector de ataque esteja a crescer rapidamente: um estudo Sonatype diagnosticou um aumento de 650% quando se comparam 2020 e 2021.

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

A fim de salvaguardar o processo de desenvolvimento de software de forma atempada, a Organização Internacional de Normalização (ISO - comité ISO/IEC JTC 1/SC 27) incluiu "Secure Coding" como novo controlo 8,28 nas novas normas ISO/IEC 27002 e ISO/IEC 27001:2022, Anexo A. O objectivo da medida técnica para a codificação segura é a protecção preventiva do software.

Um nível mínimo de segurança é criado logo na fase de escrita com base nos regulamentos processuais, minimizando assim o número de potenciais vulnerabilidades de segurança no software. O quadro regulamentar para a geração de código seguro deve ser aplicado de forma holística tanto ao próprio código do programa da empresa como ao software de terceiros e fontes de código aberto. Os princípios notáveis para implementação são Segurança por Concepção e Menos Privilégios, que também devem ser considerados na codificação.

Princípios de codificação segura

A medida 8.28 aborda várias vezes os chamados princípios de codificação segura. As orientações sobre o que estes podem ser fornecidos são fornecidas por numerosas organizações e institutos que emitem regularmente guias e melhores práticas para uma 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 mostram muitos paralelos, por exemplo no que diz respeito aos seguintes pontos:

• Validação da introdução de dados
• Assegurar a autenticação e gestão de palavra-passe
• Controlo de acesso seguro
• Código simples e transparente
• Medidas criptográficas e componentes testados de forma sustentável
• Tratamento de erros e registo
• Protecção de dados
• Modelagem de ameaças

Na norma ISO/ISO 27002:2022, as acções recomendadas para o Controlo 8.28 estão divididas em três secções, "Planeamento e pré-codificação", "Durante a codificação", e "Verificação e manutenção", cujos conteúdos essenciais são descritos abaixo.

Planeamento e pré-codificação

Tanto o desenvolvimento de novos códigos como 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. Isto requer a avaliação das expectativas específicas da organização e a definição prévia de princípios reconhecidos. Além disso, as acções recomendadas para planeamento e pré-codificação têm em conta práticas de codificação comuns e históricas conhecidas e erros que podem levar a vulnerabilidades.

A configuração de ferramentas de desenvolvimento, tais como baseadas em regras em ambientes de desenvolvimento integrado (IDE), deve impor a criação de código seguro. Muito importante é a qualificação dos programadores e a sua familiaridade com arquitecturas seguras e normas de programação. A inclusão de conhecimentos especializados em segurança da informação na equipa de desenvolvimento é evidente.

Durante o processo de codificação

Durante o processo de codificação, as práticas de codificação e as técnicas de programação estruturada desempenham um papel primordial, tendo em conta o caso específico de utilização e as suas necessidades de segurança. Técnicas de concepção inseguras - por exemplo, palavras-passe codificadas - devem ser consistentemente proibidas. O código deve ser adequadamente documentado e revisto para melhor eliminar os bugs relacionados com a segurança. A revisão do código deve ter lugar tanto durante como após o desenvolvimento, através de testes de segurança de aplicações estáticas (SAST) ou similares. Os métodos de testes estáticos apoiam a abordagem de deslocamento para a esquerda ("testar cedo e frequentemente"), deslocando-se para a esquerda no ciclo de vida através do teste precoce do código visível para conformidade com as regras.

Isto permite a identificação precoce de código manchado, ligações a ficheiros ou classes de objectos específicos, ou lacunas a nível de aplicação que podem ser abusivamente utilizadas para interacção despercebida com programas de terceiros como vulnerabilidades exploráveis. Antes de o software ser colocado em funcionamento, o Controlo 8.28 requer uma avaliação das superfícies de ataque e a implementação do princípio do privilégio mínimo. A análise realizada dos erros de programação mais comuns e a documentação da sua correcção devem ser avaliadas.

Verificação e manutenção

Mesmo após a entrada em funcionamento do software, o tema da codificação segura continua a ser relevante. Isto inclui actualizações seguras, bem como verificações de vulnerabilidades conhecidas no próprio código. Além disso, os erros e suspeitas de ataques devem ser documentados para que os ajustamentos necessários possam ser feitos prontamente. Em qualquer caso, o acesso não autorizado ao código fonte deve ser impedido de forma fiável por ferramentas adequadas.

Código-fonte aberto

Na área da verificação e manutenção, a Medida 8.28 enumera ainda instruções explícitas para a utilização de ferramentas e bibliotecas externas, tais como software de código aberto. Estes componentes de código devem ser geridos, actualizados e mantidos em inventários. Isto pode ser feito, por exemplo, através de uma Lista de Material de Software (SBOM). Uma SBOM é um registo formal e estruturado dos pacotes e bibliotecas de um software e das suas relações entre si e dentro da cadeia de fornecimento, em particular para manter um registo do código reutilizado e dos componentes de código aberto. A SBOM suporta a manutenção de software e actualizações de segurança direccionadas.

Conclusão

O código seguro é uma base elementar para pôr fim a potenciais ataques. O novo Control 8.28 tem em conta esta visão de longa data e actualiza o papel-chave da codificação segura na sua importância para a segurança da informação. Contudo, uma vez que a medida compreende um grande número de recomendações detalhadas de acção e é tecnicamente exigente, a sua implementação envolverá um nível de esforço comparativamente elevado - isto deve ser tido em conta logo na fase de planeamento.

Com a visão profissional dos nossos auditores experientes, apoiamo-lo na implementação conforme da medida. Com os nossos conhecimentos de auditoria e certificação de mais de 35 anos, somos o seu parceiro de contacto ideal e teremos todo o prazer em ajudá-lo com o tema da segurança da informação e certificação, em conformidade com as normas ISO/IEC 27001:2022.

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

A ISO/IEC 27001:2022 foi publicada a 25 de Outubro de 2022. Isto resulta nos seguintes prazos e prazos de transição para os utilizadores:

Preparação para a certificação ISO/IEC 27001:2022

• Esperado a partir de Maio de 2023 (dependendo do Organismo Alemão de Acreditação GmbH (DAkkS)).

Última data para auditorias iniciais/certificação de acordo com a "antiga" ISO 27001:2013

• Após 31 de Outubro de 2023, 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 da "antiga" ISO/IEC 27001:2013 para a nova ISO/IEC 27001:2022

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

DQS: Simplesmente a alavancar a Segurança.

Devido aos períodos de transição, as empresas têm tempo suficiente para adaptar o seu SGSI de acordo com os novos requisitos e para o certificar. Contudo, a duração e o esforço de todo o processo de mudança não deve ser subestimada - especialmente se não se dispuser de pessoal especializado suficiente. Se quiser estar do lado seguro, deve tratar do assunto mais cedo e não mais tarde 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 o apoiar na avaliação do seu estado actual, talvez como parte de uma auditoria delta. Informe-se junto dos nossos numerosos auditores experientes sobre as mudanças mais importantes e a sua relevância para a sua organização. Juntos discutiremos o seu potencial de melhoramento e apoiá-lo-emos até receber o seu novo certificado. Tire partido da nossa competência em segurança da informação! Aguardamos com expectativa a sua resposta.