segunda-feira, 29 de outubro de 2012

Requisitos de Segurança de Software


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.



terça-feira, 2 de outubro de 2012

Common Criteria como Fonte de Conteúdo para Logging


O Commom Criteria (CC) ou ISO 15408 continua sendo a principal referencia para certificação de segurança de sistemas. Eu particularmente não penso que essa referência auxilie muito quando se trata de segurança de aplicações. 

Ouso dizer que o OWASP Top 10 sozinho fez e faz muito mais diferença para comunidade de desenvolvimento de software que deseja mudar a realidade de suas aplicações em termos de segurança. Se considerarmos outros ativos da OWASP como os cheat sheets, ASVS, Test Guide a disputa passa a ser covardia. Penso que o CC esteja mais alinhado com outro modelo o SSE-CMM, que se tornou um ilustre desconhecido para a comunidade de segurança em SDLC. 

Mas mesmo que no todo o CC se revele inapropriado para appsec, seus controles continuam sendo muito pertinentes e podem inspirar em muito a discussão sobre oportunidades de melhoria de segurança. Para ilustrar essa minha impressão, resolvi mapear eventos que o CC recomenda que sejam monitorados pelo serviço de logging, que compartilho a seguir:

  • Ações empreendidas pela aplicação em decorrência de violações de segurança. 
  • Ativação ou desativação de mecanismos de análise de auditoria. A aplicação pode ser instrumentalizada com mecanismo que analisem ostensivamente seu comportamento, na tentativa de reconhecer ações suspeitas. Tais mecanismos podem variar de um conjunto de regras fixas de eventos suspeitos até heurísticas avançadas que revele ações suspeitas pela correção de múltiplos eventos associados a cenários de ataque. 
  • Os eventos devem estar relacionados a identidade do usuário, para que a responsabilização pela execução do evento seja garantida.
  • Ações empreendidas pela aplicação quando ao exceder os limites relacionados ao armazenamento de registros (ex. rotação de arquivo por data, dimensão do arquivo).
  • Ações empreendidas pela aplicação em decorrência de falha do receptor dos registros de logging.
  • Requisições bem sucedidas de operação em objetos sensíveis da aplicação.
  • Todas as requisições de operação em objetos sensíveis da aplicação.
  • Os atributos de segurança usados para verificação do direito de acesso a objetos sensíveis.
  • Verificações bem sucedidas de autenticidade de informação consumida pela aplicação.
  • Todas as verificações de autenticidade de informação consumida pela aplicação.
  • Execução com sucesso de rotinas de exportação de dados da aplicação.
  • Todos os tipos de execução de rotinas de exportação de dados da aplicação.
  • Superação do limite estabelecido pelas tentativas de autenticação, a ação decorrente (ex.  bloqueio da senha), e restauração do estado normal (ex. desbloqueio da senha).
  • Rejeição de segredo fornecido a aplicação (ex. senha, frase).
  • Rejeição e aceite de segredo fornecido a aplicação (ex. senha, frase).
  • Mudança nas métricas de qualidade de segredos.
  • Uso mal sucedido de determinado mecanismo de autenticação
  • Todos os usos do mecanismo de autenticação
  • Tentativa mal sucedida de associar os atributos de segurança de determinada identidade ao respectivo sujeito (ex. criação do sujeito).
  • Tentativa mal ou bem sucedida de associar os atributos de segurança de determinada identidade ao respectivo sujeito (ex. sucesso ou falha na criação do sujeito).
  • Uso de mecanismo de anonimização de sessão.
  • Rejeição de nova sessão ou suspensão de sessão ativa em decorrência da superação do número máximo de sessões concorrentes.
  • Suspensão da sessão do usuário em decorrência de período de inatividade superior ao permitido.
  • Início de sessão do usuário.

Como pode ser observado, o CC sugere eventos muito interessantes a serem monitorados pelo serviço de logging. Considerando que uma das atividades mais complexas do projeto de logging é a definição dos eventos que ameaçam a aplicação, e por consequência serão monitorados pelo serviço, essa lista não pode ser ignorada. Ainda, a sua simples existência revela o potencial do modelo CC, como fonte de pesquisa para controles de segurança.

terça-feira, 24 de julho de 2012

OWASP Brasília


Há quase 1 ano, registrei neste post as minhas impressões sobre a realidade da segurança de aplicações na perspectiva da conscientização do desenvolvedor no mercado de Brasília. Na ocasião, em mais de 180 desenvolvedores treinados em segurança de software, NENHUM havia ouvido falar na OWASP, e alguns tinham visto o termo XSS em alguma manchete de TI.

