Uso

As regras desta norma podem ser estendidas com regras específicas da organização. No entanto, as regras da norma devem ser obedecidas para reivindicar conformidade com a norma.

O treinamento pode ser desenvolvido para educar os profissionais de software sobre a aplicação adequada das normas de codificação. Após a aprovação de um exame, esses programadores treinados também podem ser certificados como profissionais de codificação. Por exemplo, a Certificação de Desenvolvedores de Software (SDC) é um programa de credenciamento desenvolvido na Universidade Carnegie Mellon. O SDC usa exame autêntico para

  1. Identificar candidatos a trabalho com habilidades específicas de programação.
  2. Demonstre a presença de uma força de trabalho de software bem treinada.
  3. Fornecer orientação para instituições de ensino e treinamento.

Uma vez estabelecido um padrão de codificação, ferramentas e processos podem ser desenvolvidos ou modificados para determinar a conformidade com o padrão.

Teste de conformidade

Para garantir que o código fonte esteja em conformidade com esse padrão de codificação, é necessário ter medidas em vigor que verifiquem se há violações de regras. O meio mais eficaz para alcançar esse objetivo é usar um ou mais analisadores ISO/IEC TS 17961 - conforme analisadores. Quando uma regra não pode ser verificada por uma ferramenta, é necessária uma revisão manual.

O Laboratório de Análise de Código Fonte (SCALe) fornece um meio para avaliar a conformidade dos sistemas de software em relação a esta e outras normas de codificação. As normas de codificação CERT fornecem um conjunto normativo de regras contra as quais os sistemas de software podem ser avaliados. A conformidade dos sistemas de software deve demonstrar melhorias na segurança, confiabilidade e segurança sobre sistemas não conformes.

A equipe do SCALe do Programa CERT, parte do Instituto de Engenharia de Software da Universidade Carnegie Mellon, analisa o código-fonte de um desenvolvedor e fornece um relatório detalhado das descobertas para orientar o reparo do código. Depois que o desenvolvedor abordou essas descobertas e a equipe do SCALe determina que a versão do produto está em conformidade com a norma, o Programa CERT emite ao desenvolvedor um certificado e lista o sistema em um registro de sistemas de conformidade. Este relatório detalha o processo SCALe e fornece uma análise dos sistemas de software selecionados.

Conformidade

A conformidade com o PADRÃO de Codificação C ® CERT exige que o código não contenha quaisquer violações das regras especificadas neste livro. Se uma condição excepcional for reivindicada, a exceção deve corresponder a uma condição excepcional predefinida, e a aplicação desta exceção deve ser documentada no código-fonte.

A conformidade com as recomendações na wiki não é necessária para reivindicar conformidade com o Padrão de Codificação C ® CERT. A conformidade com as recomendações facilitará, em muitos casos, o cumprimento das regras; eliminando muitas fontes potenciais de defeitos.

Procedimento de desvio

A adesão rigorosa a todas as regras é improvável e, consequentemente, são necessários desvios associados a violações específicas de regras. Os desvios podem ser usados em casos em que um achado real-positivo é incontestável como uma violação de regra, mas o código é determinado como correto. Uma descoberta verdadeira-positiva incontestável pode ser o resultado de um recurso de design ou arquitetura do software ou pode ocorrer por uma razão válida que não foi prevista pelo padrão de codificação. Nesse sentido, o procedimento de desvio permite a possibilidade de que as regras de codificação sejam excessivamente rigorosas [Seacord 2012].

Os desvios não serão aprovados por razões de desempenho ou usabilidade. Um sistema de software que passa com sucesso em testes de conformidade não deve conter defeitos ou vulnerabilidades exploráveis. As solicitações de desvio são avaliadas pelo assessor líder, e se o desenvolvedor pode fornecer evidências suficientes de que o desvio não resultará em vulnerabilidade, a solicitação de desvio é aceita. Os desvios devem ser usados com pouca frequência porque é quase sempre mais fácil corrigir um erro de codificação do que fornecer um argumento de que o erro de codificação não resulta em uma vulnerabilidade.

Qualidades do sistema

O objetivo deste padrão de codificação é produzir sistemas seguros, confiáveis e seguros. Podem existir requisitos adicionais para sistemas críticos à segurança, como a ausência de alocação dinâmica de memória. Outros atributos de qualidade de software de interesse incluem portabilidade, usabilidade, disponibilidade,manutenção, legibilidade e desempenho.

