É hora de mudar a segurança cibernética para a esquerda

É hora de mudar a segurança cibernética para a esquerda

Existem muitas ameaças sofisticadas e atores de ameaças no mundo hoje para que a segurança cibernética continue sendo da competência da TI.

Imagem em destaque

À medida que a complexidade das operações de TI continua a aumentar, a necessidade de transferir a segurança cibernética para o desenvolvimento e o pipeline de CI/CD está rapidamente se tornando uma prioridade para muitas organizações de TI.

É claro que a ideia de mudar a segurança para a esquerda não é nova. Foi introduzido pela primeira vez como já na década de 1970 (muito antes de a primeira linha do código do malware ser escrita). Foi também o que deu origem à ideia do DevSecOps e ao conceito anterior de segurança por design. Mas esta abordagem ao desenvolvimento de software ainda é relativamente nova e só foi adotada por cerca de terço das organizações de desenvolvimento hoje.

Embora a segurança por design se concentre principalmente em garantir código seguro, com o DevSecOps um conjunto predeterminado de serviços de segurança é implementado quando um aplicativo ou carga de trabalho é implantado. Isso inclui coisas como segurança de rede, autenticação multifator, direitos de acesso e assim por diante.

Para garantir que os aplicativos de produção sejam tão seguros quanto possível no futuro, ambas as abordagens provavelmente terão que ser adotadas em massa por desenvolvedores e organizações de TI.

A adoção é lenta por vários motivos

Os desenvolvedores tradicionalmente contam com equipes de segurança e operações de TI para proteger o código que criam. Mas há muitas coisas acontecendo hoje que tornam isso difícil. Ataques cibernéticos sofisticados e hiperdirecionados, ambientes de computação híbridos e em contêineres e uma borda de rede porosa e difícil de definir tornam impossível tratar a segurança cibernética como uma reflexão tardia.

A rápida adoção de arquiteturas de microsserviços e computação sem servidor na nuvem criou um ambiente onde a compreensão das arquiteturas de rede e das dependências de aplicativos fica exponencialmente mais difícil a cada ano. A pressão sobre os desenvolvedores para produzir código, gerar atualizações e criar novos recursos e funcionalidades também aumenta a cada ano, à medida que as organizações recorrem às tecnologias digitais.

As altas expectativas, aliadas à adoção generalizada de Agile e DevOps, significam que os desenvolvedores estão contando com provedores de plataforma e infraestrutura como serviço e com a implantação de infraestrutura como código para mover mais código para a produção mais rápido do que nunca. Os desenvolvedores também dependem de conjuntos de ferramentas mais complexos para realizar seu trabalho.

Para adicionar mais lenha à fogueira está a falta de conhecimento sobre segurança cibernética entre muitos desenvolvedores e uma escassez crítica de profissionais qualificados em segurança cibernética no lado de TI. A preocupante ascensão do ransomware como o malware mais utilizado na década de 2020 significa que os ataques cibernéticos estão a ficar mais caros, tanto em termos económicos como de reputação.

TI precisa de maior visibilidade

Do ponto de vista da TI, a falta de visibilidade sobre como o código é desenvolvido e onde está sendo implantado (inclusive em ambientes de desenvolvimento distantes dos servidores de produção) cria pontos cegos que podem dificultar saber por onde começar ao se recuperar de um ataque de segurança cibernética.

Embora existam livros de execução projetados especificamente para ajudar as equipes de resposta a incidentes a descobrir o que está acontecendo, a velocidade com que novos recursos e funcionalidades são introduzidos na produção significa que a documentação nem sempre está atualizada ou mesmo disponível.

Outro bom motivo para começar a mudar a segurança cibernética para a esquerda é que os ambientes de desenvolvedores são cada vez mais vistos como bons alvos para a infiltração de criminosos cibernéticos na organização. Os desenvolvedores usam muito código-fonte aberto e cadeias de ferramentas complexas e automatizadas que, quando mal configuradas ou mal utilizadas, podem abrir a porta para que invasores obtenham uma posição segura dentro da organização.

Os desenvolvedores também podem esquecer e deixar os ambientes de teste em execução muito depois de terem cumprido seu propósito. O Hack da cadeia de suprimentos da Solarwinds de 2020 é um bom exemplo do que pode acontecer quando hackers obtêm o código-fonte antes do lançamento.

Depois que o ambiente de desenvolvimento estiver comprometido, será muito mais fácil para os invasores fazerem coisas como incorporar ransomware nos backups da organização. Quando a TI tenta se recuperar do ataque de ransomware, descobre que os dados necessários foram corrompidos ou reinicia o ataque a partir de malware armazenado nos backups.

3 passos para mudar para a esquerda

Muitas organizações ainda fazem testes de segurança pouco antes de o software ser lançado para produção. Os testes contínuos de vulnerabilidade introduzidos anteriormente no SDLC resultam em software com menos bugs e falhas de segurança. Ao mover esse processo para o pipeline de CI/CD, duas coisas acontecem: há maior garantia de que os padrões de segurança da organização serão seguidos e isso envolve os desenvolvedores mais cedo no SDLC.

A primeira etapa é realizar testes automatizados de segurança estática de aplicativos sempre que o código for compilado. A maioria das organizações que realizam CI/CD já terá as ferramentas e estruturas implementadas para fazer isso acontecer. Certifique-se de que os resultados da verificação sejam carregados em um banco de dados de componentes vulneráveis ​​disponibilizado por meio de um painel do mecanismo de CI de forma rastreável até a construção original. Isso ajudará com fins de conformidade, relatórios e pesquisa, ao mesmo tempo que lhe dará uma avaliação constante de sua aplicação.

Em seguida, certifique-se de realizar estudos de análise de composição de software para entender todas as dependências de aplicativos e de terceiros no momento da construção.

Por fim, é uma prática recomendada fazer testes dinâmicos de segurança de aplicativos.

Se você ainda não estiver praticando essas práticas, pode ser caro começar. Mas eles manterão sua organização fora das manchetes. Isso vale cada centavo.

Fonte: BairesDev

Conteúdo relacionado

Tillbaka till blogg

Lämna en kommentar

Notera att kommentarer behöver godkännas innan de publiceras.