Na oportunidade, joguei luz sobre algumas questões inerentes a liderança de um Capítulo da OWASP que poderiam não estar na ordem do dia de algum líder.

Infelizmente neste ano que se passou, nada mudou na condução do Capítulo Brasília da OWASP, apesar de ter havido nesse ínterim a mudança da liderança. Muito provavelmente, os desenvolvedores continuam ignorando a existência da OWASP, bem como das técnicas que poderiam impor mais dificuldade aos atacantes aí fora.

Convictos dessa realidade adversa e dos desafios para liderar um Capítulo da OWASP e disseminar a segurança de aplicação, resolvemos (@Klaubert, @Br3n0S1lv4, @DiogoRispoli e eu) reativar o Capítulo Brasília.

Compartilho com vocês essa novidade e peço a sua ajuda para disseminar a segurança de aplicação na capital federal. 

Como você pode ajudar? Sua organização possui equipe de desenvolvimento de software? Organize um evento interno ou externo que trate do tema segurança de aplicação. A OWASP Brasília levará o palestrante. Segue uma lista de palestras pré-definidas para facilitar.

### Palestras ###

OWASP Top 10
O OWASP Top 10 é um projeto desenvolvido pela OWASP com o objetivo de disseminar o conhecimento sobre os 10 maiores riscos de segurança que as aplicações web estão suscetíveis. Nesta palestra apresentaremos a metodologia usada para classificar tais riscos, os detalhes relativos aos 10 maiores riscos e suas vulnerabilidades e os respectivos controles para dificultar a sua exploração.

Codificação Defensiva
Seria impossível ensinar para um motorista todas as possibilidades de acidentes que ele poderia vivenciar antes dele assumir o volante pela primeira vez, dado a infinita combinação de cenários que poderiam decorrer em um sinistro. Apesar disso, uma abordagem bastante usada é a direção defensiva, pela qual o motorista aprenda técnicas curinga que poderiam ser aplicadas a um conjunto de situações de risco. A codificação defensiva, tema desta palestra, se baseia no mesmo princípio, preparando o desenvolvedor para instrumentar seu código para que a aplicação esteja preparada para se defender de diversos riscos, mesmo que o desenvolvedor não tenha o conhecimento detalhado sobre cada um deles.

OpenSAMM
Como nenhuma organização tem recursos ilimitados para investir em segurança de aplicações, necessariamente ela necessitará priorizar as ações que lhe deem o maior retorno. Esta palestra apresenta o modelo OpenSAMM, cujo objetivo é auxiliar as organizações a estruturar um programa de melhoria contínua do SDLC (ciclo de vida de desenvolvimento de software) para incorporar práticas de segurança mais apropriadas, considerando as suas particularidades.

ModSecurity: Firewall OpenSource para Aplicações Web (WAF)
Com a crescente complexidade e importância das aplicações web, prazos curtos para desenvolvimento, novas técnicas de ataque, regulações, busca por melhores práticas e a falta de atenção e/ou foco do desenvolvedor com a segurança, torna-se necessário adicionar uma nova camada de segurança para aplicações web, os "firewall de aplicações web" ou WAF's. Esta apresentação introduzirá os conceitos de WAF, e em especial o ModSecurity, Firewall OpenSource para Aplicações Web, uma poderosa ferramenta desenhada para entender e proteger as aplicações web nos seus mais variados tipos. Serão apresentadas suas funcionalidades, bem como ele pode ajudar no dia a dia de um site web, seja na monitoração, proteção ou mesmo na depuração das aplicações web. Também será apresentada o WAF-FLE, console open source para visualização de eventos para o ModSecurity

Usando protocol Hmac-Based para reduzir superfície de ataque.
Proteger uma aplicação web é uma tarefa que envolve uma estratégia de defesa em profundidade. Aplicações web possuem características como sua grande superfície de ataque, que favorecem os atacantes. Reduzir essa superfície não é uma tarefa fácil, porém importante para aumentar o nível de segurança desse tipo de aplicação. Nesta apresentação será descrito um protocolo baseado em um algoritmo criptográfico chamado HMAC que pode ser utilizado para proteger e reduzir significativamente a superfície de ataque de aplicações web, sem a necessidade de modificá-las. Durante a apresentação serão realizadas demonstrações de uma implementação do palestrante, open source e publicamente disponível.