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!