Segurança: Fator Determinante para A Qualidade de Software

Abstract

The increasing occurrence of security failures in software products alerts for the low quality of developed software. However, information security has a larger scope that can combine different quality aspects. A solution for this tendency of failures is to include activities usually applied in information security in a software development process. Therefore, this work proposes a process to deal software security quality: the Software Development Secure Process. Resumo. A crescente incidência de falhas de segurança decorrentes de problemas nos produtos de software alerta para a baixa qualidade do software desenvolvido. Contudo, a segurança da informação tem um escopo maior que pode combinar diversos aspectos de qualidade. Uma solução para essa tendência de falhas é incluir atividades normalmente aplicadas em segurança da informação no processo de desenvolvimento de software. Logo, este trabalho propõe um processo para tratar a qualidade da segurança de software: o Processo Seguro de Desenvolvimento de Software. 1. Introdução Falhas de segurança em software são um dos principais problemas enfrentados pelos profissionais de segurança [CERT 2005]. Esta realidade tende a crescer, uma vez que muitas empresas ainda não perceberam o quão é importante agregar princípios de segurança em seus processos de desenvolvimento de software. Todavia, a especialização de atividades de um processo de desenvolvimento voltadas para produzir software mais seguro ainda está em fase de maturação no que se refere aos problemas de segurança dos sistemas. O processo CLASP (2005), por exemplo, é uma iniciativa que objetiva aplicar a segurança dentro do processo de desenvolvimento de software. A segurança da informação discorre e orienta sobre a melhor forma de aumentar a proteção das informações manipuladas por produtos de software. Não obstante, não se pode deduzir que um software ao implementar algoritmos de criptografia para proteger a integridade dos dados pode ser considerado seguro. Na verdade, esse software apenas implementa uma característica de segurança, não podendo, de fato, ser considerado seguro. A criptografia, por exemplo, não protege o software contra ataques de sobrecarga de memória (buffer overflow). A segurança de software não pode ser confundida com software seguro, isto é, funcionalidades e características de segurança em um software não representam que o software seja seguro [McGraw 2004]. Este trabalho objetiva contribuir para a construção de software seguro e, por conseguinte, software de maior qualidade, por meio da aplicação do Processo Seguro de VI Simpósio Brasileiro de Qualidade de Software 266 Desenvolvimento de Software (PSDS) organizado a partir do SSE-CMM (2003), do OCTAVE [Alberts et al. 2001], da ISO/IEC 15408 (2005a, 2005b, 2005c), e da ISO/IEC 17799 (2005). Este trabalho está organizado como se segue. A seção 2 descreve padrões e normas de segurança utilizadas para estruturar as atividades do processo seguro proposto. A seção 3 apresenta uma visão geral do Processo Seguro de Desenvolvimento de Software. A seção 4 discorre sobre a aplicação do processo seguro. A seção 5 apresenta as principais conclusões deste trabalho. 2. Padrões e Normas de Segurança da Informação O ISSEA (International Systems Security Engineering Association) (2003) estendeu o CMM (Capability Maturity Model) [Paulk et al. 1993] para o SSE-CMM (System Security Engineering – Capability Maturity Model) (2003). A versão anterior do SSECMM foi adaptada para se tornar a norma ISO/IEC 21827 (2002). O SSE-CMM objetiva garantir a segurança de um sistema fornecendo formas de traduzir as necessidades de segurança do cliente em um processo de segurança, que gere produtos que satisfaçam tais necessidades. O OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) [Alberts et al. 2001] é uma técnica estratégica de planejamento e avaliação baseada em riscos para segurança. Aspectos relacionados aos riscos (ativos, ameaças, vulnerabilidades, e impacto organizacional) são tratados, permitindo que uma organização ajuste a estratégia de proteção de seus riscos de segurança. Os requisitos do OCTAVE são agrupados em um conjunto de critérios. Neste ponto, dois métodos consistentes com os critérios foram desenvolvidos: o OCTAVE e OCTAVE-S. O Método OCTAVE foi projetado para ser aplicado em grandes organizações. O Método OCTAVE-S é voltado para pequenas organizações. A ISO/IEC 15408 (Evaluation criteria for Information Technology security) (2005a, 2005b, 2005c) propõe um conjunto de critérios para avaliar a segurança de produtos de tecnologia da informação. A ISO/IEC 15408 deriva-se do Common Criteria (2005). Tanto o Common Criteria quanto a ISO/IEC 15408 apresentam um conjunto de requisitos que devem ser atendidos para atingir níveis de segurança nos sistemas. Os requisitos se dividem em: requisitos funcionais de segurança, e requisitos de garantia da segurança. Os primeiros requisitos atuam como um conjunto mínimo de características de segurança que um software poderia implementar e envolvem desde a privacidade até a auditoria. Os requisitos de garantia operam como ações a serem realizadas em apoio ao desenvolvimento, para validar e certificar que o software seja seguro por ter conduzido tais ações (requisitos de garantia), que envolvem: Suporte ao ciclo de vida, Testes, Gerência de configuração, e Entrega e operação do produto, etc. A ISO/IEC 17799 (2005) objetiva preservar a confidencialidade, a integridade e a disponibilidade das informações, através da implementação de controles. Afirma ser essencial para uma organização identificar seus requisitos de segurança. Isto pode ser conseguido pela avaliação de risco dos ativos através da análise das ameaças, das vulnerabilidades, da probabilidade da ameaça se concretizar, além do impacto dessa ameaça na organização. VI Simpósio Brasileiro de Qualidade de Software 267 3. Processo Seguro de Desenvolvimento de Software A partir dos padrões e das normas apresentados na seção anterior, tendo como principal referência o SSE-CMM (2003), foram identificados um conjunto de macroatividades e atividades que passaram a compor o processo proposto: Processo Seguro de Desenvolvimento de Software (PSDS). O PSDS (Figura 1) foi elaborado inicialmente tendo como base o ciclo de vida iterativo incremental. Para a utilização de outros ciclos de vida, isto precisaria ser validado. Este processo é constituído de 37 atividades agrupadas em 11 macroatividades de segurança. As macroatividades e suas atividades elencadas representam uma proposta não exaustiva. A idéia é que cada atividade se adeque às etapas do ciclo de vida de software e que seja aplicada em paralelo com essas etapas. Neste contexto, é recomendável especializar o processo proposto para a organização que o utilizar, segundo suas necessidades e peculiaridades. Assim sendo, é possível utilizar apenas um subconjunto das macroatividades e ou das atividades propostas, adaptá-las e ou incluir novas macroatividades ou atividades específicas. O PSDS apresenta dois papéis que apóiam a execução do processo: o Engenheiro de segurança, e o Auditor de segurança. O Engenheiro de segurança é responsável pela especialização, e instanciação do processo seguro segundo os objetivos do projeto, alinhado com metas e planos da organização, e verificando se os projetos satisfazem seus objetivos de segurança. O Auditor de segurança avalia a aderência do processo seguro nos projetos de software, em termos de resultados das atividades, dos artefatos produzidos, verificando a conformidade das ações dos projetos ao processo estabelecido. Ele valida a eficaz aplicação do processo seguro, podendo reportar-se aos principais envolvidos através de um canal de comunicação independente, para relatar e tratar de não conformidades identificadas. Preferencialmente, o auditor de segurança não deve acumular as responsabilidades do papel desempenhado pela equipe de garantia da qualidade. As 11 macroatividades do PSDS serão descritas a seguir. 3.1 Planejar segurança O propósito dessa macroatividade é garantir que as informações necessárias para o planejamento da segurança para o projeto sejam estabelecidas e registradas. Devem ser elaborados (ou refinados) os objetivos e o plano de segurança da informação para a organização, e ser constituída a equipe de segurança (quando da instanciação do processo seguro). Essa macroatividade é composta pelas seguintes atividades: (i) Desenvolver plano de segurança; (ii) Planejar ambientes de processamento; e (iii) Planejar o gerenciamento de incidentes de segurança. VI Simpósio Brasileiro de Qualidade de Software 268 Figura 1. Processo seguro de desenvolvimento de software VI Simpósio Brasileiro de Qualidade de Software 269 3.2 Avaliar vulnerabilidade de segurança O propósito dessa macroatividade é identificar e caracterizar (na iteração) vulnerabilidades de segurança do software relacionadas com o ambiente definido. É intrínseco dessa macroatividade definir vulnerabilidades específicas para artefatos críticos gerados ao longo do processo de desenvolvimento, fornecendo uma avaliação geral de vulnerabilidade do software. Pela execução de métodos de identificação de vulnerabilidades, os atores envolvidos no processo obtêm uma lista detalhada de vulnerabilidades, que serão em seguida avaliadas. Essa macroatividade é composta pelas seguintes atividades: (i) Identificar vulnerabilidades de segurança; e (ii) Analisar as vulnerabilidades de segurança identificadas. 3.3 Modelar ameaça de segurança O propósito dessa macroatividade é identificar e caracterizar ameaças de segurança com suas propriedades e características, a partir das vulnerabilidades resultantes da macroatividade anterior. Uma ameaça pode ser definida como um evento que possa comprometer o funcionamento habitual do software, impactando em seus objetivos em vários níveis. A modelagem de ameaças pode ser usada para identificar ameaças e guiar decisões de projeto (incluindo artefatos críticos pro