Muitos desses atributos estão interrelacionados de maneiras interessantes. Por exemplo, a legibilidade é um atributo de manutenção; ambos são importantes para limitar a introdução de defeitos durante a manutenção que podem resultar em falhas de segurança ou problemas de confiabilidade. Além disso, auxiliares de legibilidade codificam a inspeção por agentes de segurança. Confiabilidade e disponibilidade exigem uma gestão adequada dos recursos, o que também contribui para a segurança do sistema. Atributos do sistema, como desempenho e segurança, estão frequentemente em conflito, exigindo que as compensações sejam consideradas.

Como este livro é organizado

Este livro é organizado em 14 capítulos contendo regras em áreas específicas de tópicos, três apêndices, uma bibliografia e um índice. O primeiro apêndice é um glossário de termos usados através deste livro. Os termos listados no glossário são impressos em fonte em negrito na primeira vez que aparecem e, em seguida, em fonte normal em aparições subsequentes. O segundo anexo lista o comportamento indefinido da Norma C, anexo J, J.2 [ISO/IEC 9899:2011], numerado e classificado para fácil referência. Esses comportamentos indefinidos numerados são referenciados frequentemente a partir das regras. O terceiro anexo contém comportamentos não especificados da Norma C, Anexo J, J.1 [ISO/IEC 9899:2011]. Esses comportamentos não especificados são ocasionalmente referenciados das regras também. A bibliografia é um compêndio das pequenas seções bibliografia de cada regra, bem como outras referências citadas ao longo do livro.

A maioria das regras tem uma estrutura consistente. Cada regra nesta norma tem um identificador único, que está incluído no título. O título e os parágrafos introdutórios definem a regra e são normalmente seguidos por um ou mais pares de exemplos de código não conformes e soluções compatíveis. Cada regra também inclui uma avaliação de risco, diretrizes relacionadas e uma bibliografia (quando aplicável). As regras também podem incluir uma tabela de vulnerabilidades relacionadas. As recomendações sobre o CERT Coding Standards wiki são organizadas de forma semelhante.

Identificadores

Cada regra e recomendação é dada um identificador único, que consiste em três partes:

  • Um mnemônico de três letras representando a seção do padrão
  • Um valor numérico de dois dígitos na faixa de 00 a 99
  • A letra C indicando que esta é uma diretriz de linguagem C

O mnemônico de três letras é usado para agrupar práticas de codificação semelhantes e para indicar a que categoria pertence uma prática de codificação.

O valor numérico é usado para dar a cada prática de codificação um identificador único. Valores numéricos na faixa de 00 a 29 são reservados para recomendações, e valores na faixa de 30 a 99 são reservados para regras. As regras e recomendações são frequentemente referenciadas a partir das regras deste livro pelo seu identificador e título. As regras podem ser encontradas na tabela de conteúdos do livro, enquanto as recomendações só podem ser encontradas na wiki.

Exemplos de código não compatíveis e soluções compatíveis

Exemplos de código não compatíveis ilustram código que viola a diretriz em discussão. É importante notar que estes são apenas exemplos, e eliminar todas as ocorrências do exemplo não significa necessariamente que o código que está sendo analisado esteja agora em conformidade com a diretriz.

Exemplos de código não compatíveis são normalmente seguidos por soluções compatíveis, que mostram como o exemplo de código não compatível pode ser recodificado de forma segura e compatível. Exceto quando observado, exemplos de códigos não conformes devem conter violações apenas da regra em discussão. As soluções compatíveis devem estar em conformidade com todas as regras de codificação seguras, mas podem, ocasionalmente, não cumprir uma recomendação.

Exceções

Qualquer regra ou recomendação pode especificar um pequeno conjunto de exceções detalhando as circunstâncias em que a prática de codificação não é necessária para garantir a segurança, confiabilidade ou segurança do software. As exceções são apenas informativas e não são necessárias para serem seguidas.

Avaliação do risco

