0
0
De acordo com um estudo recente,apenas uma minoria de desenvolvedores de software está realmente trabalhando em uma empresa de desenvolvimento de software. Isso significa que hoje em dia literalmente cada empresa constrói software de alguma forma ou de outra.
Como profissional na área de segurança da informação, é sua tarefa proteger informações, ativos e tecnologias. Obviamente, o software construído por ou para sua empresa que está coletando, transportando, armazenando, processando e finalmente agindo sobre os dados da sua empresa, é de alto interesse. As práticas seguras de desenvolvimento devem ser aplicadas no início e a segurança deve ser testada durante toda a vida útil do software.
Dentro do (ISC)² corpo de conhecimento comum para CISSPs, a segurança do desenvolvimento de software é listada como um domínio individual. Vários padrões e práticas que abrangem a segurança no Ciclo de Vida do Desenvolvimento de Software (SDLC) estão disponíveis: ISO/IEC 27024:2011, ISO/IEC TR 15504 ou NIST SP800-64 Revision 2, para citar alguns.
Todos os acima pedem a avaliação contínua e o controle de artefatos no nível do código-fonte, especialmente no que diz respeito aos padrões de codificação e enumerações de fraqueza comum(CWE),mas apenas mencionam brevemente testes estáticos de segurança de aplicativos(SAST)como uma possível maneira de resolver essas questões. Na busca por possíveis ferramentas concretas, o NIST fornece SP 500-268 v1.1 “Fonte Code Security Analysis Tool Specification Specification Versão 1.1”.
Em maio de 2019, a NIST retirou o já mencionado SP800-64 Rev2. O NIST SP 500-268 foi publicado há mais de nove anos. Isso parece ser sintomático para uma questão subjacente que vemos: os padrões não podem acompanhar o ritmo acelerado do desenvolvimento e da mudança no campo.
Um bom exemplo é o alvorecer da linguagem de desenvolvimento Rust, que aborda uma das principais fontes de problemas de segurança apresentados pela linguagem clássica C++ – ou seja, o gerenciamento da memória. Os principais players do campo, como Microsoft e Google, viram grandes vantagens e anunciaram que focariam os desenvolvimentos futuros em relação à Rust. Embora as normas mencionem linguagens de desenvolvimento superiores às outras, nem os mecanismos utilizados por Ferrugem nem a própria Ferrugem são mencionados.
No campo da Análise de Código Estático, as informações no NIST SP 500-268 não estão erradas, mas o artigo simplesmente não menciona avanços no campo.
Vamos discutir brevemente dois aspectos: Primeiro, o amplo uso do software de código aberto nos deu uma visão sobre uma vasta quantidade de mudanças de código fonte e o raciocínio por trás deles (segurança, desempenho, estilo). Além disso, temos visto aumento das capacidades de poder da CPU para processar esses dados, acompanhados de melhorias algorítmicas. Hoje em dia, temos um grande lago de dados de treinamento disponíveis. Para usar nossa empresa como exemplo, a fim de treinar nosso modelo subjacente apenas para C++, estamos digitalizando mudanças em mais de 200.000 projetos de código aberto com milhões de arquivos contendo história rica.
Em segundo lugar, na última década, testemunhamos enormes avanços no aprendizado de máquina. Vemos ferramentas como GPT-3 e seus aplicativos em código-fonte sendo amplamente discutidos. Classicamente, a análise do código fonte estático era o domínio da IA simbólica — fatos e regras aplicadas ao código fonte. O reino do código fonte é perfeitamente adequado para esta abordagem, uma vez que o código fonte do software tem uma sintaxe e gramática bem definidas. A desvantagem é que essas regras foram desenvolvidas por engenheiros, o que limita o ritmo em que as regras podem ser geradas. A ideia seria automatizar a construção de regras usando aprendizado de máquina.
Recentemente, vemos pesquisas no campo da aprendizagem de máquina sendo aplicadas ao código fonte. Mais uma vez, vamos usar nossa empresa como exemplo: Usando a grande quantidade de mudanças no código aberto, nosso sistema procura padrões conectados à segurança. Ele apresenta possíveis regras a um engenheiro, juntamente com os casos encontrados no conjunto de treinamento — tanto conhecidos quanto fixos, bem como desconhecidos.
Além disso, o sistema suporta parâmetros nas regras. Os possíveis valores para esses parâmetros são coletados automaticamente pelo sistema. Como exemplo prático, a análise de manchas segue os dados recebidos para seu uso dentro do aplicativo para garantir que os dados são higienizados antes do uso. O sistema aprende automaticamente possíveis fontes, higienização e funções de pia.
De volta aos Artigos Especiais do NIST: Com a retirada do SP 800-64 Rev 2, os usuários foram apontados para nist SP 800-160 Vol 1 por enquanto até que um novo white paper atualizado seja publicado. Isso foi no final de maio de 2019. A natureza desses artigos é apenas descrever práticas recomendadas de alto nível, listar alguns exemplos e permanecer bastante vago na implementação concreta. No entanto, os documentos são a base para revisões e auditorias. Dada a importância do campo, parece que falta um componente importante. Também é hora de pensar em processos que nos ajudem a acompanhar o ritmo da tecnologia.
FONTE: HELPNET SECURITY