Introdução: Contexto Agile, SDLC
Formas de organização/trabalho ágil se tornaram muito populares nos últimos anos. Tanto para desenvolvimento de Software quanto para desenvolvimento de sistemas. Metodologias Ágeis focam em processos flexíveis e adaptativos no processo de desenvolvimento. Metodologias ágeis focam em reuniões, colaborações e interações sobre os processos e ferramentas. Extremamente adaptável a mudanças durante a fase de desenvolvimento.
A partir daí, começamos a entender a esteira de desenvolvimento de software: SDLC. Foi apontado que vale mais a pena considerar a segurança do projeto, desde o início da esteira do que no final. Pois, no final podem ser encontrados problemas e brechas que custam muito mais caro do que se tivesse sido detectadas no início do projeto.
Falhas de Segurança & Problemas
Independente da metodologia utilizada podemos reduzir o ciclo de desenvolvimento em: Planning, Design, Implementation, Testing, Maintenance.
Existe uma relação que aponta que quanto mais tarde a vulnerabilidade for detectada, mais caro será para o projeto. Recomenda-se então que seja implementando o que chamamos de : S-SLDC ou Esteira de desenvolvimento de Software Segura!
Isso significa, que é adicionado novas fases e processos durante a SDLC para garantir que o desenvolvimento seja acompanhado do início até a entrega final para o cliente. Com esses novos processos, a S-SDLC implementa novas etapas de segurança que dificultam vulnerabilidades. Os processos mais comuns da S-SDLC são:
Requisitos, Modelagem de Ameaças, SAST, DAST, Validação e Treinamentos
Ao implementar esses processos a chance de surgirem vulnerabilidades no final da esteira são drasticamente reduzidas. O que agrega valor e segurança ao projeto!
Essas etapas podem ser executadas em ordem ou em paralelo. Principalmente, a etapa de treinamento: essa deve ocorrer em paralelo para maior proveito!
Requisitos de Segurança
Nesta primeira fase são analisados os requisitos do projeto.
Essa fase se relaciona com a fase de Planejamento da SDLC.
É durante a fase de concepção, aquela primeira apresentação do projeto que se deve envolver os especialistas em segurança.
Nessa fase, já podemos ter uma ideia do rascunho da arquitetura do sistema, a função do sistema, APIs que integram, dados que irá transmitir, receber e processar.
Durante essa fase, os principais apontamentos de segurança serão para passar as boas práticas e recomendações para cada Framework, plataforma e linguagem que será utilizada. Definir como os dados serão armazenados e tratados. Recomendo elaborar aquele check-list de perguntas básicas, por exemplo:
Entender se a aplicação em questão lidará com dados pessoais de clientes, os chamados PII.
É necessário entender também se o projeto em questão fará parte do escopo de algum regulatório.
É sempre bom olhar todo o perímetro de segurança que será abrangido pela nova aplicação.
Os especialistas de segurança realizarão apontamentos de segurança durante a etapa de análise de requisitos.
Os requisitos podem ser usados como uma Checklist, que pode ser instanciada em Tickets de Boards Agile(exemplo: Asana, Pivotal Tracker, Trello).
Uma vez a arquitetura definida, projetada e desenhada seguimos para as próximas etapas.
Modelagem de Ameaças
Nessa fase o especialista de segurança irá analisar a superfície de ataque do projeto, por onde um possível usuário com más intenções poderia tentar se infiltrar no sistema para obter alguma vantagem? Após isso, definir um grau de risco, por exemplo: baixo, médio ou alto. Essa fase, se relaciona com as etapas de análise de requisitos e desenho do projeto.
Risco = Probabilidade x Impacto.
Essa é a fórmula amiga de todos que desejam calcular o risco de alguma ameaça que possa vir ocorrer dentro do projeto. Durante a modelagem de ameaças deve se levar em consideração todo o tipo possível de ameaça, inclusive as de intrusão física aos dados.
Existem várias metodologias para se usar para modelar ameaças e riscos, em segurança da informação. Uma delas é o S.T.R.I.D.E
O Stride é um anagrama para as seis principais ameaças que comprometem os seis pilares da segurança da informação.
Durante essa etapa cabe aos especialistas de segurança realizar uma metodologia escolhida para modelar as possíveis ameaças dentro da superfície de ataque. Mapear todo o escopo, identificar possíveis vetores de ataques e definir proteções para evitar brechas de segurança.
Nessa etapa o diagrama de fluxo de dados(DFD) do projeto ajuda bastante para todos terem uma visão clara e objetiva do escopo do projeto.
Entender: Por onde ocorre a entrada de dados, saída de dados canal de transmissão dos dados.
Aqui o nível de proteção por camadas é sempre recomendado: Firewall, IPS, IDS, SOC, WAF, etc.
Quanto mais sensível forem os dados trabalhados no escopo do projeto maior deverá ser a quantidade de camadas de segurança implementadas.
Modelagem de ameaças é sobre compreender os possíveis vetores de ataque. Após realizar o desenho da modelagem com base no DFD/Arquitetura do projeto, a modelagem deverá ser entregue de forma transparente aos envolvidos no desenvolvimento do projeto. É extremamente importante salientar que essas duas primeiras fases devem ser realizadas ANTES da fase de testes do projeto.
Análise estática de código (SAST)
Conforme a etapa de desenvolvimento do sistema for chegando ao fim, o código vai ficando mais estável e é aí que se inicia a próxima etapa da S-SDLC: Análise estática de código ou SAST.
Essa etapa tem como objetivo encontrar bugs a nível de código: bugs simples, mas que podem causar prejuízo se entregue ao cliente.
Ferramentas de SAST devem ser incluídas na pipeline de deploy, elas scaneiam todo o repositório do código que foi passado e geram um relatório de vulnerabilidades: baixas, médias e altas.
Muitas ferramentas, além de apontar o erro em si também já mostram as possíveis soluções.
Vale ressaltar que esses scanners muitas vezes encontram falsos-positivos, e por isso as vulnerabilidades devem ser analisadas tanto por segurança quanto pelos desenvolvedores do projeto.
Que tipo de erros um SAST pode me gerar?
Ele pode identificar entradas e saídas de dados inseguras que possam resultar num XSS, por exemplo.
Ausência de um ponto-CSRF, alguma credencial no código, etc
Análises SAST são facilmente automatizadas utilizando ferramentas como o Jenkins.
Um exemplo de ferramenta SAST é o Sonarqube.
A maioria das ferramentas SAST, possui a versão Free e versões pagas.
A maior abrangência de linguagens geralmente necessita da versão paga. Vale a pena consultar o site do fornecedor para verificar se a ferramenta atende a Stack de desenvolvimento proposta no projeto.
A principal vantagem de se usar um SAST na pipeline do projeto é conseguir identificar, e já resolver os primeiros Bugs e erros do sistema antes que eles sejam entregues ao cliente e causarem prejuízos financeiros para a empresa.
O SAST é um forte aliado tanto do time de segurança quanto os especialistas de Qualidade de Software.
Bonus: Análise de dependências para códigos Open-Source
Ainda falando sobre SAST é importante ressaltar o uso de dependências Open-source caso você use alguma no código de um projeto. Se você utiliza dependências Open-Source, como ter conhecimento se essas dependências não estão vulneráveis?
Ferramentas que checam dependências nos mostram as versões conhecidas sem vulnerabilidades de dependências Open-source.
Logo, durante a fase de SAST é bom aplicar também uma análise de dependências.
Verifique se sua ferramenta SAST já não possui esse módulo. Assim como o SAST essa etapa também pode ser automatizada.
Análise dinâmica de código (DAST)
A análise dinâmica também ocorre durante a fase de Testes, após o código já estar pronto. Geralmente é executada no ambiente de testes do projeto.
Se, SAST é uma análise estática, DAST é uma análise dinâmica.
Ou seja, ele roda uma instância do projeto e tenta identificar possíveis brechas de segurança mais comuns.
Basicamente o DAST executa os testes mais simples de segurança.
É necessário utilizar ferramentas DAST confiáveis.
Uma delas é o ZAP, que é Open-Source!
Testes de DAST ocorrem de forma Black-Box(Testando sem contexto e conhecimento prévio) e podem ser automatizados na esteira tal como o SAST, sendo executado em paralelo ou logo após o SAST.
O DAST irá identificar vulnerabilidades de baixa complexidade de exploração, o ideal para evitar ataques de Script Kiddies.
SAST/DAST se complementam e ambos ajudam a garantir qualidade de software!
Validação
O Estágio de Validação deve ocorrer durante a fase de Homologação/Piloto do Projeto.
O projeto já passou por toda a esteira e agora os especialistas em segurança realizaram um Pentest, um teste de intrusão no projeto como um todo.
Esse teste simula um ataque Hacker, o time vai tentar se infiltrar no sistema.
Essa validação pode ser tanto White-Box quanto Black-Box.
Estando tudo OK, o projeto é entregue ao cliente com um alto nível de confiabilidade, agregando qualidade e segurança.
Treinamentos
Essa etapa deverá ocorrer sempre que possível, podendo ocorrer entre fases ou entre projetos.
A fase de treinamento é basicamente preparar desenvolvedores para desenvolver projetos de forma mais segura. Apresentando na prática os principais problemas e os mais comuns. Como evitar e principalmente difundir conhecimento de segurança entre a empresa.
Os treinamentos devem ser ministrados por especialistas de segurança e sempre seguindo as melhores práticas de mercado. Um exemplo é seguir a cartilha OWASP.
Os treinamentos não tem como objetivo transformar desenvolvedores em especialistas em segurança, mas sim instruir desenvolvedores para desenvolver de forma mais segura. É comum durante treinamentos novos talentos da área de segurança serem descobertos.
Conclusão
Neste artigo, eu apontei as vantagens de se ter uma esteira de desenvolvimento de software segura (S-SDLC).
Como ela funciona e agrega valor ao ser implementada na esteira de desenvolvimento de projetos.
A S-SDLC ajuda Mitigando e muito as chances de vulnerabilidades serem encontradas após o projeto ser entregue ao cliente.
Bibliografia
SDLC
S-SDLC
OWASP ZAP
SonarQube
STRIDE
Linkedin: https://www.linkedin.com/in/jo%C3%A3o-victor-vernieri-087ab3148/
