Segurança da Informação

Porque “Segurança” deve amar e aprender “DevOps”

Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOAQuer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ? 

Esta semana, enquanto eu estava pesquisando qual tema escrever o próximo artigo, me deparei com um assunto bem relevante: Porque segurança da informação, deve amar e apoiar (e aprender) com o time de DevOps ?

Atualmente o time de segurança está se deparando com um novo mundo, e usando conceitos antigos para poder se adaptar ao conceito de Cloud. Junto a isso temos as metodologias SAST e DAST para validação de segurança de aplicações. Tais ferramentas, são usadas para testes de segurança de código aberto, projetadas para serem operadas dentro dos diversos pipelines de testes e implantação continua.

Agora pensando como uma pessoa bem pragmática, deveríamos de imediato pensar “Que maneiro”. Mas, Porque ? Temos neste momento um ajuste cultural perfeito. 

Quando você não está fazendo testes de segurança (no pipeline de implantação), acontecem todos os tipos de coisas ruins. Primeiro, os desenvolvedores não entendem os requisitos de segurança e precisam confiar em um especialista em segurança para fazer a revisão do código. Então, no final de um lançamento, eles precisam aguardar na fila para concluir seus testes, apenas quando as pressões do prazo são mais altas. Então, quando o inevitável conjunto de vulnerabilidades de segurança é encontrado, nunca há tempo suficiente para corrigi-los tão tarde no processo de implantação, etc. Isso sem falar em testes de performance, que em mais de 90% dos casos, vemos que um único teste completo de uma operação não é concluído até ajustar inúmeros serviços.

Devemos concordar, neste momento falo com os times de infraestrutura, desenvolvimento, segurança e mesmo com os executivos (Coordenadores e acima). Se não tivermos uma sinergia, com um status quo quase que pré-ordenados, teremos um fracasso completo. Ou, pior ainda, uma aplicação não escalável, insegura, e não documentada. Em resumo, resultado além do esperado (no minimo).

Esse tipo de resultado é comum, e estamos vivendo isso hoje em dia, quando as organizações, dos mais diversos tamanhos estão “indo para a nuvem”.

Devemos começar a usar a cabeça, além de simplesmente pentear o cabelo pessoal.

Para cada projeto de desenvolvimento de aplicativos voltado para a Internet, devemos exigir que outro desenvolvedor faça uma revisão de segurança do aplicativo com base em uma lista de verificação simples, em comum com as principais vulnerabilidades, unida ao time de segurança.

Como isso? Crie em conjunto, uma lista de verificação de revisão de segurança que um DESENVOLVEDOR poderia usar para realizar uma revisão de segurança, em oposição a um especialista em segurança. Este tipo de abordagem é util quando pedimos para uma segunda ou terceira empresa desenvolver o código.

Quando as revisões do código de segurança começaram a ser feitas por outros desenvolvedores (muitas vezes em outras empresas de terceirização), eles pareciam de repente se preocuparem muito mais com a segurança. Por quê?

Primeiro, a segurança agora era um problema de desenvolvedor. Os requisitos eram claros e compreendidos, podendo ser integrados ao processo de desenvolvimento. Escrever um código seguro era sua responsabilidade, em oposição a alguma pessoa de segurança arbitrária “validando” sua aplicação.

A lista de requisitos era perfeita? Provavelmente não, mas dado o estado da segurança do código hoje, muitas aplicações escritas agora ainda podem falhar esses testes simples. Acredite, existem falhas simples.

Mas o segundo motivo é ainda mais interessante. Uma vez que o teste foi feito por outros desenvolvedores, ninguém queria que outro desenvolvedor (um par!), gritasse suas falhas de codificação. Isso foi particularmente interessante quando a pessoa que revisou seu código poderia ser uma concorrente – um desenvolvedor terceiro que revisa outro código do desenvolvedor terceiro de outra companhia. Quantas vezes acontece isso ? É comum sejamos sinceros, uma empresa X contratada ficar de mi-mi-mi com outra empresa Y de outro time. Ou do mesmo =)

Avance rápido para o DevOps. Veja que este tipo de abordagem, este tipo de coisas simples, quando inserido num contexto CI/CD, com ferramentas e times orientados, é dar uma passo rumo a melhoria, e a excelência. O que estamos agregando ?

Estamos obtendo testes diários, no contexto de desenvolvimento, em sinergia de times, dentro do pipeline de implementação. Então, porque não deixar de mi-mi-mi e entender que o DevOps hoje deve se preocupar com segurança, além de operações e disponibilidade, bem como a integridade do pipeline de implantação. Este é o ajuste cultural perfeito para a segurança.

Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOAQuer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ? 

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.