O seu CMDB é um ativo de segurança. Está a tratá-lo como tal?

As Configuration Management Databases (CMDB) foram desenvolvidas para gerir a configuração das infraestruturas de IT: compreender as dependências entre ativos, planear alterações e gerir sistemas em grande escala. Durante anos, foram consideradas sobretudo uma ferramenta de IT. Hoje, porém, com ransomware cada vez mais agressivo, ataques frequentes à cadeia de fornecimento e um número crescente de potenciais pontos de entrada — cada dispositivo, aplicação ou ligação de rede através dos quais uma organização pode ser atacada —, o CMDB assumiu um papel mais estratégico: tornou-se um mapa atualizado dos riscos a que a organização está exposta diariamente.

Quando os dados de configuração estão incompletos ou desatualizados, criam-se «pontos cegos» — partes da infraestrutura que nem as equipas de IT nem as de segurança conseguem ver — e que podem ser explorados durante um ciberataque. Esta é uma questão que diz diretamente respeito tanto aos responsáveis de IT como aos profissionais de cibersegurança, que muitas vezes analisam a mesma infraestrutura através de ferramentas diferentes e com base em conjuntos de dados distintos.

De ferramenta de IT a verdadeiro mapa de risco

Na sua função tradicional, um CMDB é a fonte única e fiável de informação sobre a infraestrutura de IT.

Um CMDB regista cada componente que tem de ser gerido para prestar um serviço — o chamado configuration item (CI) —, como servidores, aplicações, dispositivos, serviços ou contratos, e, acima de tudo, mapeia as relações e dependências entre eles. É esta informação sobre as relações entre os diferentes elementos, mais do que uma simples lista de recursos, que distingue um CMDB de um inventário estático: quando um componente falha ou é alterado, o sistema mostra imediatamente que serviços são afetados.

Importa recordar que um CMDB não é o mesmo que IT Asset Management: são duas disciplinas complementares, mas distintas, e compreender bem essa diferença é essencial para construir um CMDB verdadeiramente fiável. Os mesmos dados que permitem planear uma alteração permitem hoje às equipas de segurança identificar que ativos estão expostos, onde se encontram e qual o seu nível de criticidade.

Aplica-se aqui um princípio básico da cibersegurança: não é possível proteger aquilo que não se sabe que existe. Um CMDB preciso proporciona exatamente essa visibilidade sobre os ativos (asset visibility), indispensável para que as restantes medidas de proteção sejam eficazes.

Pontos cegos: quando o CMDB deixa de refletir a realidade

O problema é que poucos CMDB estão verdadeiramente completos. E qualquer informação em falta ou desatualizada pode, mais cedo ou mais tarde, transformar-se num risco de segurança. Alguns cenários concretos ajudam a perceber como as lacunas de informação no CMDB podem criar vulnerabilidades.

Lacunas que se transformam em riscos

O primeiro cenário diz respeito aos endpoints que não estão registados. Um dispositivo que não consta do CMDB não recebe patches, não é monitorizado e fica fora dos controlos de segurança: para a organização, é como se não existisse — mas continua a representar um ponto de entrada desprotegido na rede empresarial.

O segundo diz respeito ao software não autorizado: aplicações instaladas fora dos procedimentos oficiais e sem o conhecimento da equipa de IT, que ninguém atualiza e que aumentam o número de potenciais pontos de comprometimento. Ou seja, ampliam a «superfície de ataque» — o conjunto de pontos e vulnerabilidades que podem ser explorados num ataque.

O terceiro diz respeito às integrações não documentadas: ligações entre sistemas criadas para responder a necessidades específicas, mas nunca registadas, que podem ser exploradas para propagar uma intrusão de um sistema para outro depois de as defesas do perímetro terem sido ultrapassadas — o chamado «movimento lateral».

Um exemplo particularmente ilustrativo é a aplicação urgente de um patch de segurança. Um analista identifica uma vulnerabilidade crítica num pacote de software, determina quais os ativos afetados e envia a lista à equipa de IT para que seja feita a correção. Mas, se os dados do CMDB não refletirem a realidade, a equipa de IT não consegue saber com certeza onde estão esses sistemas, e o processo fica bloqueado precisamente no momento mais crítico: quando a vulnerabilidade já é conhecida, mas ainda não foi corrigida. Um CMDB atualizado permite uma intervenção rápida e organizada; um CMDB desatualizado transforma-a num verdadeiro obstáculo.

Por que razão os dados permanecem incompletos

As lacunas de informação que descrevemos têm frequentemente a mesma origem: processos de discovery pouco flexíveis ou executados apenas periodicamente. Com a proliferação dos serviços cloud, dos dispositivos móveis e da Internet of Things (IoT), já não basta atualizar o inventário de tempos a tempos. O risco é deixar de fora do CMDB ativos expostos à Internet herdados de fusões e aquisições ou de empresas subsidiárias, dispositivos pessoais ligados à rede e equipamentos IoT e OT — tecnologias operacionais utilizadas em ambientes industriais onde nem sempre é possível instalar os agentes de software necessários à monitorização.

A isto junta-se o fenómeno do Shadow IT e, em particular, do Shadow SaaS: serviços cloud contratados diretamente por departamentos ou equipas sem supervisão central, criando pontos cegos difíceis de identificar e ainda mais difíceis de proteger. Em todos estes casos, o primeiro problema é a falta de visibilidade sobre os ativos — e, sem essa visibilidade, torna-se impossível protegê-los eficazmente.

