Processos seguros do ciclo de vida de desenvolvimento de software

Autor (es): Noopur Davis Níveis de maturidade e indicadores de público-alvo: L3/ SDLC Ciclos de vida: Arquitetura   Implementação transversal   Implementação   Projeto   Implementação   Testes de requisitos de manutenção      Copyright:  Copyright © Carnegie Mellon University 2005-2012.

Resumo

Este artigo apresenta informações gerais sobre processos, padrões, modelos de ciclo de vida, estruturas e metodologias existentes que oferecem suporte ou podem oferecer suporte ao desenvolvimento seguro de software. O relatório inicial emitido em 2006 foi atualizado para refletir as alterações.

Definições do
escopo de público-alvo Modelos de maturidade de capacidade em segundo plano

Equipe de Ciclo de Vida de Desenvolvimento de Segurança de Computação Confiável da Microsoft Processo de software para
correção de desenvolvimento seguro de software (TSP) por
métodos ágeis de construção
Os critérios comuns
Modelo de maturidade para garantia de
software Resumo da estrutura de segurança de software

Público-alvo 1

 

O público-alvo deste documento inclui gerentes de programas e projetos, desenvolvedores e todos os indivíduos que oferecem suporte à segurança aprimorada no software desenvolvido. Também é relevante para os membros do grupo de processos de engenharia de software (SEPG) que desejam integrar a segurança em seus processos padrão de desenvolvimento de software.

Escopo

As áreas de tecnologia e conteúdo descritas incluem estruturas e padrões existentes, como a estrutura Capability Maturity Model Integration 2 (CMMI), Team Software Process (TSP), 3 o FAA-iCMM, a Trusted CMM/Trusted Software Methodology (T-CMM/TSM) e o SSE-CMM (Systems Security Engineering Capability Maturity Model). Além disso, estão incluídos os esforços especificamente voltados para a segurança no SDLC, como o Ciclo de Vida de Desenvolvimento de Software de Computação Confiável da Microsoft, o Processo de Software de Equipe para o Desenvolvimento Seguro de Software (TSP SM-Segura), correção por construção, métodos ágeis e critérios comuns. Duas abordagens, o Software Assurance Maturity Model (SAMM) e o Software Security Framework (SSF), que foram lançadas recentemente, foram adicionadas para fornecer ao leitor o máximo de informações atualizadas possível.

Definições

Estes são alguns termos usados ​​neste documento para os quais um entendimento comum seria útil.

Processo – O IEEE define um processo como “uma sequência de etapas executadas para um determinado objetivo” [ IEEE 90 ]. Um processo de software seguro pode ser definido como o conjunto de atividades realizadas para desenvolver, manter e fornecer uma solução de software segura. As atividades podem não ser necessariamente sequenciais; eles podem ser simultâneos ou iterativos.

Modelo de processo – Um modelo de processo fornece um conjunto de referência de práticas recomendadas que podem ser usadas para melhoria e avaliação de processos. Modelos de processo não definem processos; eles definem as características dos processos. Modelos de processo geralmente têm uma arquitetura ou uma estrutura. Os grupos de melhores práticas que levam à consecução de objetivos comuns são agrupados em áreas de processo, e áreas de processo similares podem ainda ser agrupadas em categorias. A maioria dos modelos de processos também possui uma dimensão de capacidade ou maturidade, que pode ser usada para fins de avaliação e avaliação.

É importante entender os processos que uma organização está usando para criar software seguro, porque, a menos que o processo seja entendido, é difícil determinar seus pontos fracos e fortes. Também é útil usar estruturas comuns para orientar a melhoria de processos e avaliar processos em relação a um modelo comum para determinar áreas de melhoria. Os modelos de processos promovem medidas comuns dos processos organizacionais ao longo do ciclo de vida de desenvolvimento de software (SDLC). Esses modelos identificam muitas práticas técnicas e de gerenciamento. Embora muito poucos desses modelos tenham sido projetados desde o início para tratar da segurança, há evidências substanciais de que esses modelos abordam boas práticas de engenharia de software para gerenciar e construir software [ Goldenson 03 , Herbsleb 94 ].

Mesmo quando as organizações estão em conformidade com um modelo de processo específico, não há garantia de que o software que elas construam esteja livre de vulnerabilidades de segurança não intencionais ou código malicioso intencional. No entanto, provavelmente existe uma probabilidade maior de criar software seguro quando uma organização segue práticas sólidas de engenharia de software, com ênfase em bom design, práticas de qualidade como inspeções e revisões, uso de métodos de teste completos, uso apropriado de ferramentas, gerenciamento de riscos, projeto gestão e gestão de pessoas.

Padrões – Os padrões são estabelecidos por alguma autoridade, costume ou consentimento geral como exemplos de melhores práticas. As normas fornecem material adequado para a definição de processos.

Avaliações, avaliações, avaliações – Todos esses três termos implicam a comparação de um processo sendo praticado com um modelo ou padrão de processo de referência. Avaliações, avaliações e avaliações são usadas para entender a capacidade do processo, a fim de melhorar os processos. Eles ajudam a determinar se os processos praticados são especificados, projetados, integrados e implementados adequadamente para dar suporte às necessidades, incluindo as necessidades de segurança, do produto de software. Eles também são mecanismos importantes para selecionar fornecedores e monitorar o desempenho dos fornecedores.

Garantia de software – SwA é definido como “o nível de confiança de que o software está livre de vulnerabilidades, intencionalmente projetado no software ou inserido acidentalmente a qualquer momento durante seu ciclo de vida, e que o software funciona da maneira pretendida” [ CNSS 06 ]. No Capability Maturity Model for Software, o objetivo da “garantia de software” é descrito como fornecendo visibilidade adequada do processo usado pelos projetos de software e dos produtos que estão sendo construídos [ Paulk 93 ].

Garantia de segurança – Embora o termo “garantia de segurança” seja frequentemente usado, não parece haver uma definição acordada para esse termo. O CMM de engenharia de sistemas e segurança descreve “garantia de segurança” como o processo que estabelece a confiança de que as necessidades de segurança de um produto estão sendo atendidas. Em geral, o termo significa as atividades, métodos e procedimentos que fornecem confiança nas propriedades e funções relacionadas à segurança de uma solução desenvolvida.

Na seção Security Assurance do seu Software Assurance Guidebook [ NASA ], a NASA define um programa mínimo de garantia de segurança como aquele que garante o seguinte:

  • Uma avaliação de risco de segurança foi realizada.
  • Os requisitos de segurança foram estabelecidos para o software e os dados que estão sendo desenvolvidos e/ou mantidos.
  • Os requisitos de segurança foram estabelecidos para o processo de desenvolvimento e/ou manutenção.
  • Cada revisão e/ou auditoria de software inclui a avaliação dos requisitos de segurança.
  • Os processos de gerenciamento de configuração e ação corretiva fornecem segurança para o software existente e os processos de avaliação de alterações evitam violações de segurança.
  • A segurança física do software e dos dados é adequada.

A garantia de segurança geralmente também inclui atividades para as fases de requisitos, design, implementação, teste, liberação e manutenção de um SDLC.

fundo

