Garantindo desenvolvimento de software: NIST participa do desfile
O NIST Secure Software Development Framework (SSDF) é o mais recente padrão destinado a melhorar a segurança do software. Sua nova abordagem pode ajudá-lo a ter sucesso?
A versão original deste post foi publicada na Forbes.
Exatamente o que precisamos — mais uma “estrutura” para melhorar a segurança do software.
Já temos o PCI DSS (Payment Card Industry Data Security Standard), o BSIMM (Building Security In Maturity Model), o OWASP (Open Web Application Security Project), o SAMM (Software Assurance Maturity Model), o ISO (International Organization for Standardization), o SAFECode (Software Assurance Forum for Excellence in Code)— a lista continua.
E está prestes a ir em um pouco mais. O quadro nos trabalhos — um rascunho de white paper no momento — do Instituto Nacional de Padrões e Tecnologia (NIST), é chamado de SSDF, como em” mitigar o risco de vulnerabilidades de software adotando uma Estrutura segura de desenvolvimento de software (SSDF)”. Tornou-se público em 11 de junho e a janela de comentários está aberta até 5 de agosto.
O quadro recomenda 19 práticas, organizadas em quatro grupos:
- Prepare a organização.
- Proteja o software.
- Produzir software bem protegido.
- Responda a relatórios de vulnerabilidade.
Seguindo as práticas, diz o documento, “deve ajudar os produtores de software a reduzir o número de vulnerabilidades em softwares lançados, mitigar o impacto potencial da exploração de vulnerabilidades não detectadas ou não tratadas e abordar as causas básicas das vulnerabilidades para evitar recorrências futuras. Os consumidores de software podem reutilizar e adaptar as práticas em seus processos de aquisição de software.”
Recomendações, não mandatos
Está tudo bem, tudo bem. Um objetivo mais do que digno. Quem não gostaria de mitigar os riscos de vulnerabilidades de software? É que soa um pouco como emitir uma estrutura para controlar a velocidade dos veículos em vias públicas quando há dezenas de leis nos livros há décadas projetadas para fazer a mesma coisa.
Além disso, quaisquer que sejam as especificidades da versão final do NIST Secure Software Development Framework, serão recomendações, não mandatos. A NIST é uma agência federal, no âmbito do Departamento de Comércio, mas não é uma agência reguladora e, portanto, não tem influência para forçar o cumprimento do quadro.
E mesmo assim… talvez preencha um vazio. O objetivo do quadro proposto parece ser menos sobre tentar reinventar a roda e mais sobre reunir vários tipos de rodas de alta qualidade em um só lugar para que as pessoas que precisam de rodas possam decidir o que se encaixa em suas necessidades.
Consolidando as melhores práticas de segurança de software
De fato, as práticas referem-se fortemente aos múltiplos quadros listados acima, indicando que se trata de uma consolidação das recomendações de boas práticas existentes.
Como disse um dos coautores, Murugiah Souppaya, da divisão de segurança da computação do Laboratório de Tecnologia da Informação (dentro do NIST), disse: “O artigo facilita as comunicações sobre práticas seguras de desenvolvimento de software entre grupos em diferentes setores empresariais em todo o mundo, fornecendo uma linguagem comum que aponta para os setores da indústria existentes práticas específicas.”
Ele acrescentou que essa “linguagem comum” é destinada a ajudá-los a descrever suas práticas atuais. “Isso permitirá que eles definam a linha de base desejada e identifiquem áreas para melhoria”, disse ele.
É claro que nenhuma das estruturas existentes transformou a segurança do software até agora. Há manchetes diárias sobre violações ativadas por vulnerabilidades — às vezes desenfreadas — em aplicativos ou dispositivos controlados por software.
Portanto, mesmo que o NIST Secure Software Development Framework seja o melhor até agora, se as organizações não forem persuadidas a investir tempo e dinheiro para seguir as recomendações, é improvável que gere melhorias incrementais, não importa transformadoras, na segurança do software.
Tendo uma visão longa
Quais são as suas chances de quebrar esse precedente? Não é alto - pelo menos não no curto prazo - na visão de Sammy Migues.
Migues, cientista principal da Synopsys e coautor do BSIMM, disse que isso não significa que o SSDF NIST proposto não tenha valor potencial. “Sim, segui-lo ajudaria”, disse ele. “Mas quem vai segui-lo? Apenas aqueles para quem é obrigatório, e somente se forem auditados.”
E o número desses é provável que seja pequeno de fato. Migues observou que o NIST “não faz lei ou estabelece políticas. É uma organização de inovação para líderes de torcida e conscientização. Então, a menos que alguma outra organização que tenha a imprimatur da autoridade segure as pessoas para isso, é improvável que ela seja seguida”, disse ele.
O mercado — tanto público quanto privado — poderia exercer alguma influência, disse ele, se as entidades que colocam empregos para licitar fizessem uma estrutura de segurança de software como esta, uma parte do RFP (pedido de propostas). “Eles poderiam dizer: ‘Essa é uma das coisas que você tem que cumprir para conseguir o contrato’”, disse ele.
Mas dado o número de frameworks/padrões já existentes, é difícil ver como “mais uma seta no tremor” seria aquela que de repente interrompe o mercado assim.
Mesmo ambientes dinâmicos resistem à mudança
Parte do problema, disse ele, é que é difícil mudar as pessoas que estão definidas em seus caminhos, mesmo em uma indústria que está evoluindo tão rapidamente quanto a TI.
“Há algumas coisas que eu realmente gosto [na proposta]— uma delas é implementar uma ferramenta de apoio. Eles realmente colocaram o pensamento nisso — eles estão dizendo que você não pode simplesmente baixar coisas gratuitas. E colocá-las como tarefas reais, junto com quem deve pensar sobre elas, é útil”, disse ele.
“Mas todo gerente de desenvolvimento tem sua maneira de fazer as coisas. Você acha que algum deles vai olhar para isso e dizer: ‘Uau. Faço isso há 20 anos e tenho feito errado todo esse tempo! Preciso começar a fazer de forma completamente diferente? Sem chance.”
NIST SSDF incentiva mudanças incrementais
Ainda assim, se um quadro como esse entrar no sistema educacional, poderá produzir mudanças incrementais que se tornariam transformadoras com o tempo, disse ele.
“Não pode vir de um fornecedor, mas de terceiros neutros”, disse ele. “Se entrar em livros didáticos, cursos universitários e RFPs, então pode ganhar alguma tração com os órgãos reguladores.”
A NIST espera que a abordagem “de alto nível” de seu Secure Software Development Framework o torne mais palatável para um “público” de organizações com vasta diversidade de tamanho e verticais do setor. “O mais importante é implementar as práticas e não os mecanismos utilizados para isso. Por exemplo, uma organização pode automatizar um passo específico, enquanto outra pode usar processos manuais”, diz o documento.
Para isso, Souppaya acrescenta que a intenção é que o SSDF NIST seja “personalizado por diferentes setores e organizações individuais para melhor se adequar aos seus riscos, situações e necessidades, pois as organizações terão diferentes metodologias de desenvolvimento de software, diferentes linguagens de programação, diferentes ferramentas, etc.”
Como o SSDF NIST poderia fazer o trabalho
Migues concorda que a flexibilidade é importante — que fazer o trabalho é mais importante do que como o trabalho é feito. Mas ele disse que muitas organizações podem não saber as opções para o “como”.
“O que está faltando são workshops — algo como uma sessão na RSA com CISOs — que orientariam as pessoas sobre como fazê-lo com base em suas necessidades”, disse ele. “Só porque eu compro um livro de receitas da Julia Child não significa que eu possa fazer as receitas se eu não sei cozinhar.”
Algo nessa linha pode estar em andamento. Os autores do white paper chamam de “ponto de partida” que pretendem expandir para abordar tópicos como “como um SSDF pode se aplicar e variar para diferentes metodologias de desenvolvimento de software”.
Esse trabalho futuro, disseram eles, “tomará principalmente a forma de casos de uso para que os insights sejam mais facilmente aplicáveis a certos tipos de ambientes de desenvolvimento”.
Autor: Taylor Armerding