GESTÃO DA SEGURANÇA NO SDLC

Prévia do material em texto

GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLE 
GESTÃO DA SEGURANÇA NO SDLC 
SOFTWARE DEVELOPMENT LIFE CYCLE
CONCEITOS DE
• Software / Hardware.
• Projeto e gerenciamento de projeto.
• Processos ciclo de vida.
SOFTWARE
CARACTERÍSTICAS
• É desenvolvido por engenharia, não manufaturado.
• Não se desgasta, mas se deteriora.
• A maioria é feita sob medida, em vez de ser montado a 
partir de componentes existentes.
HARDWARE
CURVA DE FALHA
Ìndice 
de
Falhas
Mortalidade
infantil
Desgaste
Tempo
CURVA DE FALHA DO SOFTWARE
Tempo
Ìndice 
de
Falhas
Mudanças
Real
PROCESSO DE SOFTWARE
• É um conjunto de atividades que geram um produto.
• Há quatro atividades fundamentais:
 Especificação do software.
 Desenvolvimento do software
 Validação do software (Testes).
 Evolução do software.
ENGENHARIA DE SOFTWARE
Qualidade Total = mudança cultural com abordagens 
maduras.
Processo = Conjunto de KPA (indicadores de áreas chave).
Método = como fazer. Inclui requisitos, projeto, 
implementação, teste e manutenção.
Ferramentas = CASE (Computer Aided Software Engineering).
TIPOS DE DESPERDÍCIOS
3 Transporte
6 Movimentação
5 Estoque
4 Processo
1 Superprodução
7 Produtos defeituosos
2 Tempo de espera
DESPERDÍCIOS
Trabalho
Deslocamento
Espera
Ferramenta/Organização
O que o cliente quer pagar
FERRAMENTA 5 “S”
1º S – Senso de Seleção “Seiri”
2º S – Senso de Ordenação “Seiton”
3º S – Senso de Limpeza “Seiso”
4º S – Senso de Padronização “Seiketsu”
5º S – Senso de Comprometimento “Shitsuke”
PDCA
ENGENHARIA DE SOFTWARE
Com as mudanças no hardware:
• maior capacidade de armazenamento, 
• evolução dos computadores e sistemas sofisticados
 software tem atingido patamares inimagináveis há bem 
pouco tempo.
ENGENHARIA DE SOFTWARE
No desenvolvimento de software é comum ocorrer erros.
A manutenção é complexa. 
Um erro de software no início do projeto custa + - US$140 para 
ser corrigido.
Um erro detectado na pós-implantação pode custar US$14.000.
ENGENHARIA DE SOFTWARE
www.isixsigma.com
CUSTO DE CORREÇÃO DE ERROS NO SDLC (US$)
https://www.cs.umd.edu/projects/SoftEng/ESEG
Requisitos Projeto Código Teste Manutenção 
14.100
7.130
970
455139
DIAGRAMA DE ISHIKAWA OU 6M
Método Máquina Métricas
Meio ambiente Mão de obra Material
SEGURANÇA EM DESENVOLVIMENTO
Software hoje oferece funcionalidades imediatas 
(just-in-time), que podem ser acessadas via Web.
É importante implantar o processo de Gestão de da 
Informação confiável, para garantir a manutenção 
dentro de um nível aceitável de risco.
REUSO
A reutilização dos componentes do software é uma 
prática que permite focar nas inovações do projeto, 
podendo-se implementar funções comuns por meio de 
partes repetidas de código. Com isso permite-se 
ganhar mais tempo nas partes importantes da 
aplicação, em vez de “reinventar a roda”.
TRATAMENTO DE BUGS
É necessário conhecer as boas práticas de 
desenvolvimento e de segurança.
Investir em segurança traz um retorno amplo não só 
para o projeto, mas também para os usuários. 
Menor investimento no tratamento de bugs, fazendo 
com que sejam reduzidos tempo e recursos.
SEGURANÇA DO SOFTWARE
• Segurança nas fases: levantamento de requisitos, 
design, implementação, verificação, lançamento da 
aplicação e suporte e manutenção.
• Vulnerabilidades, correção, adaptação e expansão 
demandam mais pessoas e recursos do que o 
processo de criação.
GERÊNCIA DE PROJETOS
É realizada através da aplicação e integração dos processos do 
PMBOK, agrupados em cinco grupos:
Iniciação
Planejamento
Execução
Controle
Encerramento
GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLE 
SEGURANÇA EM DESENVOLVIMENTO
CONCEITOS DE
• Processos de desenvolvimento de software.
• Qualidade de software.
• Segurança em desenvolvimento.
• Vulnerabilidade
MODELOS DE DESENVOLVIEMNTO
• Cascata
• SCRUM
• Prototipação
• Iterativo e Incremental
• Espiral
MODELO CASCATA
MODELO ITERATIVO E INCREMENTAL
Implantação
Requisitos 
Análise
Projeto
Implemen-
tação
Testes
Análise
Projeto
Análise
Projeto
Requisitos Requisitos 
Testes Testes
Implantação Implantação
Implemen-
tação
Implemen-
tação
MODELO DE CICLO DE VIDA - RUP
ElaboraçãoConcepção Construção Transição
Requisitos
Análise
Projeto
Implementação
Testes
Implantação
marcos iterações marcos
Processo de Desenvolvimento de Software com UML (interativo e incremental)
REQUISITOS
PROJETO
ANÁLISE
IMPLEMENTAÇÃO
TESTE
IMPLANTAÇÃO
MODELO PROTOTIPAÇÃO
MODELO 
ESPIRAL
O QUE É SCRUM?
Scrum é uma metodologia ágil para gestão e 
planejamento de software. 
É um framework onde podemos empregar diversos 
processos e técnicas e desenvolver produtos complexos.
O QUE É SCRUM?
SPRINTS
No Scrum os projetos são divididos em cíclos 
de 2 a 4 semanas (SPRINTS). 
A Sprint é o coração do SCRUM. 
O trabalho é dividido em iterações (Sprints).
O Sprint representa um conjunto de atividades 
que deve ser executado.
SPRINT PLANNING MEETING 
itens 
Backlog
Não 
iniciado
Em 
progresso
Fim
Product
owner
Time de 
desenvolvimento
Sprint Timebox ( semanas)
Scrummaster Tempo da 
reunião
CUSTOS DE MANUTENÇÃO
Manutenção
67%
CUSTOS DE DESENVOLVIMENTO
CUSTOS DE MANUTENÇÃO
CUSTOS DE MANUTENÇÃO
A Engenharia de Segurança de Sistemas, surgiu com o 
crescimento e necessidade de segurança total:
• Aeronáutica e Aeroespacial
• Nuclear e industria, 
 Trazendo valiosos instrumentos para a solução de 
