Mostrando para os times de desenvolvimento é possível ter uma SSDLC sem dor de cabeça.
Segurança da Informação para produtos é visto como um atraso para entregas e como uma barreira para os desenvolvedores. No entanto, a segurança de aplicações é um recurso a mais para os times de desenvolvimento e pode inclusive economizar retrabalho.
Uma esteira ágil consiste em um processo de desenvolvimento que exige uma comunicação super eficaz entre produtos, desenvolvimento, teste e infraestrutura de aplicações. São essas diferentes partes que formam as tão conhecidas squads/tribos/times. Porém não é comum ter uma pessoa responsável por segurança dentro dessa esteira, ou até mesmo como parte dos times.
Na cultura agilista, velocidade ou volume de entregas podem ser erroneamente julgados mais importantes que a qualidade delas. Por conta disso, vem surgindo o efeito de inserção de desenvolvedores que tenham conhecimento focado em segurança, que saibam realizar testes de invasão e entendam como cada ataque funciona a nível de código.
Esteira de desenvolvimento SSDLC
Uma esteira tradicional que segue os conceitos da agilidade é chamada de SDLC — sigla para Software Development Life Cycle, literalmente traduzido como Ciclo de Vida de Desenvolvimento de Produto.
A diferença entre SSDLC e SDLC é que a palavra Secure, de Segurança, antes do Ciclo de Desenvolvimento, não somente inclui o time de segurança, e sim prevê as necessidades de segurança que uma aplicação necessita.
As atividades gerenciadas pelo time de segurança de aplicações (AppSec) estão diretamente conectadas ao escopo de atuação das squads. Ou seja, o AppSec deve entender como funciona o produto como um todo, desde as regras de negócio aplicadas a ele até a atmosfera atrelada ao usuário final do produto. Deve entender como um atacante analisaria a aplicação, quais seriam as ações tomadas por ele, todos os pontos relacionados a informações críticas e à utilização de dados.
O AppSec é o especialista em segurança que vai integrar o seu time, auxiliar na seleção de tecnologias para desenvolvimento, auxiliar nas melhores práticas de desenvolvimento seguro e defender a tomada de decisões que envolvam segurança no contexto de desenvolvimento e arquitetura.
Explicando os conceitos de uma esteira SSDLC:
Durante o planejamento e análise, são definidos os principais requisitos do negócio que a aplicação sustenta, com estes requisitos também são definidos os parâmetros técnicos para o desenvolvimento da aplicação. Em paralelo a esse processo, é importante conhecer as aplicações que serão integradas a esta, a segurança aplicada nos endpoints, se haverá acesso por terceiros, entre muitos outros detalhes que são colocados na visão de segurança quando são aplicados os requisitos de segurança. Eles são escritos pelo AppSec e apresentados para a equipe.
Durante o design, é super importante o papel de segurança. Ela vai utilizar a sua característica de atacante para entender as possíveis ameaças na aplicação e mapear vetores de ataque, trazendo à equipe as prioridades e pontos de atenção relacionados à modelagem de ameaças.
Durante o desenvolvimento, pontos importantes são ressaltados quanto à validação dos requisitos e validação da implantação de forma correta. Para isso, utilizamos o SAST e entendemos a real necessidade de uma revisão de código com foco em segurança e refatoração de código. Como conceito mínimo de segurança em código, o AppSec pode auxiliar a filtragem de correções necessárias e definir sua urgência, ainda mais conhecendo as necessidades e backlog do time.
Em paralelo, o AppSec e o Redteam podem realizar testes de segurança da aplicação, validando os testes descritos na modelagem de ameaça ou realizando testes não previstos, trazendo resultados quanto aos controles implementados a nível dinâmico de aplicação.
Posterior ao processo, com a geração de logs eficazes guiados pelo AppSec, o produto estará em conformidade com grande parte das normativas vigentes de segurança, e será facilitada a resposta a incidente, em caso de uma vulnerabilidade ser explorada por um terceiro ao processo.
Tipos de atacantes e a comunicação
Cada companhia possui uma estrutura. É importante entender como é a estrutura de segurança interna para que seja avaliado o grau de segurança atrelado à validação dos softwares e aplicações.
Seguindo a mesma linha de pensamento, muitas pessoas acreditam que os atacantes possuem somente um perfil: aquele que procura invadir uma empresa para benefício somente monetário. Mas esse é um grande equívoco. Podemos e devemos classificar o tipo de atacante que estamos sujeitos a receber em nossa aplicação. Contando com essa informação, podemos prever os ataques e nos protegermos.
A seguir, dou alguns exemplos de atacantes que uma aplicação pode receber:
Hackers White Hat
Esses são os hackers bonzinhos. São especialistas em segurança computacional que se concentram em fazer testes de penetração e outras metodologias, de modo a garantir que os sistemas de informação de empresas são realmente seguros. Esses profissionais de segurança de TI usam um arsenal em constante evolução para enfrentar os hackers “ruins”.
Hackers Black Hat
Esses são os hackers malvados, geralmente chamados simplesmente de hackers. O termo costuma ser usado especificamente para designar criminosos que invadem redes ou computadores, ou ainda que criam vírus de computador. Hackers do tipo Black Hat continuam a agir mais rapidamente do que os do tipo White Hat. Eles costumam encontrar o caminho que oferece menor resistência – seja erro humano ou negligência – ou criam um novo tipo de ataque. Puristas usam o termo “crackers” para se referir aos hackers do tipo Black Hat. A motivação desse tipo costuma ser financeira.
Para ilustrar o conteúdo SSDLC, temos o Zupcast #46 pode te ajudar a entender sobre as Black Hat e White Hat.
Hackers Gray Hat
Esses são hackers que não usam suas habilidades para benefício próprio, mas não operam de forma totalmente legal. Por exemplo, um hacker que invada o sistema de uma empresa para revelar uma vulnerabilidade e poste a descoberta na internet pode, em última instância, estar fazendo algo positivo para os clientes daquela empresa. Mas, por outro lado, comprometeram um sistema sem permissão.
Se este mesmo hacker solicitar dinheiro da empresa para não revelar a vulnerabilidade, nesse caso o limite seria transposto e ele estaria agindo como um hacker do tipo Black Hat, operando totalmente para ganho próprio.
Script Kiddies
Esse termo pejorativo se refere a hackers Black Hat que usam programas baixados da internet para atacar redes, alterar sites para se tornarem conhecidos. Alguns “script kiddies” se enquadram na categoria “Green Hat”: são amadores curiosos que desejam aprender e um dia se tornar hackers de verdade.
Hacktivists
Hackers que almejam fazer parte de mudanças sociais.
A revelação de transgressões, ou ganhos religiosos ou políticos motivam alguns hacktivists. Por exemplo, durante a Primavera Árabe, alguns hacktivists trabalharam para oferecer métodos de comunicação seguros a grupos ameaçados, além de acesso a páginas da web censuradas por governos.
Hackers patrocinados por governos
Governos ao redor do mundo estão conscientes de que é útil a seus objetivos militares estarem bem posicionados no mundo on-line. O ditado costumava ser “quem controla os mares, controla o mundo”. Passou a ser “quem controla os ares, controla o mundo”. Hoje o controle do ciberespaço é decisivo. Hackers patrocinados por governos não têm limite de tempo e contam com orçamento para focar civis, empresas e outros governos.
Hackers espiões
Empresas contratam hackers para que se infiltrem em concorrentes e roubem segredos comerciais. Esses hackers podem tentar ataques externos ou podem conseguir empregos para agir como infiltrados. Hackers espiões podem usar táticas semelhantes às de hacktivists, mas suas únicas meta são atingir os objetivos do cliente e obter benefícios monetários.
Whistleblowers (Insider)
Trata-se de uma pessoa inserida em uma organização que usa seu acesso a sistemas para vazar informações que podem ser preocupantes. Por outro lado, esta pessoa inserida pode ter más intenções ou querer vingança contra a empresa. Esses hackers podem acessar informações para vender segredos comerciais ou conseguir emprego em outras empresas. Nesse caso, são chamados de “Infiltrados mal-intencionados”.
Ciberterroristas
Geralmente motivados por crenças religiosas ou políticas, esses hackers tentam criar medo e caos ao interromper o funcionamento de serviços cruciais de infraestrutura. Os ciberterroristas são, de longe, os mais perigosos e contam com uma ampla variedade de habilidades e objetivos. Em última instância, a motivação de ciberterroristas é espalhar medo, terror e violência.
White Hat em conjunto com RedTeam
Essa é a divisão de segurança de aplicações que é responsável pela validação de controles da empresa por meio de testes de intrusão. Essas 2 áreas são fundamentais e atuam como áreas irmãs, pois quando o RedTeam encontra algo, o AppSec é responsável por auxiliar a equipe de desenvolvimento quanto à sua correção e dar um direcionamento sobre conteúdo.
Vantagens do AppSec
Ter um AppSec junto ao time de desenvolvimento traz diversos benefícios quanto à agilidade e divisão de tarefas, já que ele possui habilidades específicas de segurança. O AppSec pode agilizar o apontamento de tecnologias vulneráveis, arquiteturas inseguras e, assim, aumentar o desempenho da equipe. Ou seja, uma vez que o AppSec está lá para apontar pontos de segurança, o time precisa se preocupar menos em pensar neles e pode se ocupar de outras entregas.
Como conta também com um papel próximo ao de um Agile Master, o AppSec tem como característica facilitar a interface de comunicação entre os times que possam viabilizar integrações, ferramentas seguras já desenvolvidas e saberá quais são os pontos de atenção relacionados à aplicação que será integrada. Conjunto a esse processo, também auxilia na correção de códigos vulneráveis e implanta soluções na esteira que facilitam a revisão de código em questão, também conhecidas como SAST (Static Application Security Testing) — ou análise de código fonte — e DAST (Dynamic Application Security Testing) — ou análise de aplicação automatizada.
Desempenho x Retrabalho
Todo desenvolvedor sofre cobranças relacionadas à agilidade e qualidade de suas entregas. Porém vale ressaltar que, caso ocorra uma fraude ou invasão originada por uma vulnerabilidade no software (qualquer que seja o porte), existe o risco de a empresa perder milhões e/ou ter sua reputação prejudicada.
Os atacantes não visualizam somente os vetores de ataque que todos enxergamos. Um dos pontos cruciais para todo bom hacker é avaliar o escopo da empresa e entender brechas em aplicações que não são tão reconhecidas, bem como outros controles expostos e encontrados por um bom trabalho de reconhecimento e coleta de informações sobre a empresa. Levando em consideração todos esses pontos, a segurança de aplicações é uma camada — não a única, mas uma das mais importantes —, que pode reduzir a possibilidade de um atacante gerar prejuízo à sua empresa.
Quando se trata de aplicações, realizar um planejamento inserindo a equipe de segurança de aplicações é fundamental. É visível que, durante a discussão do time, assuntos como visão de segurança podem ser disseminados entre equipes, de forma a evangelizar a segurança por toda a organização.
O maior prejuízo possível quanto a horas de serviço ocorre quando a equipe desenvolve uma funcionalidade e recebe um feedback de outras áreas apontando falhas às quais podem existir um enorme retrabalho atrelado. É preferível que o processo seja realizado de forma amigável e direcionado para, juntos, um time de especialistas desenvolver um produto blindado e com um desempenho que seja referência de mercado.
Segurança é um pilar e conhecimento é sempre um plus
É claro que, para todo desenvolvedor, ter uma skill de segurança é um diferencial muito visado em meio a um cenário de informação. Independentemente do contexto de desenvolvimento de software, o desenvolvedor precisa entender que um sistema de hospital pode ser alvo de um ataque tanto quanto um banco ou um e-commerce.
Indo ao encontro de seu escopo de atuação, deve-se absorver segurança da mesma forma como são absorvidas informações vindas de produto e infraestrutura (DevOps). Ela deve ser tratada com a mesma importância dentro das empresas e no processo de formação dos desenvolvedores, independentemente da linguagem ou do contexto em que estão inseridos (Back-end, Front-end, Full Stack e até UX).
É essencial que todo desenvolvedor ao menos conheça o conceito de OWASP, um dos fundamentos em segurança da informação, e que entenda ao mínimo como funcionam o TOP 10 — as principais vulnerabilidades de aplicação comumente encontradas:
Segue como conclusão desse artigo sobre SSDLC que devemos manter uma boa comunicação com a nossa equipe de segurança de aplicação.
Como diz Sarah Zatko em sua palestra Web application security: 10 things developers need to know: de nada adianta somente formar especialistas se a grande maioria dos bugs são inseridos pelos profissionais de formação regular, que muito provavelmente nunca tiveram qualquer contato com segurança. Agora seria a hora inserir segurança na esteira e evangelizar as pessoas, aplicar treinamentos e demonstrar a responsabilidade em todas as camadas.
Curtiu o conteúdo sobre SSDLC? Deixe seu comentário! Até a próxima!
