ATPS ETAPA 1 SOFTWARE SEGURO

1.

O desenvolvimento de software seguro é composto por alguns princípios eficazes, fazendo com que o sistema que será desenvolvido, seja autossuficiente seguro contra vulnerabilidade à qualquer tipo de ataque, oponentes humanos, etc.

Essa segurança está relacionada ao sentido de preservar valores particulares ou organizacionais.

São características básicas de segurança da informação os atributo de confidencialidade, integridade, disponibilidade, autenticidade e autorização, não estando esta segurança restrita somente a sistemas computacionais, informações eletrônicas ou sistemas de armazenamento.

Independente da técnica a ser usada, a análise 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