problemas ligados à segurança do software. 
ANÁLISE DA SEGURANÇA DE SOFTWARE 
• Confiabilidade e segurança. 
• Modelo de segurança no processo de 
desenvolvimento.
• Ferramentas de segurança de software.
http://www.clickgratis.com.br/virtual/tecnologia/dicas-de-
informatica/saiba-o-que-sao-os-softwares-de-seguranca/
CONFIABILIDADE E SEGURANÇA
A confiança é um atributo essencial do software:
• Confiança (Disponibilidade, Confiabilidade, Segurança e 
Proteção). 
• Atingir um alto nível de confiança é normalmente, o 
requisito mais importante para o software.
Confiança
Disponibilidade Confiabilidade Segurança Proteção 
Capacidade 
do software 
disponibilizar 
Serviço.
Disponibilizar 
serviço
conforme
especificado.
Operar 
sem falhas 
severas
Identificar 
estados 
inseguros 
e suas 
falhas
VULNERABILIDADE
Decorre de deficiência do software
Complexidade e interação
Feito às pressas
Correções deficientes
Programação descuidada
GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLE 
PAPÉIS E RESPONSABILIDADES
CONCEITOS 
• Papéis e responsabilidades dos profissionais de 
software.
• Como influenciam nas atividades do projeto.
• Como utilizam os recursos e como implementam. 
ESTRATÉGIA DE SEGURANÇA DA INFORMAÇÃO
P
ad
ro
n
iz
aç
ão
A
co
m
p
an
h
am
e
n
to
ESTRATÉGICO
TÁTICO
OPERACIONAL
APOIO
Dire-
trizes
Procedimentos e 
Instruções
Te
cn
o
lo
gi
a
P
e
ss
o
as
P
ro
ce
ss
o
s
Normas
Comitê de Segurança da 
Informação
PROFISSIONAIS DO DESENVOLVIMENTO 
SEGURO DE SOFTWARE
São responsáveis em apresentar e implantar um conjunto 
de práticas e metodologias aos programadores, o que 
resultaem melhores aplicações, com um excelente nível 
de confiabilidade, maturidade, integridade e 
inviolabilidade.
CONFIABILIDADE, MATURIDADE, INTEGRIDADE E 
INVIOLABILIDADE
• Desafiadas pelo desenvolvimento de novas tecnologias.
• Virtualização, colaboração, serviços em nuvem, Big Data.
• Urgência para modernizar e otimizar a infraestrutura de TI.
• Serviços de testes completos e complexos.
• Avaliação do risco, configuração, segurança, desempenho.
• Inteligência Competitiva.
PLANEJAMENTO
• As atividades de cada membro de software são definidas 
no planejamento do projeto.
• Requerimentos básicos para que cada função seja 
desempenhada da forma mais segura possível.
RESPONSABILIDADES DA EQUIPE EM RELAÇÃO AO SDLC
• Proteção do software.
• Os supervisores de segurança com informações precisas.
• Revisar a segurança antes da aplicação disponível.
• Buscar vulnerabilidades.
• Garantir que as respostas sejam desejadas.
• Desenvolver, manter e aprimorar a aplicação.
• Definir ações obrigatórias do processo.
• Fornecer treinamento adequado.
• Direcionar a equipe durante todo o processo.
• Supervisionar e rever a segurança.
RESPONSABILIDADES DA EQUIPE EM RELAÇÃO AO SDLC
REVISOR DE SOFTWARE
• Examina o código do aplicativo.
• Sugere correções ou adições.
• Verifica e atestam um alto nível de qualidade.
• Garante qualidade, integridade, robustez e segurança. 
• Monitora testes simulados.
ATRIBUIÇÕES DO REVISOR
• Documentar cenários e detalhes.
• Verificar as interfaces e os casos de testes.
• Informar se a aplicação está funcionando dentro do que 
foi proposto.
• Verificar a performance do software.
• Detectar e corrigir os problemas e erros causados pelas 
inconsistências.
WALKTHROUGH
Marcos de Revisão
Fim 
do 
Projeto
DIRETRIZES DO WALKTHROUGH
• O sistema é culpado até que se prove o contrário
• O programador é sempre inocente porque não está em 
julgamento.
• Um walkthrough não tem o propósito de avaliação.
• Torne-o formal somente quando necessário.
• Torne cada walkthrough efetivo em termos de custo.
VANTAGENS DO WALKTHROUGH
• Feedback
• O projeto tem maiores possibilidades de não ser
cortado mesmo estando atrasado.
• Os resultados aparecem mais rapidamente, o que eleva 
o moral dos implementadores.
• A taxa de progresso é medida pala quantidade de 
funcionalidades entregues.
ESPECIALISTA
• É responsável pela segurança.
• Descobre falhas por meio de análises.
• Realiza atualizações e controle de versões.
• Corrige falhas o mais rápido possível.
PAPÉIS DO ESPECIALISTA
• Avaliar as diversas tecnologias disponíveis.
• Vantagens e desvantagens de sua aplicação no software.
• Observar o comportamento do usuário na fase de testes.
• Assegurar que o planejado foi realizado.
• Prevenir vulnerabilidades.
AUDITORES
• Utilizam ferramentas para verificar 
se a aplicação atingiu as metas e 
critérios definidos no planejamento.
• São responsáveis pelo 
procedimento de investigação do 
processamento, simulação, análise e 
avaliação dos dados.
AUDITORIA
Estratégia da organização
Planos de desenvolvimento de sistemas
Plano de continuidade de serviços
Planejamento de capacidade etc
contribui para
estabelece
define
especifica gera impactos sobre
Políticas de 
segurança
Plano 
estratégico 
da TI 
PAPEL DO AUDITOR
• Conhecer o ambiente de 
desenvolvimento.
• Análise, conferindo o planejado e 
os objetivos da aplicação.
• Elaborar testes e simulações, 
emitindo opiniões e propostas de 
melhorias.
FACILITADOR
• Coordenadores das atividades.
• Líderes dos projetos.
• Garantir metodologias de segurança.
RESPONSABILIDADES DO FACILITADOR
• Trabalhar junto com o gestor.
• Planejamento em todo o ciclo de desenvolvimento.
• Visão expandida do software e seus processos.
• Relacionamento com desenvolvedores e cliente.
• Métricas de desenvolvimento de software.
• Padrões de segurança.
EVOLUÇÃO
• Nos primórdios da Internet, os sites eram conjuntos de 
arquivos de hipertexto que usavam textos e gráficos.
• Surgiram App baseados na Web.
• Ferramentas com foco no usuário.
• O próximo passo: Software como Serviço (SAS).
CONCLUSÃO
Desenvolvimento seguro no ciclo de vida do software 
requer um planejamento estruturado:
• Os WebApps: uso intenso da rede, a simultaneidade, 
carga de usuários não previsível, desempenho, 
disponibilidade, orientação a dados, evolução contínua, 
imediatismo, segurança e estética.
• Estar atualizados: porque o risco de ameaças é iminente.
GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLE 
INTRODUÇÃO À MODELAGEM DE AMEAÇAS
CONCEITOS 
• Processo de análise de riscos, impactos e 
vulnerabilidades.
• Estratégias de proteção a ataques e segurança da 
aplicação.
• Documentação e do uso de metodologias. 
ORIGEM DA MODELAGEM DE AMEAÇAS
• Conceito militar (USA)
• Hoje sua estruturação é voltada ao software.
• Ferramentas que mapeiam os riscos associados à
aplicação ajudando a tratá-los.
CONCEITUAÇA DA MODELAGEM DE AMEAÇAS
PARA OS MILITARES AMERICANOS
• Envolve análise de riscos, motivação, capacidade,
viabilidade e cenários de defesa face a um possível
ataque.
Para uma linguagem de segurança:
• Mapeamento de exploits (elaborados por hackers que
tiram proveito de uma vulnerabilidade).
DEFINIÇÃO DA MODELAGEM DE AMEAÇAS
• Processo composto de cenários de ataque e
vulnerabilidades.
• Identifica os níveis de risco e impacto que podem
comprometer a proteção do software.
O QUE SÃO VULNERABILIDADES?
• Fragilidades presentes ou associadas a ativos que
manipulam ou processam informações.
• Ao ser explorada por ameaças, permitem a ocorrência
de incidentes, afetando negativamente os princípios de
segurança da informação.
• Uma ameaça é um possível perigo que pode explorar
uma vulnerabilidade.
TRATAMENTO DAS VULNERABILIDADES DA APLICAÇÃO
• A partir da análise e estudo das ameaças e riscos.
• Começando pelas que apresentam os maiores riscos até as que
são vistas como improváveis, mas que podem afetar o software.
RISCOS QUE PRECISAM SER GERENCIADOS
Tecnologias emergentes
Explosão de dados e informações
Mundo wifi
Privacidade dos clientes
Exigência de conformidade
VULNERABILIDADES
• Associação de riscos a marca da empresa
• Perda de propriedade intelectual.
• Exposição legal ou regulatória.
• Informações confidenciais de clientes.
• Informações estratégicas.
• Altos custos para remediação de danos.
• Interrupção dos negócios.
VULNERABILIDADES
Hardware:
- Falha, desgaste, obsolescência, mau uso.
- Erros durante a instalação.
- Ausência de atualizações de acordo com as orientações
dos fabricantes dos softwares embarcados.
- A conservação inadequada dos equipamentos.
VULNERABILIDADES
Software:
• Erros de instalação ou de configuração possibilitando 
acesso indevido, vazamento de informações.
• A configuração e a instalação indevidas dos programas ou 
sistemas operacionais podem levar ao uso abusivo dos 
recursos por parte de usuários mal-intencionados.
VULNERABILIDADES
Comunicações:
• Acessos não autorizados ou perda de comunicação.
• A ausência de sistemas de criptografia.
• A má escolha dos sistemas de comunicação para envio de 
mensagens de alta prioridade da empresa.
VULNERABILIDADES
Humanas:
• Falta de treinamento.
• Compartilhamento de informações confidenciais.
• Falta de execução de rotinas de segurança.
• Erros ou omissões.
• Sabotagem, distúrbios, greves, roubo, furto, invasões.PAPÉIS E RESPONSABILIDADES
• A aplicação disponibilizada está em um ambiente hostil, com 
diversos tipos de ameaças.
• É necessário administrar os riscos com avaliações e análises 
regulares.
• STRIDE (Spoofing, Tampering, 
Repudiation, Information Disclosure, 
Denial of Service, Elevation of
Privilege), que pode conter a 
verificação das ameaças de redes, 
de hosts e de aplicação.
MÉTODOS DE IDENTIFICAÇÃO DE AMEAÇAS
MÉTODO DE IDENTIFICAÇÃO DE AMEAÇAS: STRIDE
Spoofing
(Falsificação)
Atacante tenta se passar por alguém que não é 
para invadir o software.
Tampering 
(Violação)
o atacante tenta modificar dados trocados por 
uma aplicação e um usuário autorizado. 
Repudiation
(Repúdio)
Quando o atacante consegue penetrar na 
aplicação sem que sua autoria seja reconhecida,
MÉTODO DE IDENTIFICAÇÃO DE AMEAÇAS: STRIDE
Information
Disclosure
(Divulgação não 
autorizada)
O atacante pode ler dados particulares 
que a aplicação transmite ou armazena.
Denial of Service 
(Negação de 
serviço)
Caso o atacante impossibilite o acesso 
dos usuários à aplicação.
Elevation of
Privilege
(Elevação de 
privilégio)
O atacante consegue privilégios não 
autorizados por um meio não permitido.
EXEMPLOS
• Tampering (violação dos dados de login).
• Information Disclosure (divulgação não autorizada de usuários 
que possuem acesso ao banco).
• Denial of Service (negação de serviço, “derrubando” o servidor 
através de ataques DDoS). 
COMO MITIGAR AS AMEAÇAS
• Usar Logs de controle de acesso (ACLs).
• Camada de transporte segura (TLS).
• Camada de sockets protegida (SSL-
ferramenta de encriptação de páginas antes 
de serem transmitidas).
EXEMPLOS
• Tampering (violação dos dados de login).
• Information Disclosure (divulgação não autorizada de usuários 
que possuem acesso ao banco).
• Denial of Service (negação de serviço, “derrubando” o servidor 
através de ataques DoS). 
EXEMPLOS – REDE INSEGURA
• Tampering (violação com a manipulação dos dados trafegados 
pela rede sem segurança).
• Information Disclosure (como se trata de uma rede insegura a 
informação privada pode ser vista com maior facilidade).
• Elevation of privilege (elevação de privilégios com a 
manipulação das informações.
EXEMPLOS – REDE INSEGURA
• Muitas vulnerabilidades em rede insegura:
 Aeroportos
 locais públicos
 Faculdades
 Qualquer pessoa tem acesso e sem método de autenticação. 
 Podem ser usados os métodos de Camada de Sockets Segura 
(SSL) e Camada de Transporte Segura (TLS).
MÉTODOS DE IDENTIFICAÇÃO DE AMEAÇAS: DREAD
Enquanto o STRIDE faz uma análise e classificação das
ameaças, propondo a redução dos riscos, o modelo DREAD
(Damage Potential, Reproducibility, Exploitability, Affected
Users, Discoverability) é utilizado para calcular a estimativa
do risco total que é associado a uma ameaça de segurança
na aplicação.
PAPÉIS E RESPONSABILIDADES
Damage
O atacante pode ler dados particulares 
que a aplicação transmite ou armazena.
Reprodution
Caso o atacante impossibilite o acesso 
dos usuários à aplicação.
Exploration
O atacante consegue privilégios não 
autorizados por um meio não permitido.
Affected os usuários afetados pela ameaça 
Discovery
Agilidade que é descoberta a 
vulnerabilidade 
CONCLUSÃO
• O profissional do desenvolvimento seguro deve documentar
as ameaças.
• Servirá de apoio a futuras verificações de vulnerabilidades.
• É mais fácil analisar os riscos e determinar os recursos
necessários para suprir qualquer brecha que a aplicação
possa conter.
GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLE 
AS VULNERABILIDADES DO OWASP TOP 10
Conceitos
• OWASP (Open Web Application Security Project).
• Práticas utilizadas para aumentar a segurança do software.
• Identificação do ataque ou vulnerabilidade e seus impactos.
• Pontos fracos e os riscos mais conhecidos nas aplicações web.
OWASP 
OPEN WEB APPLICATION SECURITY PROJECT 
• OWASP é uma entidade sem fins lucrativos.
• Contribui para a melhoria da segurança de software.
• Reúne informações importantes que permitem avaliar riscos 
de segurança.
• Combate formas de ataques através da internet.
OWASP TOP 10
• OWASP Top 10 é composto pelas dez vulnerabilidades que 
mais ocorrem nos WebApps.
• Identifica os riscos mais graves dos app.
CLASSIFICAÇÃO DE RISCOS DA OWASP
• Tipo de ataque
• Tipo de vulnerabilidade
• Tipo de impacto 
 Causado pela invasão.
 Agentes de Ameaça identificam 
pontos fracos da aplicação.
 Cavalo de Troia
CVALO DE TROIA
• Programas desenvolvidos pelos 
hackers com o objetivo de destruir 
o alvo. 
• São disseminados por e-mail ou 
ficam escondidos dentro da 
aplicação do usuário.
AGENTES DE AMEAÇAS
• Os agentes utilizam técnicas de coleta de inteligência.
• Inclui técnicas inteligentes de invasão.
 Interceptação de telefonemas.
 Imagens via satélite. 
APT - ADVANCED PERSISTENT THREAT
(AMEAÇA PERSISTENTE AVANÇADA)
• São ameças cibernéticas –
espionagem via Internet.
• São valiosas – Compensa o 
investimento em tempo e dinheiro.
• Complexidade é tamanha que um 
cracker não é autor de APT.
EXEMPLOS DE APT
• Ataques APT são direcionados (targeted 
attacks). 
 drive-by download (download não 
intencional de software, sem o 
conhecimento da pessoa)
 injeção de SQL (SQL injection) 
 malwares, spywares, phishing e spam.
ENGENHARIA SOCIAL
• É a missão mais crítica dos agentes de um 
ataque APT.
• Ataque é voltado contra alguma pessoa.
• Exemplo: anexos dos e-mails
• Invasor direciona as informações de modo 
parecer confiáveis.
• O agente identifica os candidatos alvo.
POLÍTICA DE SEGURANÇA DE INFORMAÇÕES
Identifique as
vulnerabilidades 
Fonte: Prof. Elton Regis C. Spode, MsC UNIFRA
POLÍTICA DE SEGURANÇA DE INFORMAÇÕES
• Confidencialidade / privacidade – criptografia
• Integridade de dados – evitar que sejam apagados
• Disponibilidade – evitar ataques
• Consistência - de acordo com as expectativas
• Isolamento – acesso ao sistema
• Auditoria - proteger contra erros e atos ilícitos
• Confiabilidade - atuará conforme o esperado
ERROS HUMANOS
Erros humanos
52%
Incêndio 15%
Atividades
desonestas
10%
Sabotagem 10% 
Água 10%
Terrorismo 3% 
AS VULNERABILIDADES DO OWASP TOP 10
1. INJEÇÃO
Dados não confiáveis são enviados. Podem gerar comandos 
indesejados ou permitir o acesso não autorizado. 
Como evitar: usar uma API segura ou que tenha uma interface 
parametrizada de modo a separar os dados não confiáveis.
API (Application Programming Interface) = instruções de 
programação para acesso a um aplicativo.
AS VULNERABILIDADES DO OWASP TOP 10
2. QUEBRA DE AUTENTICAÇÃO E 
GERENCIAMENTO DE SESSÃO
Atacantes comprometam senhas e tokens ou exploram falhas de 
implementação, assumindo a identidade de outros usuários.
Como evitar: disponibilizar aos desenvolvedores um conjunto 
de controles fortes para autenticação e gerenciamento de 
sessão.
3. CROSS-SITE SCRIPTING (XSS)
Falhas de XSS: quando uma aplicação recebe e envia ao 
navegador dados não confiáveis, sem validação.
Atacantes executam scripts no navegador da vítima, desfigura 
sites, sequestra sessões ou redireciona para sites maliciosos.
Como evitar: bibliotecas de auto-sanitização e a Content
Security Policy no site.
4. REFERÊNCIA INSEGURA E DIRETA A OBJETOS
O programador expõe um arquivo da base de dados. Quando é 
feita uma referência à implementaçãointerna de um objeto sem 
a verificação de acesso, os atacantes podem manipular e 
acessar dados não autorizados.
Como evitar: proteger os objetos, impedindo que o atacante 
acesse recursos não autorizados.
5. CONFIGURAÇÃO INCORRETA DE SEGURANÇA
Quando uma configuração pré-definida de segurança é 
implementada na aplicação (frameworks, servidor, banco de 
dados), há risco, pois o invasor conhece o formato dos padrões. 
Como evitar: As configurações devem ser definidas, 
implementadas e mantidas porque a configuração padrão é 
insegura por ser previsível.
6. EXPOSIÇÃO DE DADOS SENSÍVEIS
A não proteção dos dados sensíveis como cartões de crédito 
compromete a segurança do usuário. 
Como evitar: criptografia.
7. FALTA DE FUNÇÃO PARA CONTROLE DO 
NÍVEL DE ACESSO
A maioria das aplicações web verificam os direitos de acesso 
antes de tornar a funcionalidade visível para o usuário.
Depois precisam executar as mesmas verificações de controle 
de acesso no servidor quando a função é invocada. 
Se as requisições não forem verificadas, os atacantes podem 
forjar as requisições para acessar funcionalidades sem a 
autorização adequada. 
8. CROSS-SITE REQUEST FORGERY (CSRF)
Esse ataque força a vítima enviar uma requisição HTTP forjada, 
incluindo o cookie da sessão. A falha permite o atacante forçar o 
navegador da vítima a criar requisições que a aplicação 
vulnerável aceita como legítimas.
Como evitar: tokens.
9. UTILIZAÇÃO DE COMPONENTES 
VULNERÁVEIS CONHECIDOS
As aplicações que utilizam componentes com vulnerabilidades 
conhecidas podem minar as defesas permitindo ataques.
Utilizar componentes vulneráveis é um risco, pois podem estar 
desatualizados e sem correções para as vulnerabilidades.
Como evitar: Componentes do software e as versões são 
identificados para que se possa monitorar a segurança.
10. REDIRECIONAMENTOS E 
ENCAMINHAMENTOS INVÁLIDOS
Aplicações web frequentemente redirecionam para outros sites, 
utilizando dados não confiáveis para determinar as páginas de 
destino. Sem uma validação adequada os atacantes podem 
facilmente redirecionar as vítimas para sites de phishing, 
malware.
Como evitar: não usar parâmetros do usuário para calcular o 
destino.
CONCLUSÃO
Para a Segurança no Ciclo de Vida do Desenvolvimento, o 
OWASP recomenda que para a melhoria dos processos se 
utilize o Modelo de Maturidade de Garantia do Software 
(SAMM), que ajuda a formular e implementar estratégias para a 
segurança do software feita de forma personalizada para os 
riscos enfrentados.
GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLE 
SEGURANÇA POR CÓDIGO 
Conceitos
• Segurança por código.
• Programação defensiva.
• Gerenciamento de senhas.
• Esforço de teste no SDLC.
SEGURANÇA POR CÓDIGO 
• É o conjunto de técnicas criadas para o tratamento de 
vulnerabilidades.
• Cuidados necessários que devem ser tomados no 
desenvolvimento seguro de software.
• Sabemos que em toda etapa do ciclo de vida acontecem erros 
de programação.
OWASP 
OPEN WEB APPLICATION SECURITY PROJECT 
• OWASP é uma entidade sem fins lucrativos.
• Contribui para a melhoria da segurança de software.
• Reúne informações importantes que permitem avaliar riscos 
de segurança.
• Combate formas de ataques através da internet.
SEGURANÇA POR CÓDIGO 
As práticas listadas pela OWASP Top 10 que ajudam na 
proteção contra as vulnerabilidades de segurança mais comuns 
nas aplicações Web, fornecendo técnicas para salvaguardar o 
software desenvolvido.
PROGRAMAÇÃO DEFENSIVA
• É um conjunto de técnicas de projeto e programação 
objetivando a estabilidade e a segurança do software. 
• Reduz/elimina a hipótese da Lei de Murphy acontecer. 
• Começaram a ser desenvolvidas quando o software aponta 
para efeitos catastróficos.
DICAS PARA PROGRAMAÇÃO DEFENSIVA
• Nunca faça código mais complexo que o necessário. 
Complexidade alimenta bugs, incluindo problemas de 
segurança.
• Deixe o código disponível para todos na rede (software livre).
• Contrate um auditor de segurança.
• Reutilize o código ao invés de reescrever do zero.
DICAS PARA PROGRAMAÇÃO DEFENSIVA
• Use criptografia para dados estratégicos.
• Todo dado é importante até prova em contrário.
• Todo código é inseguro até prova em contrário.
• Se dados vão ser corrigidos, cheque a sua validade.
AUTENTICAÇÃO E GERENCIAMENTO DE SENHAS
• Segurança é a palavra de ordem hoje.
• Temos que ser mais prudentes, com hábitos seguros na Web. 
• Temos uma infinidade de dados pessoais extremamente 
sensíveis armazenados nos mais variados tipos de sites.
• E todos eles protegidos, muitas vezes, por uma única senha.
AUTENTICAÇÃO E GERENCIAMENTO DE SENHAS
• Adotar senha única para cada serviço.
• Memorizar senhas é difícil. 
• Há várias aplicações que se propõem não só armazenar seus 
passwords de maneira segura, mas gerá-los aleatoriamente. 
• Ex: ferramenta do Google que vem embutida no Chrome.
http://canaltech.com.br/dica/protecao-de-dados/voce-sabia-que-o-google-tem-um-gerenciador-de-
senhas-veja-como-utiliza-lo/
GERENCIADOR DE SENHAS
• É um programa que armazena muitos nomes/senhas. 
• BD é criptografado e usa apenas uma chave (senha mestre).
• Facilita o gerenciamento de senhas.
• Incentiva os usuários a escolherem chaves complexas sem 
medo de não lembrá-las mais tarde.
SEGURANÇA DO GERENCIADOR DE SENHAS
A segurança do gestor de senhas depende:
• A robustez da senha mestra.
• Algoritmo de criptografia.
• A qualidade do código-fonte do aplicativo.
• A existência de vírus ou outro malware no seu computador. 
• A solidez da chave mestra e Gerenciador de senhas de pouco 
adiantam se houver um Keylogger instalado.
HASH SEGURO DE SENHA
• É uma espécie de "assinatura" ou "impressão digital“. 
• Gerar hash de senha é uma ação básica de segurança que 
deve ser feita ao projetar qualquer aplicativo que aceita 
senhas de usuários. 
• Sem gerar hash, todas as senhas armazenadas podem ser 
roubadas e usadas.
SALT SEGURO DE SENHA
• Ao solicitar uma nova autenticação, o Gerenciador de Senhas 
usa o hash e o salt para codificar as senhas armazenadas, 
implementando um grau de complexidade nas senhas.
HASH e SAL
Pw bob bob Pw bob bob
Salt Et57 D7r4
Hash f4c341se f4c341se Hash Jyb49as z32r7s9 
Hash sem Salt Hash com Salt
palavra
Password
errada
Hash
Hash
não confere
Banco de
password
Password salva
Idênticas?
Não Sim
Acesso negado Acesso liberado
USO DO TOKEN
• O Gerenciamento de Sessão e seu controle devem ser feitos 
pelo servidor, por meio de um método de time-out por sessão 
e que se seja gerado um novo identificador após a 
autenticação.
• Implementar token de sessão aleatório a cada requisição para 
evitar ataques CSRF (Cross Site Request Forgery -
Falsificação de Solicitação entre Sites).
CSRF 
FALSIFICAÇÃO DE SOLICITAÇÃO ENTRE SITES
• Ataque malicioso a um website no qual comandos não 
autorizados são transmitidos por um usuário em quem o 
website confia.
• CSRF explora a confiança que um website tem do usuário.
SEGURANÇA POR CÓDIGO
• Segundo o disposto pelo Common Weakness Enumeration, 
que descreve as vulnerabilidades publicamente conhecidas, 
vemos que podem ocorrer: 
• Falhas na lógica, erros numéricos, formato de string, 
exposição de informações, Buffers Overflows e problemas de 
criptografia.
ESFORÇO DE TESTE NO SDLC
GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLEMÉTRICAS / QUALIDADE DE SOFTWARE
Os erros podem aparecer no início do processo devido a: 
• objetivos mal definidos
• erros em fases de projeto e desenvolvimento. 
O cliente não tolera erros; o desenvolvimento de software tem 
que ter garantia de qualidade e de segurança.
CUSTO DO SOFTWARE
Requisitos Codificação Entrega
Custo
Estágio de 
desenvolvimento
Requisitos Codificação Entrega
Custo
MEDIDA DO SOFTWARE
Não se pode gerenciar o que não se pode medir.
O gerenciamento de projetos de software deve ser auxiliado 
pela utilização de uma métrica que permita a mensuração 
de um projeto e consequentemente a geração de sua 
estimativa de prazo, custo e recursos.
FATORES DE QUALIDADE McCall
OPERAÇÃO
* Corretude → Software satisfaz os objetivos do cliente.
* Confiabilidade → Programa executa sua função com precisão.
* Eficiência → Programa execute sua função, com total precisão, 
visando realizar a operação de forma 100% segura.
* Integridade → Bloqueio do acesso.
* Usabilidade → Mede a facilidade para a utilização do software.
REVISÃO
* Manutenção → O esforço para reparar erros em um programa.
* Flexibilidade → Grau de facilidade que o SW oferece para a 
sua alteração, de forma rápida e eficaz.
* Testabilidade → Esforço exigido para testar um programa a fim 
de garantir que ele execute a função pretendida.
TRANSIÇÃO
* Portabilidade → Mede a facilidade com que um produto pode 
ser movido para outra plataforma, ou software.
* Reusabilidade → Medida na qual o software pode ser reusado 
em outros softwares.
* Interoperabilidade → O software é capaz de ser acoplado ao 
outro.
• Número de linhas de código produzidas 
(KLOC - Kilo Lines of Code ou 
simplesmente mil linhas de código).
• Velocidade de execução.
• Tamanho de memória.
• Número de defeitos registrados em um 
intervalo de tempo. 
MÉTRICAS DIRETAS DO SOFTWARE
VANTAGENS
Fácil de calcular.
É o fator mais importante para muitos modelos de estimativa.
Dependente da linguagem de programação.
Penalizam programas bem estruturados.
DESVANTAGENS
MÉTRICAS KLOK
Pontos de Função podem ser utilizados para medir 
sistemas em várias fases do ciclo de vida de 
desenvolvimento, inclusive para manutenção.
Abordagem das funções e características de um sistema 
sob o ponto de vista do que ele faz para o usuário, num 
enfoque empresarial e não técnico.
ESCOLHA DE UMA MÉTRICA: PONTOS DE FUNÇÃO
• Medição de Funcionalidade de acordo com o usuário.
• Criação de uma unidade padrão de medida de software.
• Melhoria de estimativas de projetos de sistemas.
• Transparência para o usuário final.
• Permite estimativas de tempo, recursos e custos desde o 
início do ciclo de desenvolvimento.
• Melhorar a qualidade dos contratos de terceirização.
OBJETIVOS DO PONTOS DE FUNÇÃO
PF PODE SER USADO PARA:
• Estimar o custo e esforço para projetar, codificar e testar 
o software. 
• Prever o número de erros que serão encontrados.
• Prever o número de componentes e linhas de código.
EXERCÍCIO - PF NÃO AJUSTADO
Arquivos Internos  25% do total de PF
Interfaces Externas  3% do total de PF
Entradas Externas  30% do total de PF
Saídas Externas  28% do total de PF
Consultas  14% do total de PF
AÇÕES
• Eleger um dos tipos de função que representa altos 
percentuais: Arquivos internos - Entradas externas - Saídas 
externas.
• Obter o número de ocorrências do tipo de função eleito.
• Calcular Pontos de Função Não Ajustados (PFNA).
• Utilize o Fator de Ajuste da Complexidade = 1.
PFNA
Arquivos Internos seriam facilmente identificáveis, o que os 
credenciou como melhor parâmetro para as estimativas PF.
Verificou-se que o total de Arquivos Internos é 13, portanto, 
complexidade média, segundo a tabela: 
de 1a 5  Simples
de 6 a 19  Médio 
>19  Complexo
Calculando o PFNA
a) Como Arquivos Internos representam 25% do total
25% === 13
100% === PF
PF = (13 * 100) / 25 = 52
b) Interfaces Externas: 3% de 52 = 1,56 ( ~= 2)
Entradas Externas: 30% de 52 = 15,6 ( ~= 16)
Saídas Externas: 28% de 52 = 14,56 ( ~= 15)
Consultas: 14% de 52 = 7,28 ( ~= 7)
TABELA DE FATORES DE PONDERAÇÃO
Tipo da Função Complexidade
(Média)
Total por Tipo
de Função
Entradas Externas 16 * 4 64
Saídas Externas 15 * 5 75
Consulta Externa 7 * 4 28
Arquivos Lógicos Internos 13 * 10 130
Arquivos de Interface Externa 2 * 7 14
Total PFNA 311
CÁLCULO DE PONTOS DE FUNÇÃO AJUSTADO (FPA)
PF = Total de contagem x [0,65 + 0,01 x ∑ (Fi )]
Os Fi (i = 1 a 14) são fatores de ajuste de valor baseados 
em respostas às questões a seguir:
Características Gerais da Aplicação 1 2 3 4 5
01 Teleprocessamento
02 Processamento distribuído
03 Performance
04 Carga de máquina
05 Volume de transações
06 Entrada de dados on-line
07 Atualizações on-line
Características Gerais da Aplicação 1 2 3 4 5
08 Eficiência do usuário final
09 Complexidade de processamento
10 Reutilização de código
11 Facilidade de implantação
12 Facilidade de operação
13 Facilidade de manutenção / alterações
14 Operação em múltiplos locais
0 (não importante ou não aplicável) a
5 (absolutamente essencial).
Vamos imaginar que após as respostas, Fi totalizou 46.
PFA = Total de contagem x [0,65 + 0,01 x ∑ (Fi)]
PFA = 311 x [0,65 + 0,01 x 46]
PFA = 311 x 1,11
PFA = 332,77 ~= 333
GESTÃO DA SEGURANÇA NO SDLC -
SOFTWARE DEVELOPMENT LIFE 
CYCLE 
SUPORTE NA REVISÃO E DESENVOLVIMENTO
• A importância da revisão do software no seu desenvolvimento.
• A relevância das análises realizadas.
• As técnicas de revisão usadas nas fases do ciclo de vida.
• Impacto que a segurança na aplicação pode representar para 
todos os envolvidos (stakeholders).
É POSSÍVEL CORRIGIR TODOS OS ERROS?
• Mesmo com as ferramentas mais atualizadas não é possível 
localizar e corrigir todos os erros.
• São recomendadas as revisões de código para o 
aperfeiçoamento da aplicação.
FERRAMENTAS DE SUPORTE A ANÁLISE
• É aplicada aos processos de desenvolvimento de SW.
• Usadas em treinamento para segurança do SW.
• Análise estática, testes e revisão de código, para localizar 
erros na codificação que podem revelar vulnerabilidades de 
segurança.
DESENVOLVIMENTO SEGURO PARA A WEB
• É fundamental cumprir os requisitos de qualidade:
 Privacidade e Segurança, Definição de Especialistas e 