Cada diretriz do CERT® C Coding Standard, segunda edição contém uma seção de Avaliação de Risco que tenta fornecer aos desenvolvedores de software uma indicação das consequências potenciais de não abordar uma determinada vulnerabilidade em seu código (juntamente com alguma indicação dos custos de remediação esperados). Essas informações podem ser usadas para priorizar o reparo de classes de vulnerabilidade por uma equipe de desenvolvimento. A métrica é projetada principalmente para projetos de remediação. Presume-se geralmente que um novo código será desenvolvido para estar em conformidade com todo o padrão de codificação e recomendações aplicáveis.

Cada regra e recomendação tem uma prioridadeatribuída. As prioridades são atribuídas usando uma métrica baseada no Modo de Falha, Efeitos e Análise de Criticidade (FMECA) [IEC 60812]. Três valores são atribuídos para cada regra em uma escala de 1 a 3 para corte, probabilidade e custo de remediação.

Gravidade— Quão graves são as consequências da regra ser ignorada?

Valor Significado Exemplos de vulnerabilidade
1 Baixo Ataque de negação de serviço, rescisão anormal
2 Média Violação de integridade de dados, divulgação de informações não intencionais
3 Alto Executar código arbitrário

Probabilidade — Qual a probabilidade de que uma falha introduzida ignorando a regra possa levar a uma vulnerabilidade explorável?

Valor Significado
1 Improvável
2 Provável
3 Provável

Custo de remediação — Quão caro é cumprir a regra?

Valor Significado Detecção Correção
1 Alto Manual Manual
2 Média Automático Manual
3 Baixo Automático Automático

Os três valores são então multiplicados juntos para cada regra. Este produto fornece uma medida que pode ser usada na priorização da aplicação das regras. Os produtos variam de 1 a 27, embora sejam possíveis apenas os seguintes 10 valores distintos: 1, 2, 3, 4, 6, 8, 9, 12, 18 e 27. Regras e recomendações com prioridade na faixa de 1 a 4 são regras de Nível 3, 6 a 9 são de Nível 2 e 12 a 27 são de Nível 1. São possíveis interpretações das prioridades e níveis:

Nível Prioridades Possível Interpretação
L1 12, 18, 27 Alta gravidade, provavelmente, barata para reparar
L2 6, 8, 9 Severidade média, provável, custo médio para reparar
L3 1, 2, 3, 4 Baixa gravidade, improvável, caro para reparar

Projetos específicos podem começar a remediar implementando todas as regras em um determinado nível antes de proceder a regras prioritárias mais baixas, como mostrado na Figura P-2.

image

Detecção automatizada

Na wiki, tanto as regras quanto as recomendações frequentemente têm seções que descrevem a detecção automatizada. Essas seções fornecem informações adicionais sobre analisadores que podem diagnosticar automaticamente violações das diretrizes de codificação. A maioria das análises automatizadas para a linguagem de programação C não são sólidas nem completas, então a inclusão de uma ferramenta nesta seção normalmente significa que a ferramenta pode diagnosticar algumas violações desta regra em particular. Embora o C Secure Coding Validation Suite possa ser usado para testar a capacidade dos analisadores de diagnosticar violações de regras do ISO/IEC TS 17961, nenhum conjunto de testes de conformidade atualmente disponível pode avaliar a capacidade dos analisadores de diagnosticar violações das regras neste livro. Consequentemente, as informações em seções de detecção automatizada na wiki podem ser

  • Fornecido pelos fornecedores
  • Determinado pelo CERT avaliando informalmente o analisador
  • Determinado pelo CERT revisando a documentação do fornecedor

Sempre que possível, tentamos fazer referência à versão exata da ferramenta para a qual os resultados foram obtidos. Como as ferramentas evoluem continuamente, essas informações podem rapidamente se tornar datadas e obsoletas. Consequentemente, essas informações foram omitidas deste livro e mantidas apenas na wiki.

Vulnerabilidades Relacionadas

As seções vulnerabilidades relacionadas na wiki contêm um link para procurar vulnerabilidades relacionadas no site do CERT. Sempre que possível, as Notas de Vulnerabilidade CERT são marcadas com uma palavra-chave correspondente ao ID exclusivo da diretriz de codificação. Esta pesquisa fornece a você uma lista atualizada de vulnerabilidades do mundo real que foram determinadas como sendo pelo menos parcialmente causadas por uma violação desta diretriz específica. Essas vulnerabilidades são rotuladas como tal apenas quando a equipe de análise de vulnerabilidades do CERT/CC é capaz de avaliar o código-fonte e determinar precisamente a causa da vulnerabilidade. Como muitas notas de vulnerabilidade referem-se a vulnerabilidades em sistemas de software de código fechado, nem sempre é possível fornecer essa análise adicional. Consequentemente, o campo de vulnerabilidades relacionadas tende a ser um pouco pouco povoado.

