Se você passou os últimos 13 anos em um retiro espiritual, preciso te contar que o Verizon Data Breach Investigations Report (DBIR) é o relatório mais longevo sobre o estado da segurança da informação. Ele é altamente respeitado devido à solidez e rigor da metodologia estatística utilizada, a qualidade dos diferentes times responsáveis por ele ao longo do tempo, e à grande massa de dados oriunda da própria Verizon e centenas de contribuidores.
Eu acredito fortemente na necessidade de se tomar mais decisões baseadas em dados em segurança da informação. Muito que se passa por sabedoria em nossa área me lembra da época pré-científica da evolução da medicina. Precisamos de estudos bem escritos, bem executados e baseados em massas de dados representativas, como é o caso do DBIR e outros como os publicados pelo excelente time no Cyentia Institute. Estes relatórios são um bálsamo para meus olhos cansados, e me dão esperança no futuro de nosso mercado.
Neste artigo, vou destacar a minha seleção pessoal e subjetiva das duas principais lições aprendidas para segurança de nuvem na recém-publicada edição 2020 do DBIR.
Controle de Acessos e o Control Plane
Existe um tema claro no DBIR de 2020 sobre o uso de credenciais obtidas de forma ilegítima. Vamos ver o que o relatório tem a dizer sobre a freqüência com que credenciais vazadas ou roubadas foram usadas nos incidentes analisados:
“… it must be said that Hacking and even breaches in general (at least in our dataset) are driven by credential theft. Over 80% of breaches within Hacking involve Brute force or the Use of lost or stolen credentials.”
DBIR de 2020 página 19
“Cloud breaches involved an email or web application server 73% of the time. Additionally, 77% of those cloud breaches also involved breached credentials.”
DBIR de 2020 página 27
Uma das partes mais relevantes de segurança de nuvem é a existência de todo uma nova superfície de ataque representada pelas APIs do provedor de nuvem, comumente chamada de control plane. Diferentemente das interfaces de gerenciamento de infraestrutura de TI on-premises, o control plane é sempre acessível via Internet, compartilhado para todos os clientes do provedor de nuvem, amplamente conhecido e documentado.
Isso reforça como é crítico o controle de acesso a estas APIs. É muito mais fácil para um atacante fazer uso de credenciais de control plane de nuvem do que de serviços de gerenciamento de TI on-premises. Afinal de contas, interfaces on-premises tipicamente estão dentro de um perímetro, variam de empresa para empresa quanto a tecnologia, versão e sabor utilizados, e também onde ficam. Apenas encontrar os alvos internos pode ser uma atividade trabalhosa e barulhenta para um atacante, mas esse não é o caso com APIs de provedores de nuvem.
Você precisa se planejar para lidar com abuso do control plane, e implementar controles preventivos e detectivos:
- Usar duplo fator de autenticação para todos;
- Conceder o mínimo privilégio possível para usuários e sistemas, combinado ao uso de guard rails que limitem ações perigosas mesmo que privilégios excessivos sejam concedidos ou obtidos indevidamente;
- Integrar o control plane com um provedor de identidades / diretório de forma a aproveitar monitoramento e revogação de acessos existentes;
- Limitar o armazenamento de credenciais de control plane de longa duração em endpoints de usuário;
- Detectar a divulgação acidental de credenciais, como por exemplo desenvolvedores incluindo-as em repositórios de código ou usuários copiando-as para páginas de phishing;
- Logar e fazer deteção de logins e atividades privilegiadas suspeitas;
- Implementar monitoramento e controles eficazes nos endpoints de usuários com acesso privilegiado ao control plane.
Herrar é umano
O DBIR de 2020 ressalta que erros, configurações incorretas e a publicação acidental de informações estão frequentemente presentes em incidentes e vazamentos de dados:
“Errors definitely win the award for best supporting action this year. They are now equally as common as Social breaches and more common than Malware, and are truly ubiquitous across all industries.”
“In Figure 14 you can see that since 2017, Misconfiguration errors have been increasing. This can be, in large part, associated with internet-exposed storage discovered by security researchers and unrelated third parties. While Publishing errors appear to be decreasing, we wouldn’t be surprised if this simply means that errors formerly attributed to publishing a private document on an organization’s infrastructure accidentally now get labeled Misconfiguration because the system admin set the storage to public in the first place.”
DBIR de 2020 página 14
Lembre-se que os dados acima incluem tanto incidentes na nuvem quanto on-premises. Se os números fossem separados por estes dois tipos de ambiente, minha impressão é que os números de nuvem seriam piores do que os do on-premises.
O ecosistema de nuvem é relativamente novo, incrivelmente complexo, e ainda está evoluindo de forma absurdamente rápida. Ele é ao mesmo novo e desconhecido para muitos profissionais de TI e segurança, mas enganadoramente simples de utilizar para o desenvolvimento e publicação rápida de novos projetos e sistemas.
Eu anedotalmente encontrei diversos incidentes em que eram os próprios desenvolvedores, com pouca ou nenhuma experiência em operações ou segurança, que foram colocados como responsáveis por criar e operar a infraestrutura na nuvem.
Essa combinação de fatores torna os erros e más configurações particularmente frequentes e impactantes na nuvem. Buckets S3 e bases de dados expostas sem autenticação como Elasticsearch tem aparecido bastante em manchetes e notícias sobre incidentes relevantes. Mas configurações menos conhecidas como imagens de disco públicas podem ser tão ou mais danosas do que estas.
Em parte, isto ocorre porque a nuvem não é simplesmente uma versão SaaS das mesmas coisas que nós fazíamos no on-premises. Mudanças mais profundas na forma de trabalho estão envolvidas. Por exemplo, é normal que seja Operações a área formalmente responsável pela aplicação de patches. Mas no caso de aplicações rodando em containers, é Desenvolvimento que escreve os Dockerfiles e decide quais pacotes de sistema operacional serão instalados dentro dos containers. Problemas similares ocorrem com Infrastructure as Code também.
Cloud é uma área nova e fascinante, mas a oferta de talentos é muito pequena e investimentos nesta área são urgentemente necessários para que as pessoas saibam o que estão fazendo. Eu acho extremamente chocante o pouco investimento que as organizações têm feito em bons treinamentos hands-on de segurança de nuvem. Mais chocante ainda é a quantidade de material treinamento disponível que é puramente funcional, e que mesmo alguns dos melhores fornecedores na área ensinam as pessoas a usar cloud de forma claramente insegura.
As organizações devem atacar este problema em muitas frentes distintas:
- Garantir que há governança adequada para seus ambientes de nuvem, com uma visão atualizada de papéis e responsabilidades que vão impactar orçamentos, processos, ferramentas e auditorias;
- Treinar seus times de Operações, Desenvolvimento, Segurança e Auditoria em segurança de nuvem. Prefira treinamentos hands-on ensinados por profissionais de segurança da informação, como aqueles oferecidos por SANS, Securosis, Summit Route ou (momento jabá) Tenchi Security.
- Monitorar de forma contínua e automatizada as configurações de seus ambientes de nuvem, por exemplo usando uma solução open source ou comercial de CSPM;
- Logar e monitorar os ambientes de nuvem de forma a detectar acessos a dados expostos acidentalmente ou serviços configurados incorretamente, de forma que uma resposta rápida possa mitigar o impacto de incidentes.
Alexandre Sieira é o Fundador da Tenchi Security, e anteriormente foi Gerente Sênior e líder global de Gerenciamento de Produtos de Managed Security Services Analytics na torre de Detecção e Resposta da Verizon.