Revisores e Requisitos Mínimos.
 Profissionais capacitados para validar e acompanhar os 
requisitos requeridos.
BUG TRACKING - RASTREAMENTO DE ERROS
• É um software que mantém o controle de bugs 
registrados. 
• É um sistema de controle de problemas. 
• Em projetos de software aberto, os usuários 
podem acessar relatórios de bugs diretamente. 
• Rastreamento de bugs é um componente do 
ambiente de desenvolvimento.
QUALITY GATES 
• Atividade que deve ser concluída antes da aceitação de uma 
entrega para a próxima etapa no ciclo de vida. São marcos:
 Revisão por pares.
 Revisão de usuário.
 Revisão de código.
 Análise de Riscos de Segurança e de Privacidade. 
 Matriz de rastreabilidade de requisitos.
MATRIZ DE RASTREABILIDADE DE REQUISITOS 
DESIGN DO SOFTWARE
• Onde é necessária uma investigação?
• Todos os requisitos foram completados (checklist)?
• A segurança foi verificada com a revisão de especialistas?
CRIPTOGRAFIA
• Criptografia (kryptós, "escondido", e gráphein, "escrita").
• Ferramenta importante para a segurança da informação.
• A informação é transformada para outra ilegível.• Conhecida apenas por seu destinatário ("chave secreta").
• Difícil de ser lida por alguém não autorizado. 
• Só o receptor da mensagem pode ler a informação. 
O PAPEL DA CRIPTOGRAFIA
• Mundo real
 Se as fechaduras das portas e janelas são fortes …
 … a sua casa está segura.
 Se tiver um sistema de alarme de segurança…
 … a sua casa estará mais segura.