Uma pesquisa dos processos, modelos e padrões de processos existentes identifica as quatro áreas de foco do SDLC a seguir para o desenvolvimento seguro de software.

  1. Atividades de engenharia de segurança . As atividades de engenharia de segurança incluem atividades necessárias para projetar uma solução segura. Os exemplos incluem definição e definição de requisitos de segurança, design seguro com base nos princípios de design para segurança, uso de ferramentas de análise estática, revisões e inspeções seguras e testes seguros. As atividades de engenharia foram descritas em outras seções do site Build Security In.
  2. Atividades de garantia de segurança . As atividades de garantia incluem verificação, validação, revisão de especialistas, revisão de artefatos e avaliações.
  3. Atividades de segurança organizacional e de gerenciamento de projetos . As atividades organizacionais incluem políticas organizacionais, patrocínio e supervisão da gerência sênior, estabelecimento de funções organizacionais e outras atividades organizacionais que dão suporte à segurança. As atividades de gerenciamento de projetos incluem o planejamento do projeto e o rastreamento da alocação e uso de recursos para garantir que as atividades de engenharia de segurança, garantia de segurança e identificação de riscos sejam planejadas, gerenciadas e rastreadas.
  4. Identificação de riscos de segurança e atividades de gerenciamento . Existe um amplo consenso na comunidade de que identificar e gerenciar riscos de segurança é uma das atividades mais importantes em um SDLC seguro e, de fato, é o driver para as atividades subsequentes. Os riscos de segurança, por sua vez, direcionam as outras atividades de engenharia de segurança, as atividades de gerenciamento de projetos e as atividades de garantia de segurança. O risco também é coberto em outras áreas do site Build Security In.

Outros temas comuns incluem métricas de segurança e redução geral de defeitos como atributos de um processo SDLC seguro. O restante deste documento fornece visões gerais de modelos, processos e métodos de processo que suportam uma ou mais das quatro áreas de foco. As visões gerais devem ser lidas no seguinte contexto:

  • As organizações precisam definir processos organizacionais. Para fazer isso, eles usam padrões de processo e também consideram os costumes do setor, os requisitos regulatórios, as demandas dos clientes e a cultura corporativa.
  • Projetos individuais aplicam os processos organizacionais, geralmente com adaptação adequada. Ao aplicar os processos organizacionais a um projeto específico, o projeto seleciona as atividades SDLC apropriadas.
  • Os projetos usam práticas apropriadas de identificação de riscos de segurança, engenharia de segurança e garantia de segurança ao realizarem seu trabalho.
  • As organizações precisam avaliar a eficácia e a maturidade de seus processos, conforme usadas. Eles também precisam executar avaliações de segurança.

Modelos de Maturidade de Capacidade

Os modelos de maturidade de capacidade fornecem um modelo de referência de práticas maduras para uma disciplina de engenharia especificada. Uma organização pode comparar suas práticas com o modelo para identificar áreas potenciais de melhoria. Os CMMs fornecem definições no nível da meta e principais atributos de processos específicos (engenharia de software, engenharia de sistemas, engenharia de segurança), mas geralmente não fornecem orientação operacional para a execução do trabalho. Em outras palavras, eles não definem processos, definem características do processo; eles definem o quê, mas não o como. “As avaliações baseadas no CMM não têm como objetivo substituir a avaliação do produto ou a certificação do sistema. Em vez disso, as avaliações organizacionais visam focar os esforços de melhoria de processos nas fraquezas identificadas em áreas específicas do processo ”[ Redwine 04 ].

Historicamente, os CMMs enfatizam a maturidade do processo para atender às metas de negócios de melhor gerenciamento de cronograma, melhor gerenciamento de qualidade e redução da taxa geral de defeitos em software. Das quatro áreas de foco seguras do processo SDLC mencionadas anteriormente, os CMMs geralmente tratam de processos organizacionais e de gerenciamento de projetos e processos de garantia. Eles não abordam especificamente atividades de engenharia de segurança ou gerenciamento de riscos de segurança. Eles também se concentram na redução geral de defeitos, não especificamente na redução de vulnerabilidades. É importante observar, pois muitos defeitos não estão relacionados à segurança e algumas vulnerabilidades de segurança não são causadas por defeitos de software. Um exemplo de vulnerabilidade de segurança não causada por defeitos comuns de software é o código malicioso adicionado intencionalmente.

Dos três CMMs atualmente amplamente utilizados, o CMMI (Capability Maturity Model Integration), o Federal Aviation Administration integrou o Capability Maturity Model (FAA-iCMM) e o Systems Security Engineering Capability Maturity Model (SSE-CMM), apenas o SSE- O CMM foi desenvolvido especificamente para tratar da segurança. O Trusted CMM, derivado da Trusted Software Methodology, também é de importância histórica.

CMMI (Capability Maturity Model Integration)

A CMMI (Capability Maturity Model Integration) ajuda as organizações a aumentar a maturidade de seus processos para melhorar o desempenho dos negócios a longo prazo. Existem três constelações diferentes do CMMI: CMMI para aquisição (CMMI-ACQ), CMMI para serviços (CMMI-ACQ) e CMMI para desenvolvimento (CMMI-DEV). Em dezembro de 2005, o Software Engineering Institute (SEI) relatou que 1.106 organizações e 4.771 projetos relataram resultados de avaliações baseadas no CMMI. Em novembro de 2010, todas as três constelações do CMMI foram atualizadas para a versão 1.3.

O CMMI-ACQ fornece orientações de melhoria para as organizações de aquisição para iniciar e gerenciar a aquisição de produtos e serviços. O CMMI-SVC fornece orientação de melhoria para as organizações de provedores de serviços para estabelecer, gerenciar e fornecer serviços.

O CMMI-DEV fornece as melhores práticas mais recentes para desenvolvimento, manutenção e aquisição de produtos e serviços, incluindo mecanismos para ajudar as organizações a melhorar seus processos e fornece critérios para avaliar a capacidade do processo e a maturidade do processo. As áreas de melhoria cobertas por este modelo incluem engenharia de sistemas, engenharia de software, desenvolvimento integrado de produtos e processos, fornecimento de fornecedores e aquisição. O CMMI-DEV está em uso há muitos anos, substituindo seu antecessor, o Capability Maturity Model for Software ou Software CMM (SW-CMM), que está em uso desde meados da década de 1980.

O CMMI-DEV aborda quatro categorias para melhoria e avaliação de processos. Cada categoria inclui várias áreas de processo. Como pode ser visto na Figura 1, O CMMI-DEV aborda gerenciamento de projetos, gerenciamento de fornecedores, treinamento e aprimoramento de processos no nível da organização, garantia de qualidade, medição e práticas de engenharia. No entanto, ele não trata especificamente das quatro áreas mencionadas anteriormente (gerenciamento de riscos de segurança, práticas de engenharia de segurança, garantia de segurança e processos de projeto/organização para segurança). Embora não seja razoável supor que tudo isso possa ser tratado como casos especiais de práticas já abordadas pelo CMMI-DEV, metas e práticas adicionais para tornar a garantia explícita estão em desenvolvimento por meio de uma parceria da Booz Allen Hamilton, Motorola e Lockheed Martin . O progresso desse esforço pode ser encontrado no grupo de trabalho sobre processos e práticaspágina no site da Central de Informações e Recursos da Comunidade Software Assurance. Mais informações sobre o CMMI estão disponíveis no site do SEI.

Figura 1. Áreas de processo do CMMI- DEV

Figura 1. Áreas de processo do CMMI-DEV

Modelo de Maturidade de Capacidade integrado da Federal Aviation Administration (FAA-iCMM)

