requisitos de segurança
DESCRIPTION
Apresentação requisitos de segurança encontro OWASP de 20/08/13TRANSCRIPT
Requisitos de Segurança no Ciclo de Vida de Desenvolvimento
Palestrante:
Mauricio da Silva Marinho Administrador
Especialista em Análise de Sistemas Analista de TI no Núcleo de Riscos e Segurança de TI do BRB
Requisitos de Segurança
• Software sem requisitos: O Software falha!
• Software sem requisitos de segurança: A
organização falha!
• Consequências do software sem requisitos: o Baixa qualidade.
o Forte acoplamento.
o Retrabalho.
o Escopo indefinido.
o Custo elevado.
o Problemas de usabilidade.
o Objetivos não atendidos.
o Insatisfação do cliente.
o Vulnerável.
Requisitos de Segurança
• Consequências do software vulnerável.
Momentânea
Indisponibilidade
Comprometimento
Da Continuidade
Características do Software Seguro
• 3 Rs: o Reliability.
• O software funciona como esperado.
o Resiliency.
• O software não viola qualquer política de segurança e pode
resistir as ações de agentes ameaçadores.
o Recoverability.
• O software recupera-se diante de uma ameaça
materializada.
Impacto no Projeto
• Quase sempre requisitos de segurança não são
bem vistos por implicarem impacto nos três pilares
no projeto. Custo
Escopo Prazo
Pessoas
Fontes de Requisitos de Segurança no CDS
• Internas o Políticas
o Padrões
o Guias e Manuais
o Práticas e Procedimentos
• Externas o Regulações
o Conformidades
o Requisitos Geográficos
Requisitos de Segurança e Risco Residual Aceitável
Tipos de Requisitos de Segurança
Confiden-
cialidade Integridade
Disponi-
bilidade
Autenticação Autorização Responsa-
bilidade
Conceitos Chave de Segurança de Software
Requisitos são determinados para cada conceito-chave de segurança.
Organização, método científico e inferências.
Requisitos de Confidencialidade
Controles de
Confiden-
cialidade
Escrita
Secreta
Mascara-
mento
Em claro Obscura
Criptografia Hashing Estegano-
grafia
Marca
d’água
digital
Requisitos de Confidencialidade
Requisitos de confidencialidade precisam ser definidos ao longo
do ciclo de vida da informação, da origem do dado até sua
persistência ou descarte, considerando os seguintes estados:
• Em trânsito;
• Em processamento;
• Em storage (persistência);
Requisitos de confidencialidade podem ser limitados no tempo.
Requisitos de Confidencialidade
Informações pessoais de saúde
Entradas de senhas
Persistência de senhas
Proteção de MITM
Proteção de transferência de arquivos
Salva de logs
Mascaramento
Criptografia
Hashing
TLS
FTPS
Política
Requisitos de Integridade
• Requisitos que buscam garantir confiabilidade e
proteção contra modificações não autorizadas.
• Integridade de sistema o Funciona como esperado (projetado) – precisão.
o Modificações ocorrem apenas no cenário projetado de autorização (forma e responsabilidade).
• Integridade de dados o Os dados são preservados em seu ciclo de vida, permitindo alterações
apenas no cenário autorizado.
o Não permite possibilidades de inconsistências.
• Exemplo de violação de integridade: SQL Injection. o O sistema responde a requisições de modificação de dados em
desacordo ao originalmente projetado.
Requisitos de Integridade
• Requisitos de integridade precisam estar
explicitamente definidos nas especificações.
• Controles de segurança para confiabilidade: o Validação de entrada de dados.
o Checagem de paridade de bits (trânsito).
o Checagem de redundância cíclica (checksum – precisão e completude).
o Hashing (também atende a confidencialidade).
• Exemplos: o Todas as entradas querystring precisam ser validadas.
o Todo deploy deve acompanhar um checksum.
o Todos os atores não humanos precisam ser identificados e monitorados prevenindo o acesso quando não expressamente autorizado.
Requisitos de Disponibilidade
• Quase sempre requisitos associados às disciplinas de continuidade de negócio e recuperação de desastres.
• Vulnerabilidade causado por problemas no design e construção.
• Expõe o software a riscos de destruição de ambientes, perda de dados e interrupção de serviço (DoS).
• Devem ser explicitamente definidos na especificação. o MTD (Maximum Tolerable Downtime).
o RTO (Recovery Time Objective).
Requisitos de Disponibilidade
• Quase sempre requisitos associados às disciplinas de continuidade de negócio e recuperação de desastres.
• Vulnerabilidade causada por problemas no design e construção.
• Expõe o software a riscos de destruição de ambientes, perda de dados e interrupção de serviço (DoS).
• Devem ser explicitamente definidos na especificação (BIA, stress, performance test...). o MTD (Maximum Tolerable Downtime).
o RTO (Recovery Time Objective).
o SLA (explicitar o MTD e o RTO).
Requisitos de Disponibilidade
• BIA (Business Impact Analysis) o Deve ser utilizado para determinar o impacto do software no negócio.
o Deve ser mensurado quantitativamente (Ex: perda de receita por minuto de indisponibilidade).
o Deve considerar o custo para restaurar as operações ao estado original.
o Também deve ser determinado qualitativamente (perda de credibilidade, danos à imagem e à reputação).
• Construções inseguras de código (impacto na disponibilidade): o Ponteiros pendentes.
o Gerenciamento inadequado de memória (ciclo de vida dos objetos).
o Loop infinito.
o Requisição excessiva de coletores de lixo, e outras, devem ser identificadas e refatoradas.
• Especificar disponibilidade em casas de nove.
Requisitos de Autenticação
• São aqueles que reunem elementos para assegurar
a legitimidade e validade da identificação
apresentada pela entidade requisitante.
• Deve ocorrer sob diferentes fatores (Autenticação
multifator). o O quê você sabe.
o O quê você tem.
o O quê você é.
• Processos de autenticação precisam ser revisados
e colocados a prove para que sejam analisados
pela segurança de TI em busca de novos riscos
Requisitos de Autenticação
• Formas mais comuns de autenticação: o Anonymous
• Público
o Basic
• Envio das credenciais em texto claro ou Base 64.
o Digest
• Envia um hash do valor original (digest). Utiliza uma propriedade única do hardware como salt para calcular o hash.
o Integrated (NTLM)
• NT challange/response. Credenciais enviadas como um digest. Ex: autenticação standalone + Kerberos V5 (impersonation)
o Client certificates
• Autoridade certificadora confiável. Ex: Ecommerce, Egovernment...
o Formulários
• Dados sensíveis podem ser mascarados (shoulder surfing), mas as credenciais precisam ser transmitidas em canal criptografado.
Requisitos de Autenticação
• Formas mais comuns de autenticação (Cont.): o Token
• Geralmente utilizado em conjunto com formulários. Token enviado para o usuário que forneceu as credenciais.
o Smart cards
• Fator de autenticação propriedade (o quê você tem). Pode evitar o furto de credenciais
o Biometria
• Fator de autenticação característica (o quê você é). Características podem mudar!
• OBS: o One Time Dynamic Passwords (OTP) requerem fatores de conhecimento
e propriedade, dinamicamente modificando senhas e tokens. Ex: Ao informar as credenciais o usuário recebe um PIN dinâmico, em intervalos de segundos,em um device RFID.
Requisitos de Autenticação
• Erros de autenticação biométrica: o Erro tipo I - Falsa Rejeição (FRR – False Rejection Rate).
o Erro Tipo II - Falsa Aceitação (FAR – False Acceptence Rate).
FAR FRR
Crossover Error Rate
(CER) Utilizado para
avaliar diferentes
devices e tecnologias.
Baixo CER, maior
precisão.
ER
RO
S
PRECISÃO
Requisitos de Autenticação
• Exemplos de requisitos de
autenticação. o O software deve se restringir à intranet e o usuário não
precisa prover credenciais uma vez que já esteja
autenticado na rede.
o O software precisa suportar single sign on com terceiros.
o Usuários autenticados podem acessar Internet e intranet.
o A política de autenticação exige o uso de pelo menos
dois fatores de autenticação.
Requisitos de Autorização
• Relacionados aos privilégios de uma entidade
autenticada.
• Identificar sujeitos e objetos.
• Modelos de controle de acesso: o DAC – Discricionário
• transferência de privilégio, ACLs...
o NDAC – Não discricionário
• política de segurança imposta pelo sistema
o MAC – Mandatório
• restrição pela sensibilidade da informação no objeto. Requer rótulos de sensitividade para todos os objetos.
o RBAC – Baseado em Role
o Controle de Acesso Baseado em Recurso
• Quando a lista de usuários não é conhecida (Ex: SOA).
Requisitos de Autorização
• Princípio do privilégio mínimo.
• Hierarquia de roles.
Privilégio
Mínimo
Privilégio
Máximo
Convidado
Usuário
convidado + privilégios
de usuário
Administrador
Usuário + privilégios
de Administrador
Requisitos de Responsabilidade
• Auxiliam na construção do histórico das ações do
usuário.
• Trilhas de auditoria.
• Investigações forenses.
• Elementos: o Quem?
o O quê?
o Onde?
o Quando?
Requisitos de Responsabilidade
• Exemplos o Toda tentativa frustrada de logon deve ser registrada com timestamp
endereço IP de orígem.
o No update de preços, um snapshot antes e depois deve ser registrado com os seguintes campos auditáveis:
• Identidade;
• Ação;
• Objeto; e
• Timestamp.
o Logs de auditoria devem permitir append e nunca overwrite.
o Logs de auditoria devem ser retidos em segurança por 3 anos.
Elicitação de Necessidades de Proteção (PNE)
• Além de conhecer as fontes de requisitos, é
importante conhecer as técnicas de elicitação. o Brainstorming
o Questionários e entrevistas
o Decomposição política
o Classificação de dados
o Matriz sujeito-objeto
o Casos de uso
Elicitação de Necessidades de Proteção (PNE)
• Brainstorming o É o método mais rápido.
o Idéias são registradas sem crítica.
o São classificadas segundo critérios de relevância e possibilidade.
o São pontuadas e priorizadas.
o Derivam planos de ação.
Elicitação de Necessidades de Proteção (PNE)
• Questionários e entrevistas. o A efetividade deste processo está em como as questões serão
empregadas (público-alvo).
o Exemplos:
• Que tipo de dado será transmitido e mantido pelo software?
• O dado é sensível ou confidencial?
• O software irá manipular informações privadas ou credenciais?
• Quem são os usuários que irão alterar dados? Eles precisam ser auditados ou monitorados?
• Qual é o MTD para o software?
• Existe necessidade de single sign on?
• Que papéis ou perfis precisam ser estabelecidos para o CRUD?
Elicitação de Necessidades de Proteção (PNE)
• Decomposição política o As definições políticas da
organização são fontes de requisitos.
o Os objetivos e necessidades encontrados são decompostos para gerar requisitos de segurança.
o Necessidades como gerenciamento de configuração, segregação de ambientes, separação de direitos, revisão de código e outros, já podem existir na cultura organizacional.
Elicitação de Necessidades de Proteção (PNE)
• Classificação de dados. o Tipos de dados.
o Propriedade e custódia dos dados.
o Sensibilidade dos dados (rótulos).
o Roles – Responsabilidades sobre os dados.
o Ciclo de vida do dado.
Elicitação de Necessidades de Proteção (PNE)
• Rotulagem de dados.
Dado
Público?
Protegido por roles?
Alteração Não Produz Dano?
Alteração Produz Dano?
Sem impacto Na perda?
Com impacto Na perda?
Confidencialidade Integridade Disponibilidade
Público
Confidenc.
Baixa
Alta
Suporte
Crítico
Elicitação de Necessidades de Proteção (PNE)
• Matriz Sujeito Objeto o Útil para definição de roles.
o Auxilia na revisão de direitos.
o Definir níveis de análise.
Elicitação de Necessidades de Proteção (PNE)
• Casos de Uso e Desuso. o Determinam requisitos funcionais e de segurança.
o Modela o comportamento do software diante da intenção do ator.
Cria conta
Autentica
Pesquisa
Autentica
Obtém identidade
Força Bruta
Rouba dados
Cliente Hacker
Matriz de Rastreabilidade • Garante o escopo.
• Garante que os requisitos correspondem as
necessidades.
• Auxilia no estudo do impacto de mudanças.
• Auxilia na definição de casos de teste.
• Auxilia nas inferências de vulnerabilidades por
conceitos-chave de segurança.
Mais sobre Desenvolvimento Seguro
• Subsídios para processos de desenvolvimento
seguro e modelos de maturidade: o OWASP CLASP
o BSIMM – Building Security in Maturity Model
Obrigado!