PRIVACIDADE E CONFIDENCIALIDADE
Mundo Digital
• Ninguém pode invadir arquivos e ler os seus dados 
pessoais sigilosos (Privacidade).
• Ninguém pode invadir um meio de comunicação e 
obter a informação trafegada para obter vantagens
(Confidencialidade).
PROCEDIMENTOS DE CRIPTOGRAFIA
Os procedimentos de criptografar e decriptografar são obtidos
através de um algoritmo.
Algoritmo de 
Criptografia
Dado original Dado criptografado
0101001
0101101
11101101
##$@&&
&$$@@#$
%%$&@&
IMPLEMENTAÇÃO VOLTADA 
PARA O DESENVOLVIMENTO
• Criação da aplicação e testes.
• Validação das API (Application
Programming Interface).
• Ao término, realizar uma Análise 
Estática Constante, que é a revisão de 
todo o código desenvolvido.
http://www.goldark.
com.br/blog/api-first
ANÁLISE ESTÁTICA
• Problema: Quanto mais cedo, mais barata é a sua correção.
• Um problema encontrado em desenvolvimento será muito mais 
barato de corrigir do que se for encontrado em produção. 
• Da mesma forma, código bem escrito reduz drasticamente o 
tempo e o custo de manutenção.
• O uso da orientação a objeto: código flexível e mudanças de 
forma mais tranquila, segura e natural.
ANÁLISE ESTÁTICA
• Por outro lado, prazos cada vez mais curtos, a qualidade é 
deixada de lado, de forma que detalhes importantes são 
ignorados, levando a aplicações mal construídas. 
• O resultado é sempre o mesmo: alto custo e demora em 
manutenções, alta taxa de bugs e insatisfação do cliente.
ANÁLISE ESTÁTICA: VERIFICAÇÃO EM 3 GRUPOS 
1) Verificação por estilo: Considera elementos como identação, 
espaços e tabs, convenção de nomes, número de parâmetros, 
alinhamento na vertical, formato e presença de comentários, 
dentre outros. 
• São os aspectos que contribuem para tornar o código 
padronizado, organizado e legível. A ferramenta mais utilizada 
para verificação por estilo é o Checkstyle.
IDENTAÇÃO
2) Verificação por boas práticas: 
• Evitar duplicação de código, tamanho de métodos, classes e 
parâmetros, criação desnecessária de variáveis locais.
• O conjunto de regras é extenso. A ferramenta de verificação 
mais utilizada para aplicar boas práticas é o PMD.
3) Verificação por bugs: 
• Trata de encontrar erros no sistema. 
• É importante para antecipar a identificação de problemas antes 
de sua execução pelo cliente. 
• A ferramenta mais utilizada para identificação de bugs é o 
Firebug.
ANÁLISE DINÂMICA
• O programador deve ler o código através de uma ferramenta 
de suporte, para que possa ser feita uma verificação.
• Testes Fuzzing: é injetado no software grande volume de 
conteúdo malformado, desconhecido e fora do padrão para 
verificação de seu comportamento e a segurança. 
TESTES FUZZING
• Fuzzing é uma técnica de testes de software, automatizada ou 
semi-automatizada, que provê dados inválidos.
• O programa é monitorado, analisando erros em tempo de 
execução. 
• Fuzzing é uma técnica comumente utilizada para testar 
problemas de segurança.
REVISÃO DE AMEAÇAS (TIME MODELLING/ 
APPLICATION SECURITY REVIEW)
• Irá validar os módulos contra o código completo.
• Executar o Pentest que simulará um comportamento malicioso 
com a finalidade de comprometer a aplicação. 
• Por fim, após passar por todos esses testes será lançada a 
aplicação.
FÓRUM PENTEST
PCI DSS (Payment Card Industry Data Security Standard) 
Fórum global para a disseminação de padrões de segurança 
na proteção de informação para estabelecimentos que utilizam 
cartões como forma de pagamento.
Desenvolvida pelas operadoras Visa, Mastercard e American 
Express
PLANO DE RESPOSTA
• Verificar quando a aplicação dá problema e documentar os 
procedimentos.
• Fazer a Revisão Final dos Requisitos de Segurança.
• Arquivar todos os dados relevantes da documentação para que 
se possa emitir uma resposta final.
• A revisão do código verifica se os mecanismos de segurança 
da aplicação apresentam um nível suficiente de robustez. 
REVISÃO DE CÓDIGO - VULNERABILIDADES
• Pode encontrar diversas vulnerabilidades.
• Um bom código, com técnicas efetivas, os riscos são evitados.
• Revisar o código é uma maneira de complementar os testes e 
as ferramentas utilizadas, ajudando na detecção e remoção de 
vulnerabilidades.
sobre-o-concurso-vulnerabilidades-e-outros-demonios 
TIGER TEAM (HACKERS PROFISSIONAIS)
• Originou-se nas Forças armadas para descrever uma equipe 
cuja a finalidade fosse penetrar a segurança de instalações 
militares (penetration test).
• Pessoas especializadas em segurança da informação.
• Testar a eficácia da segurança de uma organização.
CIBERESPAÇO
• Tornou-se popular na indústria de 
computadores: a segurança da informação 
é testada frequentemente por Tiger Team.
• O termo mais comum hoje é Penetration
Testers (Analistas de Teste de Intrusão). 
	Aula_01
	Aula_02
	Aula_03
	Aula_04
	Aula_05
	Aula_06
	Aula_07
	Aula_08