O FAA-iCMM é amplamente utilizado na Administração Federal de Aviação. O FAA-iCMM fornece um modelo único de melhores práticas para aprimoramento em toda a empresa, incluindo terceirização e gerenciamento de fornecedores. A versão mais recente inclui áreas de processo para abordar gerenciamento corporativo integrado, gerenciamento de informações, implantação/transição/descarte e operação/suporte. O FAA-iCMM integra os seguintes padrões e modelos: ISO 9001: 2000, EIA/IS 731, Prêmio Nacional de Qualidade Malcolm Baldrige e critérios do Prêmio Presidente de Qualidade, CMMI-SE/SW/IPPD e CMMI-A, ISO/IEC TR 15504, ISO/IEC 12207 e ISO/IEC CD 15288.

O FAA-iCMM foi organizado nas três categorias e 23 Áreas de Processo mostradas na Figura 2 . O FAA-iCMM trata do gerenciamento de projetos, gerenciamento de riscos, gerenciamento de fornecedores, gerenciamento de informações, gerenciamento de configurações, design e teste, todos integrantes de um SDLC seguro. No entanto, o FAA-iCMM não trata da segurança especificamente em nenhuma dessas áreas. Assim como no CMMI, o FAA-iCMM inclui um conjunto genérico de melhores práticas que não abordam especificamente questões de segurança. Um documento de referência (PDF) com ponteiros para os detalhes sobre o modelo e cada área de processo está disponível.

Figura 2. Áreas de processo do FAA-iCMM

Figura 2. Áreas de processo do FAA-iCMM

Para abordar lacunas na cobertura de segurança, algumas organizações da FAA e do Departamento de Defesa (DoD) patrocinaram um esforço conjunto para identificar as melhores práticas de segurança e proteção para uso em conjunto com a FAA-iCMM. A extensão proposta de Segurança e proteção ao FAA-iCMM identifica práticas baseadas em padrões que devem ser usadas como critério para orientar a melhoria do processo e avaliar os recursos de uma organização para fornecer produtos e serviços seguros e protegidos.

As adições de segurança propostas incluem os seguintes quatro objetivos e dezesseis práticas:

Objetivo 1 – Uma infraestrutura de segurança e proteção é estabelecida e mantida.

  1. Garantir segurança, conscientização, orientação e competência.
  2. Estabeleça e mantenha um ambiente de trabalho qualificado que atenda às necessidades de segurança.
  3. Garanta a integridade das informações, fornecendo armazenamento e proteção e controlando o acesso e a distribuição das informações.
  4. Monitorar, relatar e analisar incidentes de segurança e proteção e identificar possíveis ações corretivas.
  5. Planeje e preveja a continuidade das atividades com contingências para ameaças e perigos para as operações e a infraestrutura.

Meta 2 – Os riscos de segurança e proteção são identificados e gerenciados.

  1. Identifique riscos e fontes de riscos atribuíveis a vulnerabilidades, ameaças à segurança e riscos à segurança.
  2. Para cada risco associado à segurança, determine os fatores causais, estime a consequência e a probabilidade de uma ocorrência e determine a prioridade relativa.
  3. Para cada risco associado à segurança, determine, implemente e monitore o plano de mitigação de riscos para atingir um nível aceitável de risco.

Objetivo 3 – Os requisitos de segurança e proteção são atendidos.

  1. Identifique e documente os requisitos regulamentares, leis, normas, políticas e níveis aceitáveis ​​de segurança.
  2. Estabeleça e mantenha requisitos de segurança e proteção, incluindo níveis de integridade, e projete o produto ou serviço para atendê-los.
  3. Objetivamente, verifique e valide produtos de trabalho e produtos e serviços fornecidos para garantir que os requisitos de segurança foram alcançados e cumpram o uso pretendido.
  4. Estabelecer e manter argumentos de segurança e garantia de segurança e evidências de suporte ao longo do ciclo de vida.

Meta 4 – Atividades e produtos são gerenciados para atingir requisitos e objetivos de segurança.

  1. Estabelecer e manter relatórios independentes de segurança e status e problemas de segurança.
  2. Estabelecer e manter um plano para alcançar os requisitos e objetivos de segurança e proteção.
  3. Selecione e gerencie produtos e fornecedores usando critérios de segurança e proteção.
  4. Avalie, monitore e analise as atividades de segurança em relação aos planos, controle de produtos, tome ações corretivas e melhore os processos.

Mais informações sobre segurança e extensões de segurança desenvolvidas para este modelo estão disponíveis em [ Ibrahim 04 ].

CMM Confiável/Metodologia de Software Confiável (T-CMM, TSM)

No início dos anos 90, a então Strategic Defense Initiative (SDI) desenvolveu um processo chamado “Metodologia de Desenvolvimento de Software Confiável”, posteriormente renomeado para “Metodologia de Software Confiável (TSM)”. Esse modelo definiu níveis de confiança, com níveis mais baixos de ênfase enfatizando a resistência a vulnerabilidades não intencionais e níveis mais altos de confiança, adicionando processos para combater desenvolvedores mal-intencionados. A SDI realizou experimentos com o TSM para determinar se esses processos poderiam ser implementados praticamente e qual seria o impacto desses processos (especialmente no custo e no cronograma). O TSM foi posteriormente harmonizado com o CMM, produzindo o Trusted CMM (T-CMM) [ Kitson 95 ]. Embora o TCMM/TSM não seja amplamente usado hoje em dia, continua sendo uma fonte de informações sobre processos para o desenvolvimento de software seguro.

Modelo de maturidade de capacidade de engenharia de segurança de sistemas (SSE-CMM)

“O SSE-CMM ® é um modelo de processo que pode ser usado para melhorar e avaliar a capacidade de engenharia de segurança de uma organização. O SSE-CMM fornece uma estrutura abrangente para avaliar as práticas de engenharia de segurança em relação aos princípios de engenharia de segurança geralmente aceitos. Ao definir essa estrutura, o SSE-CMM fornece uma maneira de medir e melhorar o desempenho na aplicação dos princípios de engenharia de segurança. O SSE-CMM agora é o padrão ISO/IEC 21827 e a versão 3 já está disponível. Mais informações sobre o modelo estão disponíveis em http://www.sse-cmm.org [ Redwine 04 ].

O objetivo declarado para o desenvolvimento do modelo é que, embora o campo da engenharia de segurança possua vários princípios geralmente aceitos, falta uma estrutura abrangente para avaliar as práticas de engenharia de segurança em relação aos princípios. O SSE-CMM, definindo essa estrutura, fornece uma maneira de medir e melhorar o desempenho na aplicação dos princípios de engenharia de segurança. O SSE-CMM também descreve as características essenciais dos processos de engenharia de segurança de uma organização.

O modelo está organizado em duas grandes áreas: (1) Engenharia de Segurança e (2) Projeto e processos organizacionais. A Engenharia de Segurança, por sua vez, é organizada em Processos de Engenharia, Processos de Garantia e Processos de Risco. Existem 22 áreas de processo distribuídas entre as três organizações. Cada área de processo é composta por um conjunto relacionado de metas e atividades de processo.

O SEE-CMM foi revisado pela última vez em 2005. O modelo tornou-se um padrão ISO em 2008. A Associação Internacional de Engenharia de Segurança de Sistemas ( ISSEA ) mantém o SSE-CMM.

Figura 3. Áreas de processo do SSE-CMM

Figura 3. Áreas de processo do SSE-CMM

Ciclo de vida de desenvolvimento de segurança de computação confiável da Microsoft

