Requisitos de Segurança

  • 779 views
Uploaded on

Apresentação requisitos de segurança encontro OWASP de 20/08/13

Apresentação requisitos de segurança encontro OWASP de 20/08/13

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
779
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
29
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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.
  • 3. Requisitos de Segurança • Consequências do software vulnerável. Momentânea Indisponibilidade Comprometimento Da Continuidade
  • 4. 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.
  • 5. 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
  • 6. 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
  • 7. Requisitos de Segurança e Risco Residual Aceitável
  • 8. 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.
  • 9. Requisitos de Confidencialidade Controles de Confiden- cialidade Escrita Secreta Mascara- mento Em claro Obscura Criptografia Hashing Estegano- grafia Marca d’água digital
  • 10. 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.
  • 11. 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
  • 12. 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.
  • 13. 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.
  • 14. 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).
  • 15. 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).
  • 16. 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.
  • 17. 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
  • 18. 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.
  • 19. 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.
  • 20. 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. ERROS PRECISÃO
  • 21. 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.
  • 22. 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).
  • 23. 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
  • 24. 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?
  • 25. 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.
  • 26. 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
  • 27. 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.
  • 28. 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?
  • 29. 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.
  • 30. 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.
  • 31. 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
  • 32. 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.
  • 33. 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
  • 34. 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.
  • 35. 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
  • 36. Obrigado!