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 elicitaçã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 elicitação de requisitos exige que pelo menos um dos participantes na atividade tenha densidade em segurança de software, para que os fluxos 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. Segue, a título de ilustração, alguns exemplos de requisitos de segurança, retirados do livro Official (ISC)2 guide to the CSSLP by Mano Paul
Confidencialidade
- Senha e outros campos de entrada de dados sensíveis necessitam ser mascarados.
- Senhas não devem ser armazenadas as claras nos sistemas backend, e quando armazenadas devem passar por processo de hash com uma função pelo menos equivalente a SHA-256.
- Transport Layer Security (TLS) como Secure Socket Layer (SSL) deve ser colocado em prática para proteger contra ameaças internas de Man in the Middle (MITM) para todas as informações de cartão de crédito que seja transmitida.
- O uso de protocolos reconhecidamente inseguros como, por exemplo, File Transfer Protocol (FTP) para transmitir credenciais de contas em texto claro a terceiros fora de sua organização deve ser proibido.
- Arquivos de log não devem armazenar qualquer informação sensível como definido pelo negócio, de modo que seja compreensível por seres humanos.
Integridade
- Todos os formulários de entrada e query strings necessitam ser validadas frente a um conjunto de entradas aceitáveis, antes do software aceita-los para processamento.
- O software a ser publicado deve ser disponibilizado juntamente com o checksum e a função hash usada pra computar o checksum, de modo que o interessado possa validar sua precisão e completude.
- Todos os personagens não humanos como um sistema ou processos batch devem ser identificados, monitorados e impedidos de alteração de dados, a medida que ele passa no sistema que eles rodam, a não ser que explicitamente autorizado para tal.
Disponibilidade
- O software deve oferecer alta disponibilidade de oito (8) noves (9), como definido pelo SLA.
- O software deve estar preparado para atender capacidade máxima de 300 usuários simultâneos.
- O software e seus dados devem ser replicados por todos os centros de dados para prover balanceamento de carga e redundância.
- A funcionalidade de missão crítica no software deve ser restaurada a operação normal no prazo de 1 hora de descontinuidade; funcionalidade de missão essencial no software deve ser restaurada a operação normal no prazo de 4 horas da interrupção, e funcionalidade de missão suporte no software deve ser restaurada a operação normal no prazo de 24 horas.
Autenticação
- O software será implantado somente na Intranet e o usuário autenticado deve fornecer novamente suas credenciais para acessar a aplicação, uma vez que esteja autenticado na rede.
- O software deverá suportar single sign on a terceiros e fornecedores que estão definidos na lista de interessados.
- A política de autenticação garante a necessidade para dois – ou autenticação com múltiplos fatores para todos os softwares de processamento financeiro.
Autorização
- O acesso a arquivos secretos de alta sensibilidade deve ser restrito somente a usuários com níveis de permissão secreto e super-secreto.
- Os usuários não devem ser demandados a enviar suas credenciais sempre, uma vez que ele tenha se autenticado com sucesso.
- Todos os usuários autenticados herdarão a permissão de leitura somente que são parte do papel do usuário convidado enquanto os usuários autenticados por padrão terão permissão de leitura e escrita como parte do papel de usuário regular. Somente os usuários com acesso administrativo, terão todos os direitos dos usuários regulares, adicionalmente a execução de operações.
Auditing and Logging
- Todas as tentativas de logon devem ser registradas juntamente com o timestamp e o endereço de IP de origem da requisição.
- Os valores anterior e posterior a uma mudança de preço modificado por um usuário, quando da atualização de um preço por um usuário, devem ser monitorados com os seguintes campos auditados: identidade, ação, objeto e timestamp.
- Os logs de auditoria devem sempre ser adicionados de novos registros e nunca sobrescritos.
- Os logs de auditoria devem ser mantidos de forma segura por um período de 3 anos.
- Gerenciamento de Sessão
- Cada atividade do usuário deverá ser rastreada de modo único.
- O software não deve solicitar as credenciais de acesso do usuário, uma vez que ele esteja autenticado no Internet Banking.
- As sessões devem ser explicitamente suspensas quando o usuário solicita o log off ou fecha a janela do browser.
- Identificadores de sessão usados para identificar a sessão de usuários devem não ser passados em claro ou ser facilmente adivinhado.
Erros e Gerenciamento de Exceção
- Todos os erros e exceções devem ser explicitamente manipulados a partir de blocos try, catch e finally.
- Mensagens de erro que são mostradas ao usuário revelarão somente a informação necessária, sem vazamento de detalhes internos do sistema na mensagem de erro.
- Detalhes de exceções de segurança devem ser auditados e monitorados periodicamente.
- Parâmetros de Configuração
- Os dados sensíveis do arquivo de configuração da aplicação web, como strings de conexão, devem ser encriptados .
- Senhas e chaves de criptografia não devem ser registradas no código fonte do software.
- A inicialização e a liberação de variáveis globais necessitam ser monitoradas com muito cuidado.
- Eventos de inicialização e interrupção de sessão devem incluir proteções na informação de configuração como uma salvaguarda contra ameaças de vazamento.