O Ciclo de vida do desenvolvimento de segurança da computação confiável (ou SDL) é um processo que a Microsoft adotou para o desenvolvimento de software que precisa suportar ataques de segurança [ Lipner 05] O processo adiciona uma série de atividades e produtos com foco em segurança a cada fase do processo de desenvolvimento de software da Microsoft. Essas atividades e produtos de segurança incluem a definição de requisitos de recursos de segurança e atividades de garantia durante a fase de requisitos, modelagem de ameaças para identificação de riscos de segurança durante a fase de design de software, o uso de ferramentas de análise de código de análise estática e revisões de código durante a implementação e testes focados na segurança , incluindo o teste Fuzz, durante a fase de teste. Uma pressão extra de segurança inclui uma revisão final do código, tanto do código novo quanto do legado, durante a fase de verificação. Por fim, durante a fase de lançamento, uma revisão final de segurança é conduzida pela equipe Central Microsoft Security,

A Microsoft aumentou o SDL com treinamento de segurança obrigatório para sua equipe de desenvolvimento de software, com métricas de segurança e com os conhecimentos de segurança disponíveis através da equipe Central de Segurança da Microsoft. A Microsoft está relatando resultados encorajadores de produtos desenvolvidos usando o SDL, medidos pelo número de boletins de segurança críticos e importantes emitidos pela Microsoft para um produto após seu lançamento.

O livro intitulado The Security Development Lifecycle [ Howard 06 ] expande ainda mais as informações sobre SDL a partir do artigo mencionado acima. Ênfase é dada à abordagem que uma organização deve usar para a adoção efetiva do SDL. O compromisso do gerenciamento com a segurança aprimorada do produto é essencial. Além de treinar desenvolvedores e projetar e construir o produto com segurança apropriada, o SDL incorpora o planejamento de falhas de segurança após o lançamento, para que a organização esteja pronta para corrigir rapidamente problemas imprevistos. O SDL é articulado como um processo de 12 etapas, da seguinte maneira:

Etapa 0: Educação e conscientização

Etapa 1: Início do Projeto

Etapa 2: Definir e seguir as práticas recomendadas de design

Etapa 3: Avaliação de risco do produto

Etapa 4: Análise de Risco

Etapa 5: Criando documentos de segurança, ferramentas e práticas recomendadas para clientes

Etapa 6: Políticas de codificação segura

Etapa 7: Políticas de teste seguras

Etapa 8: o impulso da segurança

Etapa 9: A revisão final da segurança

Etapa 10: Planejamento da resposta de segurança

Etapa 11: liberação do produto

Etapa 12: Execução da resposta de segurança

Processo de software de equipe para desenvolvimento seguro de software (TSP)

Processo de Software de Equipe (TSP) do Software Engineering Institute (SEI) fornece uma estrutura, um conjunto de processos e métodos disciplinados para aplicar os princípios de engenharia de software no nível da equipe e individual. O software produzido com o TSP tem uma ou duas ordens de magnitude a menos de defeitos do que o software produzido com as práticas atuais – ou seja, 0 a 0,1 defeitos por mil linhas de código, em oposição a 1 a 2 defeitos por mil linhas de código.

O TSP para desenvolvimento seguro de software (TSP-Secure) estende o TSP para se concentrar mais diretamente na segurança dos aplicativos de software. O projeto TSP-Secure é um esforço conjunto da iniciativa TSP do SEI e do programa CERT do SEI. O principal objetivo do projeto é desenvolver um método baseado em TSP que possa produzir previsivelmente software seguro. O TSP-Secure aborda o desenvolvimento seguro de software de três maneiras. Primeiro, como o software seguro não é construído por acidente, o TSP-Secure aborda o planejamento de segurança. Além disso, como as pressões de cronograma e os problemas com as pessoas atrapalham a implementação das melhores práticas, o TSP-Secure ajuda a criar equipes de desenvolvimento autodirigidas e a colocar essas equipes no comando de seu próprio trabalho. Segundo, como segurança e qualidade estão intimamente relacionadas, o TSP-Secure ajuda a gerenciar a qualidade durante todo o ciclo de vida de desenvolvimento do produto. Finalmente,

As equipes que usam o TSP-Secure criam seus próprios planos. O planejamento inicial é realizado em uma série de reuniões denominadas lançamento do projeto, que ocorre durante um período de três a quatro dias. O lançamento é liderado por um treinador de equipe qualificado. Em um lançamento do TSP-Secure, a equipe alcança um entendimento comum das metas de segurança para o trabalho e a abordagem adotada para realizar o trabalho, produz um plano detalhado para orientar o trabalho e obtém suporte de gerenciamento para o plano. As tarefas típicas incluídas no plano são identificar riscos de segurança, identificar e definir requisitos de segurança, design seguro, design seguro e revisões de código e uso de ferramentas de análise estática, testes de unidade e testes de fuzz. (O teste do Fuzz envolve o envio de entradas aleatórias para interfaces de programas externas durante o teste de caixa preta.Fuzz 06 , Michael 05 ]).

Cada membro da equipe de uma equipe TSP-Secure seleciona pelo menos uma das nove funções padrão de membro da equipe (as funções podem ser compartilhadas). Uma das funções definidas é uma função do Security Manager. O Security Manager lidera a equipe para garantir que os requisitos, o design, a implementação, as revisões e os testes do produto abordem a segurança; garantir que o produto seja estaticamente e dinamicamente garantido; fornecendo análises oportunas e alertas sobre problemas de segurança; e rastrear quaisquer riscos ou problemas de segurança até o fechamento. O gerente de segurança trabalha com especialistas em segurança externa quando necessário.

Após o lançamento, a equipe executa seu plano e garante que todas as atividades relacionadas à segurança estejam ocorrendo. O status de segurança é apresentado e discutido durante cada briefing de status de gerenciamento.

Visitas a sites como a lista das 20 principais vulnerabilidades de segurança do SANS Institute, o site MITRE Common Vulnerabilities and Exposures (CVE), o site US-CERT Technical Cyber ​​Security Alerts e o site Microsoft Security Advisory mostram que defeitos comuns de software são os principal causa de vulnerabilidades de segurança (estouros de buffer foram o defeito de software mais comum que levou a vulnerabilidades de segurança) [ Microsoft 06 , MITRE 06 , SANS 05 , US-CERT 05] Portanto, a estratégia de gerenciamento da qualidade TSP-Secure é ter vários pontos de remoção de defeitos no ciclo de vida de desenvolvimento de software. Quanto mais pontos de remoção de defeitos houver, maior será a probabilidade de encontrar problemas logo após a introdução, permitindo que os problemas sejam corrigidos com mais facilidade e a causa raiz seja mais facilmente determinada e tratada.

Cada atividade de remoção de defeitos pode ser pensada como um filtro que remove uma porcentagem de defeitos que podem levar a vulnerabilidades do produto de software (consulte a Figura 4 ). Quanto mais filtros de remoção de defeitos houver no ciclo de vida de desenvolvimento de software, menos defeitos que podem levar a vulnerabilidades permanecerão no produto de software quando ele for lançado. Mais importante, a medição precoce de defeitos permite que a organização tome medidas corretivas no início do ciclo de vida de desenvolvimento de software.

Figura 4. Filtros de remoção de vulnerabilidade

 Figura 4. Filtros de remoção de vulnerabilidade

