ALERTA 02/2022

[TLP:WHITE]

1. As vulnerabilidades em software são identificadas diariamente e atingem desde sistemas operacionais a aplicações que oferecem serviços. Com o intuito de diminuir a incidência de vulnerabilidades de alta severidade e o impacto dessas quando exploradas, a instituição precisa estabelecer critérios de “Segurity by design” em todas as fases de desenvolvimento.

2. Como os casos de vulnerabilidades são amplos e muitas vezes relacionados com a linguagem de codificação utilizada, recomenda-se, de imediato, a capacitação e preparação das equipes de desenvolvimento ou de responsáveis pela análise do produto adquirido em um processo de compra, tendo como objetivo principal:

- A capacidade de entendimento, pelos desenvolvedores, sobre os problemas típicos ligados à linguagem de codificação utilizada, para identificá-los e tratá-los.

3. A partir deste entendimento amplo, existem ferramentas específicas para análise de vulnerabilidades genéricas, como o caso dos DevSecOps, acrônico dos termos em inglês de Desenvolvimento – segurança – Operação, para mecanismos de esteira, com análises estáticas e dinâmicas. No entanto, como as possíveis correções identificadas no relatório não são realizadas de forma automática, deverão ser realizadas por desenvolvedores com o domínio e entendimento da vulnerabilidade acusada. Do exposto, recomenda-se:

- A utilização de ferramentas de verificação de código para identificação de vulnerabilidades.

4. Referências bibliográficas e boas práticas indicam Modelos com procedimentos baseados nos "Processos de ciclo de vida de desenvolvimento seguro" em tradução livre do Inglês "Secure Software Development Life Cycle Processes - SDLC Process".

5. Esses modelos de SDLC preconizam identificar ainda na fase de desenvolvimento e implementação da funcionalidade possíveis vulnerabilidades. Normalmente são montados "casos de abuso" para verificar como aquela aplicação poderia ser explorada e consequentemente fazer as correções necessárias.

6. Segundo o projeto OWASP, podemos definir "caso de abuso" como uma forma de usar uma funcionalidade não esperada por quem a desenvolveu, dessa maneira permitindo que um atacante modifique o comportamento da funcionalidade com intuito de explorar ou tirar vantagem dessa modificação.

7. A ações de identificação de vulnerabilidades não detectadas em ferramentas de análise são de difícil percepção, particularmente em desenvolvimento envolvendo BlockChain. Para tanto, normalmente, é necessária uma equipe multidisciplinar.
 
8. O OWASP OpenSAMM(Software Assurance Maturity Model) nos mostra um "overview" dos passos envolvidos na definição de um caso de abuso:

1) Descrição da funcionalidade de negócio pelo analista de negócio;
2) Enumeração dos ataques possíveis contra essa funcionalidade (Pentester ou AppSec);
3) Avaliação de risco de todos os ataques possíveis identificados (Analista de risco);
4) Filtragem dos ataques baseados na classificação de risco (consenso da equipe); e
5) Definição da lista de casos de abuso para a funcionalidade.

9. A partir da definição dos casos de abuso serão elencadas possíveis contramedidas para esses casos.

10. Os modelos de maturidade de desenvolvimento seguro são uma importante ferramenta para mitigar os impactos e a incidência de vulnerabilidades nas aplicações, consequentemente aumentando o nível de segurança cibernética das organizações.

11. Por fim, o CTIR Gov recomenda:

- Realizar o dimensionamento e seleção da equipe de desenvolvimento ou terceirização de etapas de desenvolvimento atentando para os conceitos de "Security by Design";

- Capacitação de pessoal na área de desenvolvimento seguro;

- Uso de ferramenta de verificação de código para identificação de vulnerabilidades; e

- Identificar e adotar boas práticas para desenvolvimento seguro durante todo o ciclo de vida do software, aplicando as correções antes da ação de codificação ou durante a operação, com emissão de patches ou atualizações.

12. Para mais informações recomendamos a leitura dos links em fontes abertas:

https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html
https://www.cisa.gov/uscert/bsi/articles/knowledge/sdlc-process/secure-software-development-life-cycle-processes
https://www.opensamm.org/explore/
https://owasp.org/www-pdf-archive/Benelux2017_-_Secure_Development_Training_deck.pdf

13. Lembramos ainda que compete aos órgãos e às entidades da administração pública federal comunicar imediatamente o CTIR Gov, por meio de suas equipes de prevenção, tratamento e respostas a incidentes cibernéticos, sobre a existência de vulnerabilidades ou incidentes de segurança cibernética que impactem ou que possam impactar os serviços prestados.

14. Recomenda-se fortemente que os alertas e recomendações do CTIR Gov sejam verificados em https://www.ctir.gov.br/alertas/.

Equipe CTIR Gov
[TLP:WHITE]