SAFECode e PCI SSC discutem a evolução do software seguro
9 de dezembro de 2020
Este post apareceu originalmente no PCI Security Standards Council Blog. Visite o post aqui.
Quando o PCI Security Standards Council (PCI SSC) desenvolveu seu Software Security Framework (SSF) há alguns anos, ele se baseou na expertise de uma força-tarefa de segurança de software. Como parte dessa força-tarefa, a SAFECode,juntamente com outros parceiros do setor, desempenharam um papel fundamental no desenvolvimento da estrutura e de seus padrões.
SafeCode é um fórum global do setor onde líderes empresariais e especialistas técnicos se reúnem para trocar insights e ideias sobre a criação, melhoria e promoção de programas de segurança de software escaláveis e eficazes. Neste blog, entrevistamos Steven B. Lipner, Diretor Executivo da SAFECode,e Troy Leach, SVP, Diretor de Engajamento da PCI SSC para discutir a evolução do desenvolvimento de software e a abordagem do setor para garantir a segurança do software.
Quanto a indústria depende de software e software de terceiros?
Steven Lipner: Software é a base da indústria moderna. Quase todas as organizações, grandes e pequenas, dependem de produtos de software comercial. E os sistemas de software específicos do setor são amplamente utilizados em indústrias que vão do varejo à manufatura. Organizações menores normalmente dependem de software licenciado, enquanto organizações de médio e grande porte usam uma mistura de software licenciado e interno desenvolvido. Hoje, cada vez mais organizações dependem de serviços em nuvem que, por sua vez, dependem do software do provedor de serviços. Um fator importante hoje é o surgimento de uma cadeia de fornecimento de software: tanto desenvolvedores internos quanto comerciais muitas vezes dependem de software, incluindo software de código aberto, que eles não se desenvolveram.
Troy Leach: Isso é especialmente verdade para o software de pagamento. Nossa indústria abraçou muitas inovações modernas para aceitar pagamentos. Temos visto um crescimento significativo no uso de serviços em nuvem para aceitação de e-commerce e desenvolvedores de terceiros para o desenvolvimento de aplicativos de pagamento móvel. Também vimos a adoção geral de arquiteturas e funções de software mais complexas do que as arquiteturas de pagamento mais simplistas do passado.
Como o desenvolvimento de software evoluiu nos últimos 5 anos?
Steven Lipner: Existem quatro tendências que são uma parte importante do desenvolvimento de software:
- Dependência de uma cadeia de fornecimento de software, especialmente incluindo código aberto.
- Dependência de serviços em nuvem e provedores de serviços para complementar ou substituir o desenvolvimento interno e o gerenciamento de sistemas e software.
- Adoção de processos de desenvolvimento seguros. Isso cresceu embora não seja universal.
- Adoção de modelos de desenvolvimento rápido, como DevOps e Agile, que permitem às equipes de desenvolvimento adicionar novos recursos e atender às novas necessidades do cliente em horas ou dias, em vez de meses ou até anos.
Troy Leach: Lembro-me de como muitas arquiteturas foram relativamente descomplicadas quando lançamos nosso padrão e programa PA-DSS no PCI Council. A maioria dos aplicativos de pagamento só tinha um punhado de atualizações todos os anos e o desenvolvimento desses aplicativos de pagamento era geralmente proprietário. Hoje, vemos atualizações para a grande maioria dos aplicativos de pagamento acontecendo com muito mais frequência e aproveitando códigos fora da prateleira e serviços de terceiros para incluir a aceitação de pagamentos em um conjunto maior de funções.
Como a abordagem do setor para garantir a segurança do software mudou ao longo dos anos? Em outras palavras, como garantimos o software no passado e como precisamos assegurá-lo no futuro?
Steven Lipner: Houve uma grande mudança nas abordagens à segurança do software nos últimos 15 anos ou mais. Historicamente, as organizações enfatizavam recursos de segurança, como criptografia e autenticação baseada em senha, e então alguns usaram testes de penetração ad hoc para detectar e eliminar alguns erros de design e implementação. A partir do início dos anos 2000, algumas organizações começaram a integrar ferramentas, técnicas e treinamento em seus processos de desenvolvimento de software para que os desenvolvedores fossem responsáveis pela construção de softwares seguros contra ataques, além de estarem funcionalmente corretos e funcionando bem. As organizações mais maduras incorporaram a análise de causas básicas de vulnerabilidades descobertas e a melhoria contínua com o objetivo de eliminar ou mitigar classes inteiras de vulnerabilidades de segurança durante o desenvolvimento, em vez de corrigir problemas um de cada vez depois de serem descobertos no campo.
Troy Leach: Isso também tornou a avaliação do software de pagamento mais difícil de avaliar através dos modos tradicionais, já que o software é desenvolvido a partir de diversos grupos de desenvolvedores e através de vários métodos. Isso exigiu que a indústria adaptasse como determinamos a eficácia da segurança para proteger os dados de pagamento, bem como o acesso ao ambiente onde ocorre o processamento de pagamentos.
Na sua opinião, quais são as semelhanças e diferenças entre o NIST Secure Software Development Framework e o PCI Software Security Framework?
Steven Lipner: Ambas as estruturas reconhecem que a criação de software seguro é, antes de tudo, um processo que a equipe de desenvolvimento ou organização deve criar e aderir. E ambos reconhecem a importância de integrar ferramentas seguras de desenvolvimento, treinamento de desenvolvedores e melhoria contínua no processo de desenvolvimento de software. Como seria de esperar, a estrutura do NIST é muito geral, enquanto a estrutura do PCI é um pouco mais direcionada para desenvolvedores de software no setor de cartões de pagamento.
Troy Leach: Concordo com Steve que o reconhecimento de um ambiente em mudança, abordagem e resultado destinam-se a ser muito semelhante entre os dois quadros. O PCI Council tem um foco menor no software de pagamento predominantemente no setor privado. Nosso objetivo é fornecer às empresas uma maneira de verificar independentemente a segurança e a proteção dos dados de pagamento, testando os recursos de segurança das organizações de desenvolvimento de software.
Em que o SAFECode está funcionando no que se refere à segurança do software? Como essas estruturas estão sendo usadas pela indústria e como elas ajudam a criar essa garantia?
Steven Lipner: SAFECode publicou vários guias de práticas recomendadas e cursos de treinamento que podem ajudar organizações e desenvolvedores individuais a fazer um trabalho melhor na construção de software seguro. Nosso “Fundamental Practices for Secure Software Development” é um guia amplamente utilizado para integrar a segurança no processo de criação de software e é citado em vários lugares em todo o SSDF NIST. Também lançamos documentos sobre grandes questões, incluindo cadeia de fornecimento de software e modelagem de ameaças, bem como uma série de posts curtos em blogs sobre tópicos que vão desde o papel de “campeões de segurança” dentro de uma organização de desenvolvimento até “testes em fuzz” para segurança de software a questões associadas à transição para algoritmos de criptografia resistentes a ataques de computadores quânticos. Esses recursos são amplamente citados e usados em todo o setor, e continuamos a criar mais com base nas necessidades e experiências de nossos membros no desenvolvimento seguro de software.
Troy Leach: Minha esperança é que, à medida que o PCI Council expande o tipo de software que pode ser avaliado através de nossa Estrutura de Segurança de Software, continuamos a receber feedback valioso de nossa Força-Tarefa de Segurança de Software, que tem boa representação dos membros do SAFECode. Eu sei que, durante o lançamento anterior, Steve pessoalmente foi fundamental para ajudar a moldar nossa perspectiva com suas recomendações, juntamente com seus colegas da SAFECode, e espero que essa colaboração continue.
Quais são as práticas que os desenvolvedores de software precisam aplicar para garantir que o que eles estão fornecendo é seguro para os clientes?
Steven Lipner: O documento SAFECode Fundamental Practices é uma grande introdução às práticas que os desenvolvedores devem aplicar. Em alto nível, as duas coisas que eu priorizo são (1) para que as organizações possam aceitar relatórios externos de vulnerabilidades em seus softwares, remediar essas vulnerabilidades, realizar análises de causas básicas e atualizar seus processos, ferramentas e treinamentos para evitar que erros semelhantes ocorram e (2) para que as organizações tenham um inventário completo de componentes de terceiros que incorporem em seus softwares e possam aprender e responder a vulnerabilidades em esses componentes.
Troy Leach: Do nosso ponto de vista, nosso Secure Software Lifecycle Standard complementa as mesmas práticas de segurança estabelecendo bons processos e uma metodologia consistente para quando e como o risco e a segurança relacionada são considerados ao longo da vida útil do software de pagamento. Isso ajuda a indústria de pagamentos a melhorar a consistência nos processos de gerenciamento de software e fornece transparência para aqueles que dependem das práticas dos desenvolvedores de software.
Quais são as principais coisas que os clientes devem fazer para verificar se o software que compram foi desenvolvido com segurança?
Steven Lipner: Procure evidências públicas de um compromisso com o desenvolvimento seguro. Se um fornecedor em potencial não tem uma maneira fácil e não ameaçadora para alguém relatar uma vulnerabilidade de software, provavelmente é uma boa ideia encontrar outro fornecedor. Se uma organização tem um site que fala sobre seu compromisso com o desenvolvimento seguro e a maneira como ele vai sobre esse processo, isso é um sinal de que eles estão realmente comprometidos com a segurança do software. Certificações de conformidade com algumas normas podem fornecer informações úteis se as normas exigirem a implementação real de práticas seguras de desenvolvimento – o PCI Secure Software Standard e o Secure Software Lifecycle Standard são dois exemplos. Tais certificações podem ser especialmente úteis para a avaliação de fornecedores de serviços em nuvem.
Troy Leach: Esse é precisamente o objetivo do nosso programa de avaliação: identificar e promover boas práticas de segurança e o reconhecimento da avaliação independente. Isso dá aos comerciantes, provedores de serviços e outros que selecionam qual software de pagamento usar maior transparência e confiança sobre como os dados de pagamento estão sendo protegidos.
Quais são alguns recursos disponíveis que o SAFECode e o PCI SSC desenvolveram sobre este tópico?
Steven Lipner: O site SAFECode inclui um monte de material sobre desenvolvimento seguro. Consulte os centros de recursos nos Centros de Recursos – SAFECode e material de treinamento no SAFECode Training.
Troy Leach: Você pode aprender mais sobre o PCI Secure Software Standard and Secure Software Lifecycle Standard, baixando-os da nossa Biblioteca de Documentos on-line. Outros recursos úteis incluem nossos FAQs de Estrutura de Segurança de Software PCI, SSF At-A-Glance e transição do PA-DSS para os documentos do PCI Software Security Framework. Atualmente, estamos oferecendo treinamento informativo e de certificação para o Secure Software Lifecycle Assessor e Secure Software Assessor.