Cada vez que os defeitos são removidos, eles são medidos. Todo ponto de remoção de defeitos se torna um ponto de medição. A medição de defeitos leva a algo ainda mais importante do que a remoção e prevenção de defeitos: informa às equipes onde elas se posicionam contra seus objetivos, ajuda-as a decidir se deve avançar para a próxima etapa ou parar e tomar medidas corretivas e indica onde fixar seu processo. cumprir seus objetivos.

A equipe considera as seguintes perguntas ao gerenciar defeitos:

  • Que tipo de defeitos levam a vulnerabilidades de segurança?
  • Onde, no ciclo de vida de desenvolvimento de software, os defeitos devem ser medidos?
  • Quais produtos de trabalho devem ser examinados quanto a defeitos?
  • Quais ferramentas e métodos devem ser usados ​​para medir os defeitos?
  • Quantos defeitos podem ser removidos em cada etapa?
  • Quantos defeitos estimados permanecem após cada etapa de remoção?

O TSP-Secure inclui treinamento para desenvolvedores, gerentes e outros membros da equipe.

Correção por construção

A metodologia de correção por construção da Praxis High Integrity Systems é um processo para o desenvolvimento de software de alta integridade [ Hall 02 ]. Ele foi usado para desenvolver sistemas críticos e críticos para a segurança com um grande grau de sucesso [ Ross 05 ]. Ele fornece software com taxas de defeitos muito baixas, eliminando rigorosamente os defeitos no estágio mais inicial possível do processo. O processo é baseado nos seguintes princípios: não introduza erros em primeiro lugar e remova os erros o mais próximo possível do ponto em que foram introduzidos.

O processo é baseado na forte convicção de que cada etapa deve servir a um propósito claro e ser realizada usando as técnicas mais rigorosas disponíveis para resolver esse problema específico. Em particular, o processo quase sempre usa métodos formais para especificar propriedades comportamentais, de segurança e proteção do software. Há uma crença de que somente usando a formalidade a precisão necessária pode ser alcançada.

Os sete princípios fundamentais da correção pela construção são

  1. Espere que os requisitos sejam alterados. Os requisitos de mudança são gerenciados adotando uma abordagem incremental e prestando maior atenção ao design para acomodar as mudanças. Aplique mais rigor, em vez de menos, para evitar retrabalhos dispendiosos e desnecessários.
  2. Saiba por que você está testando. Reconheça que existem duas formas distintas de teste, uma para criar o software correto (depuração) e outra para mostrar que o software criado está correto (verificação). Essas duas formas de teste requerem duas abordagens muito diferentes.
  3. Elimine erros antes do teste. Melhor ainda, implante técnicas que dificultem a introdução de erros em primeiro lugar. O teste é a segunda maneira mais cara de encontrar erros. O mais caro é permitir que seus clientes os encontrem para você.
  4. Escreva um software fácil de verificar. Caso contrário, a verificação e a validação (incluindo testes) podem levar até 60% do esforço total. A codificação normalmente leva apenas 10%. Mesmo dobrando o esforço de codificação valerá a pena se reduzir o ônus da verificação em menos de 20%.
  5. Desenvolva de forma incremental. Faça alterações muito pequenas, incrementalmente. Após cada alteração, verifique se o sistema atualizado se comporta de acordo com sua especificação atualizada. Fazer pequenas alterações facilita a verificação do software.
  6. Alguns aspectos do desenvolvimento de software são simplesmente difíceis. Não há bala de prata. Não espere que nenhuma ferramenta ou método facilite tudo. As melhores ferramentas e métodos cuidam dos problemas fáceis, permitindo que você se concentre nos problemas difíceis.
  7. O software não é útil por si só. O software executável é apenas parte da imagem. É inútil sem manuais do usuário, processos de negócios, documentação de design, código fonte bem comentado e casos de teste. Estes devem ser produzidos como uma parte intrínseca do desenvolvimento, e não adicionados no final. Em particular, reconheça que a documentação de design serve a dois propósitos distintos:
    1. Permitir que os desenvolvedores passem de um conjunto de requisitos para uma implementação. Grande parte desse tipo de documentação sobrevive à sua utilidade após a implementação.
    2. Permitir que os mantenedores entendam como a implementação atende aos requisitos. Um documento destinado aos mantenedores é muito mais curto, mais barato de produzir e mais útil do que um documento de design tradicional.

A correção pela construção é um dos poucos processos SDLC seguros que incorporam métodos formais em muitas atividades de desenvolvimento. Onde apropriado, linguagens formais de especificação como Z são usadas para especificar comportamento funcional e propriedades de segurança. A linguagem de programação SPARK (um subconjunto de Ada projetado por contrato) é frequentemente usada para facilitar a verificação estática profunda e construtiva. Mais detalhes sobre essa abordagem estão disponíveis no artigo BSI Correctness by Construction .

Métodos Ágeis

Nos últimos anos, uma nova família de métodos de engenharia de software começou a ganhar aceitação entre a comunidade de desenvolvimento de software. Esses métodos, chamados coletivamente Agile Methods, estão em conformidade com o Agile Manifesto [ Agile 01 ], que declara:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo isso e ajudando outras pessoas a fazê-lo. Através deste trabalho, chegamos ao valor:

Indivíduos e interações em processos e ferramentas
Software de trabalho em documentação abrangente
Colaboração do cliente em negociação de contratos
Respondendo a mudanças ao seguir um plano

Ou seja, enquanto houver valor nos itens à direita, valorizamos mais os itens à esquerda. ”

Os métodos Agile individuais incluem Programação Extrema (a mais conhecida), Scrum, Desenvolvimento de Software Lean, Metodologias de Cristal, Desenvolvimento Orientado a Recursos e Metodologia de Desenvolvimento de Sistemas Dinâmicos. Embora existam muitas diferenças entre essas metodologias, elas se baseiam em alguns princípios comuns, como iterações curtas de desenvolvimento, design mínimo inicial, design e arquitetura emergentes, propriedade coletiva do código e capacidade de qualquer pessoa alterar qualquer parte do código, comunicação direta e documentação mínima ou inexistente (o código é a documentação) e construção gradual de casos de teste. Algumas dessas práticas estão em conflito direto com os processos SDLC seguros. Por exemplo,

No artigo “Towards Agile Security Assurance”, Beznosov e Kruchten abordam esse problema e fazem algumas propostas sobre como as atividades de garantia de segurança podem ser mescladas aos métodos de desenvolvimento Agile [ Beznosov 05 ]. Eles criaram uma tabela que mostra a compatibilidade de atividades comuns de garantia de segurança com métodos Agile. A Tabela 1 (replicada aqui com permissão dos autores) mostra que quase 50% das atividades tradicionais de garantia de segurança não são compatíveis com os métodos Agile (12 de 26), menos de 10% são ajustes naturais (2 de 26), cerca de 30 % são independentes do método de desenvolvimento e pouco mais de 10% (4 de 26) podem ser semi-automatizados e, assim, integrados mais facilmente aos métodos Agile.

Tabela 1. Compatibilidade de métodos ágeis com práticas de garantia de segurança

Método ou técnica de garantia de segurança

Partida (2)

Independente (8)

Semi-automático (4)

Incompatibilidade (12)

Exigências

Diretrizes

 

X

 

 

Análise de Especificação

 

 

 

X

Reveja

 

 

 

X

Projeto

Aplicação de abordagens arquitetônicas específicas X

 

X

 

 

Uso de princípios de design seguro

 

X

 

 

Validação formal

 

 

 

X

Validação informal

 

 

 

X

Revisão interna

X

 

 

 

Revisão externa

 

 

 