Para encontrar a lista mais recente de vulnerabilidades relacionadas, digite a seguinte URL:

https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+XXXNN-X

onde XXXNN-X é o ID da regra ou recomendação para a qual você está pesquisando.

Identificadores específicos de vulnerabilidade (VU) e identificadores de vulnerabilidades e exposições comuns (CVE) são referenciados ao longo deste livro. Você pode criar uma URL exclusiva para obter mais informações sobre vulnerabilidades específicas, anexando o ID relevante ao final de uma sequência fixa. Por exemplo, para encontrar mais informações sobre

  • VU#551436, “Visualizador Mozilla Firefox SVG vulnerável ao estouro inteiro”, você pode anexar 551436 a https://www.kb.cert.org/vulnotes/id/ e inserir a URL resultante no seu navegador: https://www.kb.cert.org/vulnotes/id/551436
  • CVE-2006-1174, você pode anexar CVE-2006-1174 a http://cve.mitre.org/cgi-bin/cvename.cgi?name= e inserir a URL resultante no seu navegador: http://cve.mitre.org/cgi-bin/cvename.cgi?name= CVE-2006-1174

As seções de Vulnerabilidade Relacionada são incluídas apenas para regras específicas neste livro, quando as informações são relevantes e interessantes.

Diretrizes Relacionadas

Esta seção contém links para diretrizes em padrões relacionados, especificações técnicas e coleções de diretrizes como Tecnologia da Informação — Linguagens de Programação, Seus Ambientes e Interfaces de Software de Sistema — C Regras de Codificação Segura [ISO/IEC TS 17961:2013]; Tecnologia da Informação — Linguagens de Programação — Orientação para evitar vulnerabilidades em linguagens de programação através da seleção e uso de idiomas [ISO/IEC TR 24772:2013]; MISRA C3: Diretrizes para o uso da linguagem C em sistemas críticos [MISRA C:2012]; e IDs CWE na Enumeração de Fraqueza Comum (CWE) da MITRE [MITRE 2013].

Você pode criar uma URL exclusiva para obter mais informações sobre CWEs, anexando o ID relevante até o final de uma sequência fixa. Por exemplo, para encontrar mais informações sobre o CWE ID 192, “Erro de Coerção Inteiro”, você pode anexar 192.html a http://cwe.mitre.org/data/definitions/ e inserir a URL resultante no seu navegador: http://cwe.mitre.org/data/definitions/192.html.

As demais especificações técnicas, relatórios técnicos e diretrizes mencionadas estão disponíveis comercialmente.

Bibliografia

A maioria das regras tem uma pequena seção bibliografia que lista documentos e seções nesses documentos que fornecem informações relevantes à regra.

Código gerado automaticamente

Se uma ferramenta de geração de código for usada, é necessário selecionar uma ferramenta apropriada e realizar a validação. A adesão aos requisitos deste documento pode fornecer um critério para avaliar uma ferramenta.

A orientação de codificação varia dependendo de como o código é gerado e mantido. As categorias de código incluem as seguintes:

  • Código de código mantido por ferramentas gerado por ferramentas especificado e mantido em um formato de nível mais alto a partir do qual o código fonte específico do idioma é gerado. O código-fonte é gerado a partir desta descrição de nível superior e, em seguida, fornecido como entrada para o compilador de idiomas. O código-fonte gerado nunca é visualizado ou modificado pelo programador.
  • Código de código gerado por ferramenta e mantido à mão que é especificado e mantido em um formato de nível mais alto a partir do qual o código fonte específico do idioma é gerado. Espera-se ou antecipe-se, no entanto, que em algum momento do ciclo de desenvolvimento, a ferramenta deixe de ser usada e o código fonte gerado será visto visualmente e/ou modificado manualmente e mantido.
  • O código codificado à mão é escrito manualmente por um programador usando um editor de texto ou um ambiente de desenvolvimento interativo; o programador mantém o código-fonte diretamente no formato de código-fonte fornecido ao compilador.

