O documento discute a importância dos requisitos de segurança no ciclo de vida de desenvolvimento de software. Ele destaca que software sem requisitos de segurança pode colocar a organização em risco e listar várias consequências negativas. Também discute fontes de requisitos de segurança, características de software seguro, impactos no projeto, e técnicas para elicitar requisitos de segurança.

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!