X

Implementação

Rastreabilidade de requisitos informais

 

 

 

X

Teste de requisitos

 

 

X

 

Validação informal

 

 

 

X

Validação formal

 

 

 

X

Teste de segurança

 

 

X

 

Teste de vulnerabilidade e penetração

 

 

X

 

Análise de profundidade de teste

 

 

 

X

Análise estática de segurança

 

 

X

 

Linguagens e ferramentas de programação de alto nível

 

X

 

 

Adesão aos padrões de implementação

 

X

 

 

Uso do controle de versão e rastreamento de alterações

 

X

 

 

Alterar autorização

 

 

 

X

Procedimentos de integração

 

X

 

 

Uso de ferramentas de geração de produtos

 

X

 

 

Revisão interna

X

 

 

 

Revisão externa

 

 

 

X

Avaliação de segurança

 

 

 

X

Outros começaram a explorar a integração da garantia de segurança com os Métodos Ágeis [ Beznosov 04 , Poppendieck 02 , Wayrynen 04 ].

O Fórum de Segurança Agile foi iniciado em 2005 para fornecer um ponto focal para a colaboração em todo o setor. Informações adicionais sobre o Fórum, bem como outros documentos que abordam as abordagens de segurança adotadas em conjunto com o Agile, estão disponíveis no site do Fórum .

Os critérios comuns

Canadá, França, Alemanha, Holanda, Reino Unido e Estados Unidos lançaram um padrão de avaliação de segurança desenvolvido em janeiro de 1996. Esse padrão é conhecido como “Critérios Comuns para Avaliação de Segurança da Tecnologia da Informação” (CCITSE), mas é mais frequentemente referido como “Critérios comuns” (CC) [ CC 05 ]. O CC se tornou a estrutura de avaliação de segurança dominante e agora é um padrão internacional, ISO/IEC 15408.

O CC está documentado em três seções. A seção de introdução descreve o histórico, o objetivo e os conceitos e princípios gerais da avaliação de segurança e descreve o modelo de avaliação. A segunda seção descreve um conjunto de requisitos funcionais de segurança que os usuários dos produtos podem querer especificar e que servem como modelos padrão para os requisitos funcionais de segurança. Os requisitos funcionais são catalogados e classificados, basicamente fornecendo um menu de requisitos funcionais de segurança que os usuários do produto podem selecionar. A terceira seção do documento inclui requisitos de garantia de segurança, que incluem vários métodos para garantir que um produto seja seguro. Esta seção também define sete conjuntos predefinidos de requisitos de garantia chamados Níveis de Garantia da Avaliação (EALs).

Existem dois artefatos que devem ser criados para passar por uma avaliação de CC: um Perfil de Proteção (PP) e um Destino de Segurança (ST). Ambos os documentos devem ser criados com base em modelos específicos fornecidos no CC. Um Perfil de proteção identifica as propriedades de segurança desejadas (requisitos de segurança do usuário) de um tipo de produto. Os perfis de proteção geralmente podem ser criados selecionando componentes apropriados na seção dois do CC, pois as chances são de que os requisitos do usuário para o tipo de produto que está sendo construído já existem. Os perfis de proteção são uma declaração de necessidades de segurança independente da implementação para um tipo de produto (por exemplo, firewalls). Os perfis de proteção podem incluir os requisitos funcionais e de garantia para o tipo de produto. Um destino de segurança (ST) é uma declaração de necessidades de segurança dependente da implementação para um produto específico.

Os perfis de proteção e o destino de segurança permitem o seguinte processo de avaliação

  1. Uma organização que deseja adquirir ou desenvolver um tipo específico de produto de segurança define suas necessidades de segurança usando um Perfil de proteção. A organização então avalia o PP e o publica.
  2. Um desenvolvedor de produto pega esse perfil de proteção, grava um alvo de segurança que está em conformidade com o PP e tem esse alvo de segurança avaliado.
  3. O desenvolvedor do produto cria um TOE (ou usa um existente) e o avalia com o Destino de Segurança.

Os sete níveis de avaliação são

  1. Nível 1 de garantia de avaliação (EAL1) – funcionalmente testado
  2. Nível 2 de garantia de avaliação (EAL2) – estruturalmente testado
  3. Nível 3 de garantia da avaliação (EAL3) – metodicamente testado e verificado
  4. Nível 4 de garantia da avaliação (EAL4) – metodicamente projetado, testado e revisado
  5. Nível 5 de garantia da avaliação (EAL5) – projetado e testado semi-formalmente
  6. Nível de garantia de avaliação 6 (EAL6) – projeto semi-formalmente verificado e testado
  7. Nível de garantia de avaliação 7 (EAL7) – projeto formalmente verificado e testado

O Esquema Comum de Avaliação e Validação de Critérios (CCEVS) é administrado nos Estados Unidos pelo Instituto Nacional de Padrões e Tecnologia (NIST) e pela Agência de Segurança Nacional (NSA) sob a Parceria Nacional de Garantia da Informação (NIAP). Uma lista de produtos validados e seu nível de EAL associado é mantida atualizada no site do CCEVS .

Os Critérios Comuns são um padrão reconhecido internacionalmente. Informações sobre os grupos de trabalho e produtos verificados internacionalmente estão disponíveis no site do Common Criteria .

Modelo de Maturidade do Software Assurance

Uma versão beta do Software Assurance Maturity Model (SAMM) foi lançada em agosto de 2008 e a versão oficial 1.0 foi lançada em março de 2009. Esse modelo foi desenvolvido para ajudar as organizações a formular e implementar uma estratégia de segurança de software. É mantido por meio do Projeto OpenSAMM como parte do Projeto de Segurança de Aplicativos Web Abertos (OWASP). Esse modelo foi projetado para ser personalizado para o ambiente de risco específico que cada organização enfrenta. Os recursos disponíveis para este modelo [ Chandra 09b ] foram projetados para ajudar no seguinte:

  • avaliação do programa de segurança de software existente de uma organização
  • desenvolvimento de um programa de segurança de software balanceado usando iterações bem definidas
  • demonstração de melhoria de um programa de garantia de segurança
  • definição e medição de atividades relacionadas à segurança dentro de uma organização

O SAMM é um projeto aberto que fornece conteúdo disponível gratuitamente e que não é específico do fornecedor.

O modelo concentra-se em quatro funções principais de negócios envolvidas no desenvolvimento de software:

  • Governança: processos e atividades relacionadas à maneira pela qual uma organização gerencia seu desenvolvimento de software
  • Construção: processos e atividades relacionadas à maneira como uma organização define as metas e a criação de software nos projetos de desenvolvimento
  • Verificação: processos e atividades relacionadas à maneira como uma organização valida e testa artefatos criados ao longo do desenvolvimento de software
  • Implantação: processos e atividades relacionadas à maneira como uma organização gerencia a liberação operacional do software que cria para um ambiente de tempo de execução

As áreas de prática específicas em cada função de negócio estão listadas na Tabela 2. Uma estrutura de nível de maturidade foi identificada para cada prática da seguinte maneira:

  • Nível de maturidade 0: ponto de partida onde as atividades na prática não são realizadas em grande parte
  • Nível de maturidade 1: as atividades e os processos da área de atuação são entendidos em uma extensão inicial, mas o cumprimento é ad hoc
  • Nível de maturidade 2: pratique a eficiência e/ou a eficácia está aumentando
  • Nível de maturidade 3: as atividades e os processos da área de atuação são abrangentes, indicando o domínio em larga escala da área

