ATPS - Desenvolvimento De Software Seguro

Etapa 1

Passo 2

Requisitos

Os requisitos de segurança de software são o conjunto de necessidades de segurança que o software deve atender, sendo tais necessidades influenciadas fortemente pela política de segurança da organização, e compreendendo aspectos funcionais e não-funcionais. Os aspectos funcionais descrevem comportamentos que viabilizam a criação ou a manutenção da segurança e, geralmente, podem ser testados diretamente. Na maioria dos casos, remetem a mecanismos de segurança como, por exemplo, controle de acesso baseado em papéis de usuários (administradores, usuários comuns, entre outros.), autenticação com o uso de credenciais (usuário e senha, certificados digitais, entre outros.), dentre outros. Os aspectos não funcionais descrevem procedimentos necessários para que o software permaneça executando suas funções adequadamente mesmo sob uso indevido. São exemplos de requisitos não funcionais: validação de dados de entrada e a registro eventos em log de auditoria com informações suficientes para análise forense.

A licitação de requisitos de segurança de software consiste na definição das necessidades de proteção exigidas pelo software. Tal atividade exige uma colaboração intensa entre os interessados no software, especialmente daqueles com visão negocial, que podem ter consciência das consequências no negócio decorrentes de incidentes de segurança, cujo vetor de ataque se localize no software. Algumas das técnicas mais usadas no levantamento de requisitos de segurança incluem:

 Brainstorming.

 Pesquisas de opinião (questionários e entrevistas).

 Decomposição da política.

 Classificação de dados.

 Matriz de objeto-sujeito.

 Modelagem de caso de uso e abuso.

Independente da técnica a ser usada, a licitação de requisitos exige que pelo menos um dos participantes na atividade tenha densidade em segurança de software, para que os luxos regulares que o software proverá ou já provêm sejam criticados, evidenciando maneiras de subvertê-los. A definição dos cenários negativos, cuja realização é indesejada, resultará no requisito de segurança.

Projeto / Análise

A prática final no desenvolvimento seguro é especialmente importante para projetos de Software Livre. A Operação Segura refere-se a todo o suporte que deve ser oferecido às aplicações e sistemas depois dos mesmos serem lançados e disponibilizados como uma “versão final”.

A operação segura não se refere apenas ao suporte comum dado em listas e fóruns de discussão mas também ao fornecimento de canais de comunicação específicos para problemas e soluções relacionados à segurança que vão surgir de acordo com a popularização do software.

O primeiro ponto que tem de se observar nesta estrutura de suporte é o como o projeto vai lidar com falhas de segurança descobertas (ou seja, na operação normal de um software já lançado). Muitos defendem mas existem alguns projetos que lidam com as vulnerabilidades em segredo até uma correção estar disponível. Outro ponto importante é a definição clara de como os avisos/relatórios que tratem de vulnerabilidades serão enviados e recebidos pelo projeto. É aconselhável que exista um canal rápido e conhecido pelo qual relatórios sobre novas vulnerabilidades possam ser enviados e tratados pela equipe responsável em tempo hábil, sem a necessidade de vigiar centenas de e-mails sobre suporte genéricos na lista de usuários.

Caso o projeto opte pelo Full Disclosure, os desenvolvedores tem de estar atentos à esta política e tomar as devidas precauções. Mesmo sem o Full Disclosure, os desenvolvedores tem de ter em mente que um especialista em segurança pode descobriruma falha simplesmente analisando atualizações no repositório de controle de versões. Correções ou formas de se remediar uma falha devem ser feitas públicas e amplamente conhecidas o mais rápido possível após a descoberta/publicação de uma falha.

Internamente, as falhas de segurança encontradas após o lançamento devem realimentar o processo de análise de risco para que este possa se concentrar nas áreas próximas a onde a falha foi encontrada, no intuito de conferir a efetividade das correções e o possível aparecimento de problemas decorrentes de novo código adicionado muitas vezes as pressas.

Implementação e Teste

Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada no cliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste ser usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o teste no mesmo momento que o projeto, num processo contínuo até o fim do projeto.

Em contrapartida, algumas práticas emergentes como a programação extrema e o desenvolvimento ágil focam o modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro (TDD), por engenheiros de software. Antes da implementação da unidade em questão, o teste falha. Então o código é escrito, passando incremental mente em porções maiores dos casos de teste. Os testes são mantidos junto com o resto do código fonte do software, e geralmente também integra o processo de construção do software.

Manutenção

Manutenção é o processo de melhoria e otimização de um software já desenvolvido (versão de produção), como também reparo de defeitos. A manutenção do software é uma das fases do processo de desenvolvimento de software, e ocorre a seguir a entrada do software em produção. Esta fase envolve:

 Mudanças no software para corrigir defeitos e deficiências que foram encontrados durante a utilização pelo usuário novas funcionalidades e para melhorar a aplicabilidade e usabilidade do software.

A manutenção do software envolve inúmeras técnicas específicas. Uma das técnicas é separação estática, a qual é usada para identificar todos os códigos de programa que são afetados por alguma variável. Isto é geralmente útil em programas de refatoração de código que foram especialmente útil em assegurar preparação para bug do milênio.

A fase de manutenção de software é uma parte explicita do modelo em cascata do processo de desenvolvimento de