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.
Modelos de Processos de Software, Modelo Cascata (waterfall), Desenvolvimento incremental, Engenharia de Software Orientada a Reuso, Atividades do Processo, Especificação, Prototipação
Modelos de Processos de Software, Modelo Cascata (waterfall), Desenvolvimento incremental, Engenharia de Software Orientada a Reuso, Atividades do Processo, Especificação, Prototipação
Conceitos básicos que fundamentam os estudos sobre SI, Diferentes categorias de ativos existentes em uma empresa, Conceitos de vulnerabilidades e ameaças dos ativos, integridade, confidencialidade e disponibilidade, análise de riscos (AR), etc.
Palestra: Fundamentos do Desenvolvimento Seguro de SoftwaresAndre Henrique
Palestra realizado na Live da OWASP Vitória realizado online ao vivo no Youtube no dia 30/06/2020.
O objetivo da apresentação foi de disponibilizar um conteúdo básico com temas acerca de boas práticas em codificação, erros comuns, estatísticas atuais em 2020 e onde obter informação para programar de forma mais segura.
Palestra realizada por Camilo Ribero no segundo semestre de 2010 para os alunos dos cursos de sistemas de informação e ciência da computação da PUC Minas, na Unidade São Gabriel
Seminário sobre Qualidade de Software e modelos de maturidade apresentado no primeiro semestre de 2012 na disciplina de Engenharia de Software no programa de pós-graduação do Departamento de Computação da Universidade Federal de São Carlos.
Les principales failles de sécurité des applications Web actuellesXavier Kress
Les principales failles de sécurité des applications Web actuelles telles que recensées par l'OWASP. Principes, parades et bonnes pratiques de développement.
Ce document, élaboré dans le cadre d'une présentation faite au CNAM, traite de l’importance de la sécurité applicative (les applications Web sont devenues omniprésentes, objectifs et conséquences d’une attaque, les hackers et les kits d’attaque, l'OWASP et les kits de défense), des principales failles de sécurité applicatives (principe et exemples de fonctionnement, objectifs / conséquences, parades) et des bonnes pratiques permettant de sécuriser un parc applicatif (sensibiliser les développeurs, effectuer des tests d’intrusion et de la revue de code, intégrer la sécurité dans la gestion de projets)
Curso Completo de Banco de Dados com MySQL GRÁTIS em
https://www.youtube.com/playlist?list=PLHz_AreHm4dkBs-795Dsgvau_ekxg8g1r
Curso em Vídeo
Site: http://www.cursoemvideo.com
YouTube: http://www.youtube.com/cursosemvideo
Facebook: http://www.facebook.com/cursosemvideo
Twitter: http://twitter.com/cursosemvideo
Google+: http://plus.google.com/112666558837414979080
Patrocínio
HOSTNET: http://www.hostnet.com.br
Transformação conceitual para Lógico
Tabelas, Campos, Registros
Restrições de Integridade
Chaves Primaria / Estrangeira
SQL para Definição de dados: DDL
Desvendando o desenvolvimento seguro de softwareAllyson Chiarini
O mundo atual está vivendo uma revolução no quesito aplicações onde cada vez mais temos temas como mobilidade, big data e consumerização, neste contexto a segurança da informação tem papel fundamental para garantir a mitigação de risco de exposição de informações. Atualmente o tema espionagem corporativa ou política está em volga devido ao caso NSA, ou seja, estamos vivendo uma época onde o tema segurança é de vital importância para as corporações. Com uma curva crescente de demanda por novas aplicações atualmente a área de desenvolvimento é forçada a entregar as aplicações em tempo cada vez menor, levando em consideração isso para otimização de esforço no ciclo de desenvolvimento se faz necessário adotar soluções que mitiguem o risco de segurança de informação em tempo de desenvolvimento. A família AppScan vem para endereçar este ponto, onde ela além de otimizar o processo de testes na disciplina de segurança de informação ela garante uma constante atualização em relação as ameaças correntes.
Conceitos básicos que fundamentam os estudos sobre SI, Diferentes categorias de ativos existentes em uma empresa, Conceitos de vulnerabilidades e ameaças dos ativos, integridade, confidencialidade e disponibilidade, análise de riscos (AR), etc.
Palestra: Fundamentos do Desenvolvimento Seguro de SoftwaresAndre Henrique
Palestra realizado na Live da OWASP Vitória realizado online ao vivo no Youtube no dia 30/06/2020.
O objetivo da apresentação foi de disponibilizar um conteúdo básico com temas acerca de boas práticas em codificação, erros comuns, estatísticas atuais em 2020 e onde obter informação para programar de forma mais segura.
Palestra realizada por Camilo Ribero no segundo semestre de 2010 para os alunos dos cursos de sistemas de informação e ciência da computação da PUC Minas, na Unidade São Gabriel
Seminário sobre Qualidade de Software e modelos de maturidade apresentado no primeiro semestre de 2012 na disciplina de Engenharia de Software no programa de pós-graduação do Departamento de Computação da Universidade Federal de São Carlos.
Les principales failles de sécurité des applications Web actuellesXavier Kress
Les principales failles de sécurité des applications Web actuelles telles que recensées par l'OWASP. Principes, parades et bonnes pratiques de développement.
Ce document, élaboré dans le cadre d'une présentation faite au CNAM, traite de l’importance de la sécurité applicative (les applications Web sont devenues omniprésentes, objectifs et conséquences d’une attaque, les hackers et les kits d’attaque, l'OWASP et les kits de défense), des principales failles de sécurité applicatives (principe et exemples de fonctionnement, objectifs / conséquences, parades) et des bonnes pratiques permettant de sécuriser un parc applicatif (sensibiliser les développeurs, effectuer des tests d’intrusion et de la revue de code, intégrer la sécurité dans la gestion de projets)
Curso Completo de Banco de Dados com MySQL GRÁTIS em
https://www.youtube.com/playlist?list=PLHz_AreHm4dkBs-795Dsgvau_ekxg8g1r
Curso em Vídeo
Site: http://www.cursoemvideo.com
YouTube: http://www.youtube.com/cursosemvideo
Facebook: http://www.facebook.com/cursosemvideo
Twitter: http://twitter.com/cursosemvideo
Google+: http://plus.google.com/112666558837414979080
Patrocínio
HOSTNET: http://www.hostnet.com.br
Transformação conceitual para Lógico
Tabelas, Campos, Registros
Restrições de Integridade
Chaves Primaria / Estrangeira
SQL para Definição de dados: DDL
Desvendando o desenvolvimento seguro de softwareAllyson Chiarini
O mundo atual está vivendo uma revolução no quesito aplicações onde cada vez mais temos temas como mobilidade, big data e consumerização, neste contexto a segurança da informação tem papel fundamental para garantir a mitigação de risco de exposição de informações. Atualmente o tema espionagem corporativa ou política está em volga devido ao caso NSA, ou seja, estamos vivendo uma época onde o tema segurança é de vital importância para as corporações. Com uma curva crescente de demanda por novas aplicações atualmente a área de desenvolvimento é forçada a entregar as aplicações em tempo cada vez menor, levando em consideração isso para otimização de esforço no ciclo de desenvolvimento se faz necessário adotar soluções que mitiguem o risco de segurança de informação em tempo de desenvolvimento. A família AppScan vem para endereçar este ponto, onde ela além de otimizar o processo de testes na disciplina de segurança de informação ela garante uma constante atualização em relação as ameaças correntes.
QUALIDADE, SEGURANÇA E CONFIABILIDADE DE SOFTWAREFabiano Souza
Uma visão geral sobre segurança e qualidade de software
Foco na importância da integração de práticas de segurança ao ciclo de desenvolvimento de software.
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferreira.
Webinar sobre este assunto também disponível em http://www.blog.clavis.com.br/webinar-20-as-principais-vulnerabilidades-em-aplicacoes-web-owasp-top-10-2013/
Microservices tornaram-se o tema mais quente na arquitetura de software durante o ano passado, e muito pode ser dito sobre os seus benefícios. Mas, existem inúmeros desafios relacionados a implementação e propagação de segurança no contexto destes componentes. Esta palestra abordará como realizar os cenários de autenticação e autorização com microservices, cobrindo tecnologias como OAuth2, JSON Web Token, utilizando a plataforma do Spring Cloud Security afim de integrar-se com aplicações Spring e/ou Java EE.
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
ASP.Net Performance – A pragmatic approach - Luis PaulinoComunidade NetPonto
Nesta sessão abordamos a performance de Sistemas de Informação desenvolvidos na plataforma ASP.NET com recurso a SQL Server com SGBD. Iremos explicar como surgem os problemas de performance em sistemas com alguns anos de existência e qual a abordagem a tomar, quando temos utilizadores insatisfeitos.
Abordaremos também alguns casos de sucesso no mercado a nível de sistemas de alta disponibilidade e como o mercado tem evoluído. De uma forma geral, pretendemos demonstrar técnicas de análise/tuning de performance em ASP.NET e sua evolução ao longo das várias versões, como também algumas técnicas de requisitos para obtenção e estruturação da informação.
Finalmente, o objetivo passa por divulgar procedimentos, técnicas e ferramentas que sirvam como uma referência que possam ser úteis caso surjam problemas de performance nos nossos sistemas de futuro, entre os quais : Do’s & Dont’s, Systematic Tuning, ASP.NET Trace, VS Profiling Tools, SQL Profiler entre outros.
Apresentação do Nuno Caneco sobre Utilização de Mock Objects em Testes Unitários na 29a Reunião Presencial da Comunidade NetPonto em Lisboa (http://netponto.org).
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
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.
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