Tabela 2. Estrutura SAMM

Governança

Construção

Verificação

Desdobramento, desenvolvimento

Estratégia e Métricas

Avaliação de ameaça

Revisão do projeto

Gerenciamento de vulnerabilidades

Política e conformidade

Requisitos de segurança

Revisão de código

Endurecimento do ambiente

Educação e Orientação

Arquitetura segura

Teste de segurança

Capacitação Operacional

Neste momento, o modelo é novo demais para ter relatado resultados de uso.

Estrutura de segurança de software

O Citigal e o Fortify fizeram parceria para desenvolver o Software Security Framework (SSF). A estrutura do SSF foi inicialmente construída com base no conteúdo do SAMM e ajustada com base na revisão do desenvolvimento em um conjunto de organizações que abordam o desenvolvimento seguro [ Chandra 09a ]. Os autores do SSF articularam um Modelo de Segurança da Construção na Maturidade (BSIMM), com base na análise de projetos em um conjunto de organizações [ Chess 09 ].

A tabela 3 mostra a estrutura do SSF. Existem doze práticas organizadas em quatro domínios. Os domínios são

  • Governança: práticas que ajudam a organizar, gerenciar e medir uma iniciativa de segurança de software
  • Inteligência: práticas para coletar conhecimento corporativo usado na realização de atividades de segurança de software em toda a organização
  • Touchpoints SDL : práticas associadas à análise e garantia de determinados artefatos e processos de desenvolvimento de software
  • Implantação: práticas vinculadas às organizações de segurança de rede e manutenção de software

Tabela 3. Domínios e áreas de prática do SSF

Governança

Inteligência

Touchpoints SDL

Desdobramento, desenvolvimento

Estratégia e Métricas

Modelos de ataque

Análise de Arquitetura

Teste de penetração

Conformidade e Política

Recursos e design de segurança

Revisão de código

Ambiente de Software

Treinamento

Padrões e Requisitos

Teste de segurança

Gerenciamento de configuração e
gerenciamento de vulnerabilidades

As áreas de atuação agrupam 110 atividades que foram identificadas em uso real nas nove organizações estudadas para desenvolver o SSF, embora nem todas tenham sido usadas em uma organização. Nove atividades foram consistentemente relatadas em todas as organizações estudadas. Eles estão listados na Tabela 4 [ Xadrez 09 ].

Tabela 4. Atividades abordadas em todas as organizações revisadas pelo SSF

o que

Quão

Construir suporte organizacional

Criar função de evangelismo relacionada à segurança/marketing interno

Estabelecer uma abordagem unificada para atender às necessidades regulatórias e de suporte ao cliente

Criar diretiva relacionada à segurança

Promover uma cultura organizacional de segurança

Fornecer treinamento de conscientização de segurança

Descrever os problemas de segurança específicos da organização

Criar/usar conteúdo específico para o histórico da empresa

Crie orientações de segurança através de uma articulação dos recursos de segurança de um produto

Crie e publique informações detalhadas sobre os recursos de segurança (autenticação, gerenciamento de funções, gerenciamento de chaves, auditoria/log, criptografia, protocolos)

Estabelecer capacidade organizacional na arquitetura de segurança

Os especialistas em arquitetura de segurança lideram as análises de funcionalidade de arquitetura e produto

Avalie a perspectiva do invasor

Incorporar ferramentas de segurança de caixa preta no processo de revisão da qualidade

Identificar áreas problemáticas específicas da organização

Aplicar testes de caneta usando especialistas externos

Garanta uma sólida infraestrutura de segurança para desenvolvimento e validação de software

Desenvolva e teste usando a segurança apropriada de host/rede

Sumário

Outros padrões e métodos importantes que se aplicam ao desenvolvimento de software seguro, mas que não foram resumidos nesta nota técnica, incluem:

  • ISO/IEC 15288 para processos de ciclo de vida do sistema, disponível em http://www.iso.org
  • ISO/IEC 12207 para processos de ciclo de vida de software, disponível em http://www.iso.org
  • ISO/IEC 15026 para níveis de integridade de sistema e software, disponível em http://www.iso.org
  • Engenharia de software para salas limpas [ Linger 94 , Mills 87 ]

Em conclusão, esta pesquisa dos processos SDLC existentes mostra que vários processos e metodologias que são amplamente utilizados por muitos anos podem oferecer suporte ao desenvolvimento seguro de software. No entanto, eles não foram projetados especificamente para lidar com a segurança do software desde o início. Um dos principais obstáculos para instituir uma consideração abrangente da segurança no SDLC foi a disponibilidade de conhecimentos de segurança para o desenvolvedor, conforme observado por Lipner na descrição dos primeiros passos da Microsoft ao instituir a Iniciativa de Computação Confiável [ Lipner 05 ]. Quatro anos depois, uma pesquisa da Forrester encomendada pela Veracode indica que a maioria das organizações (57%) ainda não fornece treinamento de segurança para desenvolvedores [ Veracode 09 ].

O SSE-CMM, o CMM confiável, o FAA-iCMM, os critérios comuns, a correção pela construção e o TSP Secure ofereceram maneiras de abordar a segurança no desenvolvimento, mas exigiam recursos com conhecimento de segurança no grupo de melhoria de processos ou que uma organização adotasse um desenvolvimento diferente e mais rigoroso aproximação. Poucas organizações estavam dispostas a adotar essas mudanças.

O SDL da Trustworthy Computing da Microsoft foi o primeiro de um novo grupo de abordagens de ciclo de vida que busca articular os elementos críticos de segurança a serem incorporados a qualquer ciclo de vida de desenvolvimento existente, de modo que a segurança seja considerada adequadamente como parte do desenvolvimento normal. A Microsoft está relatando 60% menos vulnerabilidades em seus sistemas operacionais lançadas em 2008 do que em 2002 [ Mills 09 ].

O lançamento da Versão 1 do Modelo de Maturidade do Software Assurance e os relatórios são o uso do SSF em nove organizações, indicando um novo nível de conscientização sobre o valor da incorporação da segurança no SDLC. As organizações estão mostrando maior resposta à segurança, mas ainda há um longo caminho a percorrer antes que as considerações de segurança no SDLC possam ser consideradas comuns. A pesquisa da Veracode indicou que 34% das organizações incluídas na pesquisa abordam ativamente a segurança no SDLC, mas apenas 13% conhecem a qualidade da segurança de seu código comercial [ Veracode 09 ].

Referências

[Agile 01]

Agile Alliance. Manifesto for Agile Software Development (2005).

[Beznosov 04]

Beznosov, Konstantin. “Extreme Security Engineering: On Employing XP Practices to Achieve ‘Good Enough Security’ without Defining It.” First ACM Workshop on Business Driven Security Engineering (BizSec). Fairfax, VA, Oct. 31, 2003.

[Beznosov 05]

Beznosov, Konstantin & Kruchten, Phillipe. “Towards Agile Security Assurance,” 47–54. Proceedings of the 2004 Workshop on New Security Paradigms. White Point Beach Resort, Nova Scotia, Canada, September 20-23, 2004. New York, NY: Association for Computing Machinery, 2005.

[CC 05]

The Common Criteria Portal (2005).

[Chandra 09a]

Chandra, Pravir. “What’s up with the other model?” OpenSAMM, March 6, 2009.

[Chandra 09b]

Chandra, Pravir. “Software Assurance Maturity Model,” Version 1.0. http://www.opensamm.org