O código fonte que é escrito e mantido manualmente deve ter as seguintes propriedades:

  • Legibilidade
  • Compreensão do programa

Esses requisitos não são aplicáveis para código-fonte que nunca é tratado diretamente por um programador, embora os requisitos para o comportamento correto ainda se aplicam. Os requisitos de leitura e compreensão aplicam-se ao código que é gerado e mantido à mão, mas não se aplica ao código gerado pela ferramenta e mantido pela ferramenta. O código mantido por ferramentas e gerado por ferramentas pode impor restrições consistentes que garantem a segurança de alguns construtos que são arriscados no código gerado manualmente.

Regulamentos governamentais

Desenvolver software para proteger regras de codificação é uma boa ideia e é cada vez mais um requisito. A Lei de Autorização de Defesa Nacional para o Ano Fiscal de 2013, Seção 933, “Melhorias na Garantia de Software de Computador Adquirido pelo Departamento de Defesa”, requer evidências de que as organizações e contratantes de desenvolvimento e manutenção de software do governo estão em conformidade, em codificação de software de computador, com padrões de codificação seguras aprovados do Departamento de Defesa (DoD) durante as atividades de desenvolvimento, atualização e manutenção de software do software, inclusive através do uso de inspeção e avaliações.

Os programas de aquisição do DoD estão especificando o Guia técnico de implementação de segurança e desenvolvimento de aplicativos (STIG),versão 2, Lançamento 1 [DISA 2008] em pedidos de proposta (RFPs). A seção 2.1.5, “Padrões de Codificação”, exige que “o Gerente do Programa garanta que a equipe de desenvolvimento siga um conjunto de padrões de codificação”.

A aplicação adequada desta norma permitiria que um sistema cumprisse os seguintes requisitos do STIG [DISA 2008] de Segurança e Desenvolvimento de Aplicativos:

  • (APP2060.1: CAT II) O Gerente do Programa garantirá que a equipe de desenvolvimento siga um conjunto de padrões de codificação.
  • (APP2060.2: CAT II) O Gerente do Programa garantirá que a equipe de desenvolvimento crie uma lista de funções inseguras para evitar e documentar esta lista nos padrões de codificação.
  • (APP3550: CAT I) O Designer garantirá que a aplicação não seja vulnerável a problemas aritméticos inteiros.
  • (APP3560: CAT I) O Designer garantirá que o aplicativo não contenha vulnerabilidades de string de formato.
  • (APP3570: CAT I) O Designer garantirá que o aplicativo não permita a injeção de comando.
  • (APP3590.1: CAT I) O Designer garantirá que o aplicativo não tenha estouros de buffer.
  • (APP3590.2: CAT I) O Designer garantirá que o aplicativo não use funções conhecidas como vulneráveis a estouros de buffer.
  • (APP3590.3: CAT II) O Designer garantirá que o aplicativo não use valores assinados para alocação de memória, quando permitido pela linguagem de programação.
  • (APP3600: CAT II) O Designer garantirá que o aplicativo não tenha vulnerabilidades de representação canônica.
  • (APP3630.1: CAT II) O Designer garantirá que a aplicação não seja vulnerável às condições de corrida.
  • (APP3630.2: CAT III) O Designer garantirá que o aplicativo não use variáveis globais quando variáveis locais podem ser usadas.

Programadores de treinamento e testadores de software satisfazerão os seguintes requisitos:

  • (APP2120.3: CAT II) O Gerente de Programas garantirá que os desenvolvedores sejam fornecidos com treinamento sobre práticas seguras de design e codificação em pelo menos uma base anual.
  • (APP2120.4: CAT II) O Gerente do Programa garantirá que os testadores sejam fornecidos treinamento anual.
  • (APP2060.3: CAT II) O Designer seguirá os padrões de codificação estabelecidos para o projeto.
  • (APP2060.4: CAT II) O Designer não usará funções inseguras documentadas nos padrões de codificação do projeto.
  • (APP5010: CAT III) O Gerenciador de Testes garantirá que pelo menos um testador seja designado para testar falhas de segurança, além de testes funcionais.

Artigo Original