O custo dos ativos não geridos

Os números confirmam a dimensão do problema. Uma investigação conduzida pela Sapio Research para a Trend Micro revelou que 74% dos mais de 2.000 responsáveis de IT e segurança inquiridos tinham registado incidentes causados por ativos desconhecidos ou não geridos. Quanto ao impacto, o Cost of a Data Breach Report da IBM revelou que mais de um terço das violações envolve «shadow data», ou seja, dados armazenados em sistemas não geridos. Estas violações demoram mais tempo a ser detetadas e contidas e, em média, têm custos mais elevados. Por fim, o estudo da TeamViewer sobre digital friction mostra a frequência com que surgem as condições que alimentam estes riscos: 66% dos trabalhadores lidaram, no último ano, com atualizações forçadas ou com ciberataques, como malware e ransomware.

O que é necessário para que um CMDB contribua para a segurança?

Para que o CMDB possa contribuir para a segurança da organização, é necessário cumprir alguns requisitos operacionais — os mesmos que distinguem um CMDB fiável de uma simples lista estática condenada a ficar desatualizada.

Os requisitos técnicos

O primeiro é a discovery contínua. Não uma fotografia periódica, mas uma análise permanente do ambiente de IT que permita identificar, quase em tempo real, novos dispositivos, software e alterações de configuração. É a única forma de acompanhar uma infraestrutura em constante mudança e manter uma visibilidade dos ativos que reflita o seu estado real.

O segundo é a reconciliação automatizada. Os dados detetados através da discovery devem ser comparados continuamente com os registos existentes no CMDB, sinalizando qualquer discrepância. Sem esta comparação sistemática, as diferenças entre o que existe efetivamente na infraestrutura e o que está registado no CMDB vão-se acumulando e, ao fim de pouco tempo, os dados deixam de ser fiáveis.

O terceiro é a integração com Vulnerability Management. Ligar o CMDB às ferramentas de deteção de vulnerabilidades permite saber imediatamente quais os ativos realmente afetados. Permite também decidir o que deve ser corrigido primeiro, não apenas com base numa pontuação técnica abstrata, mas tendo em conta a importância real do ativo: quão crítico é para as operações, quem é responsável por ele e que serviços dependem do mesmo. É aqui que o CMDB deixa de ser um simples repositório de IT e passa a ser uma ferramenta operacional de cibersegurança.

O quarto requisito, muitas vezes negligenciado, é definir claramente quem é responsável pela qualidade dos dados. Cada tipo de configuration item deve ter um responsável que garanta que a informação se mantém correta e atualizada ao longo do tempo.

Um investimento comum para IT e segurança

Modernizar o ITSM — e, em particular, o CMDB — significa melhorar simultaneamente a eficiência operacional e investir diretamente na segurança da organização. É uma questão que diz respeito tanto aos responsáveis de IT como aos profissionais de cibersegurança, porque ambos retiram valor da mesma base de dados.

Quando IT e segurança partilham uma única fonte de verdade, deixam de trabalhar com visões diferentes da mesma infraestrutura. A equipa de segurança passa a dispor do contexto de que necessita — que ativos existem, qual a sua criticidade e quem é responsável por eles — para avaliar o risco e definir prioridades de forma eficaz. A equipa de IT, por sua vez, pode intervir com confiança nos sistemas que estão realmente afetados. Em ambos os casos, reduzem-se também as áreas sem monitorização onde um incidente pode evoluir sem ser detetado.

Em conclusão, a precisão do CMDB é um indicador concreto da maturidade de uma organização em matéria de cibersegurança. Um CMDB atualizado e completo não melhora apenas a prestação de serviços: mostra até que ponto a organização conhece — e, por isso, consegue proteger — todos os dispositivos, aplicações e ligações que a podem expor a um ataque.

A visibilidade sobre os ativos proporcionada por um CMDB bem mantido continua a ser uma das defesas mais subestimadas à disposição das organizações. Tratá-lo como uma simples formalidade técnica significa desperdiçar uma capacidade de proteção que, em grande parte, já existe dentro da própria organização — e que deve tornar-se cada vez mais precisa, contínua e partilhada.

FAQs

1. Por que razão um CMDB é relevante para a cibersegurança?
   Porque fornece um mapa atualizado dos ativos e das respetivas dependências. Sem esta visibilidade, as equipas de segurança não conseguem saber com certeza o que devem proteger nem onde devem aplicar patches. Os ativos que não são identificados ou monitorizados acabam por permanecer expostos.
2. Que lacunas no CMDB criam riscos de segurança?
   Sobretudo endpoints não registados, software não autorizado e integrações não documentadas. Cada elemento ausente do CMDB escapa à monitorização, às atualizações e aos controlos, aumentando silenciosamente a superfície de ataque.
3. O que distingue um CMDB «orientado para a segurança»?
   Quatro requisitos: discovery contínua em vez de periódica, reconciliação automatizada entre o estado detetado e os dados registados, integração com Vulnerability Management e responsabilidades claramente definidas pela qualidade e propriedade dos dados.
4. CMDB e asset visibility: qual é a relação entre os dois?
   Asset visibility é a capacidade de saber que ativos existem e em que estado se encontram. Um CMDB preciso e continuamente atualizado é uma das principais ferramentas para garantir essa visibilidade, sendo, por isso, um pilar tanto do ITSM como da cibersegurança.