[Chess 09]

Chess, B., McGraw, G., & Migues, S. “Confessions of a Software Security Alchemist.” InformIT, March 16, 2009.

[CNSS 06]

Committee on National Security Systems. National Information Assurance Glossary (CNSS Instruction No. 4009), June 2006.

[Fuzz 06]

University of Wisconsin Madison. Fuzz Testing of Application Reliability (2006).

[Goldenson 03]

Goldenson, D. & Gibson, D. Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results (CMU/SEI-2003-SR-009, ADA418491). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.

[Hall 02]

Hall, Anthony & Chapman, Roderick. “Correctness by Construction: Developing a Commercial Secure System.” IEEE Software 19, 1 (Jan./Feb. 2002): 18-25.

[Herbsleb 94]

Herbsleb, J., Carleton, A., Rozum, J., Siegel, J., & Zubrow, D. Benefits of CMM-Based Software Process Improvement: Initial Results (CMU/SEI-94-TR-013, ADA283848). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1994.

[Howard 06]

Howard, Michael & Lipner, Steve. The Security Development Lifecycle. Microsoft Press, 2006.

[Ibrahim 04]

Ibrahim, L. et al. Safety and Security Extensions for Integrated Capability Maturity Models. United States Federal Aviation Administration, 2004.

[IEEE 90]

IEEE Standards Coordinating Committee. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990). Los Alamitos, CA: IEEE Computer Society, 1990 (ISBN 0738103918 ).

[Kitson 95]

Kitson, David H. “A Tailoring of the CMM for the Trusted Software Domain.” Proceedings of the Seventh Annual Software Technology Conference. Salt Lake City, Utah, April 9-14, 1995.

[Linger 94]

Linger, R. C. “Cleanroom Process Model.” IEEE Software 11, 2 (March 1994): 50-58.

[Lipner 05]

Lipner, Steve & Howard, Michael. The Trustworthy Computing Security Development Lifecycle (2005).

[Michael 05]

Michael, C. C. & Radosevich, Will. Black Box Security Testing Tools (2005).

[Microsoft 06]

Microsoft Corp. Microsoft Security Advisories (2006).

[Mills 87]

Mills, H., Dyer, M., & Linger, R. C. “Cleanroom Software Engineering.” IEEE Software 4, 5 (September 1987): 19-25.

[Mills 09]

Mills, E. “Secure Software? Experts Say it’s no Longer a Pipe Dream.” CNET News, April 20, 2009.

[MITRE 06]

The MITRE Corporation. Common Vulnerabilities and Exposures.

[NASA]

NASA Software Assurance Technology Center. Software Assurance Guidebook, NASA-GB-A201.

[Paulk 93]

Paulk, M., Curtis, B., Chrissis, M. B. & Weber, C. Capability Maturity Model for Software (Version 1.1) (CMU/SEI-93-TR-024, ADA263403). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.

[Poppendieck 02]

Poppendieck, M. & Morsicato, R. “Using XP for Safety-Critical Software.” Cutter IT Journal 15, 9 (2002): 12-16.

[Redwine 04]

Redwine, S. T. & Davis, N., eds. “Processes to Produce Secure Software.” Improving Security Across the Software Development Lifecycle (National Cybersecurity Partnership Taskforce Report), Appendix B. http://www.cyberpartnership.org/init-soft.html (2004).

[Ross 05]

Ross, Philip E. “The Exterminators: A Small British Firm Shows That Software Bugs Aren’t Inevitable.” IEEE Spectrum 42, 9 (September 2005): 36-41.

[SANS 05]

The SANS Institute. The Twenty Most Critical Internet Security Vulnerabilities (Updated) – The Experts Consensus (2005).

[SEI 09]

Software Engineering Institute. Maturity Profile, 2009.

[US-CERT 05]

United States Computer Emergency Readiness Team. Technical Cyber Security Alerts (2005).

[Veracode 09]

Veracode. “Independent Survey Finds Enterprises At-Risk from Insecure Software.” April 19, 2009.

[Wäyrynen 04]

Wäyrynen, J., Bodén, M., & Boström, G. “Security Engineering and eXtreme Programming: an Impossible Marriage?” Extreme Programming and Agile Methods – XP/Agile Universe 2004: 4th Conference on Extreme Programming and Agile Methods. Calgary, Canada, August 15-18, 2004. Berlin, Germany: Springer-Verlag, 2004 (ISBN 3-540-22839-X).

 

 

  • 1.Parte do conteúdo deste artigo é usada com permissão do relatório do Software Engineering Institute CMU/SEI-2005-TN-024.
  • 2. OCMM, o Capability Maturity Model e o CMMI são registrados no Instituto de Marcas e Patentes dos EUA pela Carnegie Mellon University.
  • 3.Team Software Process e TSP são marcas de serviço da Carnegie Mellon University.

Copyright © Carnegie Mellon University 2005-2012.

This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission.  Permission is required for any other use.  Requests for permission should be directed to the Software Engineering Institute at [email protected].

The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.

NO WARRANTY

THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

Pt-BR

Direitos autorais © Carnegie Mellon University 2005-2012.

Este material pode ser reproduzido na íntegra, sem modificação, e distribuído gratuitamente em formato escrito ou eletrônico, sem a solicitação formal de permissão. É necessária permissão para qualquer outro uso. Os pedidos de permissão devem ser direcionados ao Software Engineering Institute em [email protected] .

O portal Build Security In (BSI) é patrocinado pelo Departamento de Segurança Interna dos EUA (DHS), Divisão Nacional de Segurança Cibernética. O Software Engineering Institute (SEI) desenvolve e opera o BSI. O financiamento do DHS suporta a publicação de todo o conteúdo do site.

SEM GARANTIA

ESTE MATERIAL DA UNIVERSIDADE CARNEGIE MELLON E SEU INSTITUTO DE ENGENHARIA DE SOFTWARE É FORNECIDO “COMO ESTÁ”. A UNIVERSIDADE CARNEGIE MELLON NÃO OFERECE GARANTIAS DE QUALQUER TIPO, EXPRESSAS OU IMPLÍCITAS, A QUALQUER QUESTÃO INCLUÍDA, MAS NÃO LIMITADA, ADEQUAÇÃO A OBJETIVOS OU COMERCIALIZAÇÃO, EXCLUSIVIDADE OU RESULTADOS OBTIDOS COM O USO DO MATERIAL A CARNEGIE MELLON UNIVERSITY NÃO OFERECE QUALQUER GARANTIA DE QUALQUER TIPO COM RESPEITO À LIBERDADE DE PATENTE, MARCA REGISTRADA OU INFRAÇÃO DE DIREITOS AUTORAIS.

Traduzido de: https://www.us-cert.gov/bsi/articles/knowledge/sdlc-process/secure-software-development-life-cycle-processes

Curso - Engenharia Reversa na Forense Digital

Aqui você compreenderá a utilização da Engenharia Reversa aplicada em Forense Digital, bem como a Análise de Malware.

O curso aborda diversos conceitos de forma prática. O estudo é baseado, em sua maioria, no .NET e .NET Core, pois é uma tecnologia que está sempre em evolução, sendo adicionada inclusive em Linux e MAC, ou seja, com o .NET Core, agora é multiplataforma.

Analisando este ambiente, podemos entender que é de extrema importância e urgente necessidade aprender a dissecar malwares desenvolvidos em alguma linguagem do .NET e .NET Core, com C#, VB, etc…