Nos dos últimos
artigos tratei do novo universo das aplicações em container e microserviços,
técnica padrão para desenvolvimento de aplicações nas empresas digitalizadas,
leia-se Amazon, Google e afins, porém ainda longe de dominar o mainstream.
No entanto, as várias vantagens não deixam dúvidas com relação ao futuro.
Estamos indo em direção acelerada a ela, parte do processo de digitalização da
economia. Por outro lado, vimos também que os containers podem ser um prato
cheio para disseminação de ameaças, tanto por seu ambiente novo assim como pela
dificuldade em protegê-lo com as tecnologias tradicionais de segurança.
Esse mês irei
abordar medidas de proteção que podem ser adotadas. O melhor documento que
conheço com as boas práticas para pessoas e processos é o documento 800-190 do
NIST, o instituto de padronização dos Estados Unidos, cujo título é Application
Container Security Guide. E o melhor de tudo é que é público, com acesso
livre. A conclusão ao ler o documento é que temos que voltar aos pilares
básicos de pessoas, processos e tecnologia. E é inevitável iniciar pelas
pessoas, ou, mais especificamente, os desenvolvedores.
O processo dinâmico
de desenvolvimento pode levar a alguns dos erros que mencionei mês passado,
como a geração de containers contendo vulnerabilidades e falhas de configuração
de seu sistema operacional incluído, assim como a falta de controle com o
consequente uso de containers comprometidos e que deveriam ser descartados.
Além disso, velhos problemas como erros de autenticação ainda permanecem. Ou
seja, tudo que desenvolvedores faziam, ou fazem, de errado nas aplicações tradicionais
pode ser repetido nas novas aplicações. A solução para os erros pessoais se
resolve com educação e processos.
A adoção de
processos visa a padronização de procedimentos, como já o sabemos, e é ainda
mais essencial em metodologias distribuídas e dinâmicas como a de que estamos
falando. Aqui também o NIST nos presta um grande trabalho, sendo indispensável
sua leitura. Entre os processos recomendados pelo órgão americano está o de
gestão de vulnerabilidades, gestão das imagens e containers, políticas de
configuração das imagens, controle de palavras chave em texto aberto, e
autenticação e autorização tanto de aplicações como de administradores.
O terceiro pilar é
o de tecnologia e não, não há um produto único que dê conta do trabalho. Se algum
fornecedor dizer isso a você, recomendo mudar de empresa. Aliás, não sei se
hoje em dia ainda existe problema de segurança que possa ser tratado por
produto único. O ambiente está tão complexo, e os vetores de ataque tão
diversificados, que confiar em produtos é meio caminho para ser comprometido.
O documento do NIST
chega a tratar de algumas tecnologias, e a primeira delas é a detecção de
vulnerabilidades, porém, claro, adaptada ao mundo dos containers. Eu a
colocaria, junto com treinamento e boas práticas, no capítulo de prevenção.
No entanto seria
ingenuidade achar que em 2019 só a prevenção é suficiente. Segurança por
prevenção sempre foi um sonho dos profissionais de segurança, mas infelizmente
a realidade sempre foi impiedosa. Precisamos alterar nosso mindset para
o pensamento de que a prevenção irá reduzir significativamente os ataques
bem-sucedidos, deixando-nos com menos invasões a detectar. Aqui estou falando
de invasões mesmo, não de tentativas. Temos que começar daí, do pior,
lembrando-se da máxima “ausência de evidência não é o mesmo que evidência de
ausência”. Quais seriam então as partes que deveriam compor uma arquitetura de
segurança para aplicações, lembrando que são técnicas e não produtos.
Monitoração de
malware na imagem do container
A detecção e
resposta a malware é atualmente uma tecnologia consolidada, porém formatada
para instalação em sistemas operacionais, no caso, os servidores onde os
containers e sua infraestrutura são executados. A necessidade de EDR no
servidor host continua necessário, mas também precisamos de monitoração na
imagem do container. Malware pode também ser detectado pelo comportamento
errático, levando-nos à próxima técnica.
Monitoração de
comportamento das aplicações
Assim como o
tráfego de redes, o comportamento das aplicações pode revelar muita coisa.
Mesmo ataques dia-zero podem ser detectados através de comportamento suspeito
similar ao de ataques já conhecidos. Um produto, portanto, deverá possuir um
banco de dados já consolidado, além de um bom mecanismo de análise.
Inteligência artificial e análise cognitiva começam também a serem
incorporadas.
Monitoração da
comunicação em rede
A detecção de
anomalias de comportamento no tráfego é um dos principais indicadores de
comprometimento, e podem indicar um ataque desconhecido ou um desvio de conduta
em curso. Há vários produtos que realizam essa tarefa, que deve ser executada
no ambiente de nuvem. Tal qual o comportamento de aplicações, o êxito dessa
tecnologia está na base de comportamento e capacidade de análise das
informações obtidas, principalmente quando lembramos que o tráfego será
criptografado.
Aplicar o conceito
de zero-trust para as aplicações
Normalmente ligamos
o conceito de zero-trust a usuários, o que não está errado, mas ele vai muito
mais além, englobando também a rede e aplicações. Uma aplicação deveria possuir
o mínimo acesso possível e necessário para executar sua função. Um
comportamento típico de ataque é o acesso lateral, ou seja, entre aplicações
sem conexão hierárquica entre elas. Uma política zero-trust impede esse tipo de
comunicação, mesmo que ela seja detectada pela monitoração de rede e aplicação.
Uma cada não anula a outra, na verdade se complementando.
Enforcement de políticas
Políticas de
microsegmentação, ou segmentação por software, como por exemplo comunicações de
aplicações que violem políticas de PCI, devem ser criadas. Os próprios produtos
auxiliam na criação das políticas ao mapear os acessos de aplicações
reconhecidas como integras.
* publicado na Revista RTI - Dezembro/2019
Nenhum comentário:
Postar um comentário