Agilidade e PCI DSS - Como conciliar os dois?
•
1 gostou•403 visualizações
Apresentação realizada no Agile Brazil 2014. Relato da implantação de um ciclo seguro de desenvolvimento alinhado com conceitos do framework Scrum.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (15)
Agilidade e PCI DSS - Como conciliar os dois?
- 27. Obrigado!
Notas do Editor
- Agile e PCI-DSS - É possível conciliar os dois? Nesta apresentação eu pretendo passar um pouco da nossa experiência com a implantação de um ciclo de desenvolvimento seguro aderente ao PCI DSS. Foi um processo que durou mais de um ano. Foram varias discussões, tentativas e aprendizado que resultou no que será apresentado aqui Alguém aqui esta passando ou já passou por este processo?
- PCI – Payment Card Industry Antes começar, vamos contextualizar rapidamente o PCI DSS - Concelho de grandes bandeiras de cartão de credito MasterCard, Visa, Amex e JCB que tinham programas em comum que visavam reduzir a incidencia e custo com fraudes de cartão Certificação PCI-DSS – Data Security Standart - Tendo a primeira versão publicada em 2004 -
- Data card breachs Tem por objetivo reduzir a possibilidade de fraude através da implantação de controles que aumentem a proteção de exposição de dados sensíveis de cartão de crédito - Relatório Verizon: 4x mais risco de ter dados vazados por empresas que não cumprem o requisito 6 do PCI
- PCI-DSS - Necessário para organizações que: processem, transmitam ou armazenem dados de cartão de crédito - Dados de cartão: PAN, CVV, Nome do portador, Data de validade, trilha magnetica … O que contempla o PCI-DSS (data security standart) - 12 requisitos (uso de firewall, controle de acesso físico, armazenamento de dados, desenvolvimento seguro) - 289 controles Em realção ao desenvolvimento de software, o Requisito 6 (desenvolvimento seguro) é o que vamos tratar no momento
- O primeiro susto - Olha o tamanho disso! - Quando o auditor comentou sobre o nosso status de complaince quado começamos o processo essa foi a nossa cara Quando inciamos este processo nos deparamos com uma aparente rigidez que não fazia parte do nosso modelo de trabalho; por exemplo a formalização de todos os passos realizados para uma entrega
- A realidade da empresa - Dinamismo - deploys frequentes, varias vezes ao dia Muitas pessoas envolvidas - + de 60 devs - Diversos produtos - alto de risco de engessar o desenvolvimento existente e impactar no fluxo atual
- Além disso, houve um impacto inicial com os próprios de desenvolvedores Resistência Frase dita por um dev durante as primeiras discussões sobre a implantação de um ciclo seguro de desenvolvimento
- RISCO ALTO: Segurança é tratada de forma implícita ou sem a devida atenção necessária no processo de desenvolvimento Fora o próprio risco de falha de segurança que poderiam existir ou serem inseridas, Havia o risco de não cumprimento dos controles do PCI, que necessitam de uma série de evidências, o que requer uma disciplina na execução do processo
- Considerando esta realidade e o esforço aparentemente grande que teríamos para estar compliance, vem a pergunta: Por onde começar?
- Simplificação - Primeiro entender o fluxo do cartão de crédito “Onde o cartão não passa, não é escopo” A implementação de uma segmentação efetiva da infraestrutura e aplicação por onde os dados trafegavam, nos ajudou a - Reduzir a quantidade de devs afetados - Chegamos a +- 5
- Concientização - Foi necessário vencer a resistência para iniciar uma adoção das novas práticas de segurança - O time precisa passar a entender os beneficios de um processo de segurança atrelado ao desenvolvimento - Inicialmente investimos em um treinamento externo, para alinhar os conhecimentos. - Não deu muito certo em relação a passagem de conhecimento ( instrutor “Hacker”)
- Mas.. Tivemos um efeito positivo, o time resolveu assumir a passagem de conhecimento dali pra frente - não queriam mais 8 horas daquela enganação O time passou a estar interessado em se envolver na formulação do processo - por iniciativa própria foi realizado uma “varredura” na base de código em busca de potenciais vulnerabilidades
- Com o engajamento inicial do time, começamos criação do SDLC: - Passamos a ter alinhamentos frequentes para o entendimento e pesquisa - de praticas de mercado - Preocupação com alinhamento metodologico (não deveria ferir os principios de agilidade do time)
- Ponto Focal - Os membros do time são referencias para tratar sobre o SDLC - Facilita o processo de adoção pois não dependia de apenas uma pessoa
- Scrum e SDLC Como resultado, tivemos que aplicar algumas alterações no nosso processo Scrum:
- Planning - As estimativas deve passar a considerar as atividades relativas ao SDLC - A modelagem de ameças deve ser feita antes do planejamento pois o seu resultado pode afetar diretamente uma solução
- Backlog - O Backlog conta também com estórias de “segurança” - Exemplo: correção de uma vulnerabilidade que venha a ser reportada - Priorização: o P.O deve estar alinhado para poder realizar a priorização dos itens relacionados a segurança - O conceito de pronto passa a considerar todos os passos do SDLC
- SDLC Aplicado na Dafiti - Visão geral do SDLC utilizado atualmente
- Modelagem de ameaças - Inclusão de segurança desde o início do ciclo de desenvolvimento (fazer referencia ao requisito 6.3) - Avaliação de vulnerabilidades de um requisito sob o ponto de vista de um agente malicioso 1. Determinar objetivos e escopo de avaliação; 2. Reunir informação relevante; 3. Listar ameaças; -Ganho financeiro; -Roubo de informações sigilosas; -Acesso a dados sensíveis; 4. Determinar riscos; 5. Determinar contramedidas. -
- Modelagem de ameaças - Inspiração no modelo “Threat Modeling Express – InfoQ” adequado para times ageis - Modelo mais leve de modelagem e que pode ser utilizado por um time pequeno, sem um profissonal de segurança dedicado
- Desenvolvimento seguro * Boas práticas - Validar todas as entradas de dados -Controle todas as saídas de dados - Blindar a aplicação de fontes de dados externas - OWASP top 10 - Insumos da modelagem de ameaças
- Secure Code review - Validação dos apectos de segurança por um desenvolvedor diferente do qual construiu o código - Ferramenta utilizada para facilitar - Exemplos de situações identificadas: Tentativa de colocar codigo de terceiros na pagina do checkout
- Teste de segurança automatizado - Bateria de testes para identificação de vulnerabildades que não tenham sido identificadas nas validações manuais anteriores -Simplicação do QA, pois a validação de segurança é feita em uma etapa anterior - Ferramentas OpenSource: Arachini, W3af, Webscarab
- Gestão de mudança - Formalização de qualquer alteração na base de código pertencente ao escopo de avaliação - Composta por análise de impacto, risco, procedimento de implantação e reversão, identificação dos envolvidos e aprovação da mudança. - Planilha com registro; futuramente integrado ao Jira para melhor controle
- Deploy - Separação de reponsabilidades quanto ao acesso a produção; definição clara de quem tem acesso - Faz parte do conceito de pronto
- Próximos passos - Aumentar a quantidade de times utilizando SDLC - Mais automação - Inicio da revisão para o modelo 3.0