O ambiente tecnológico de um fornecedor de gestão de dados de saúde havia evoluído ao longo de três anos, de uma implantação monolítica local para um ambiente híbrido composto por uma rede corporativa, um ambiente de infraestrutura AWS, servidores Windows para cargas de trabalho legadas e um cluster Kubernetes operado por um provedor de DevOps gerenciado para a aplicação do portal do paciente. O monitoramento de segurança do fornecedor havia evoluído junto com a infraestrutura (segurança de endpoints nos servidores Windows, monitoramento de segurança de AWS no seu SIEM, monitoramento de rede na rede corporativa), mas o cluster Kubernetes era uma zona cinzenta. O contrato de serviço do provedor de DevOps gerenciado incluía o monitoramento da saúde e do desempenho do cluster. O monitoramento de segurança do cluster, especificamente a segurança em tempo de execução, a aplicação das políticas de rede e a gestão de vulnerabilidades das imagens de contêiner, havia sido discutido durante a integração, mas não fora formalmente atribuído a nenhuma das partes. A equipe de segurança do fornecedor acreditava que o monitoramento do provedor de DevOps cobria tanto a segurança quanto o desempenho. A equipe do provedor de DevOps entendia que seu escopo era o monitoramento operacional, e não o monitoramento de segurança. Quando uma vulnerabilidade de fuga de contêiner em um dos contêineres da aplicação do portal foi explorada durante um teste de intrusão contratado pelo fornecedor, o testador conseguiu passar de um contêiner comprometido para o nó Kubernetes subjacente sem gerar um alerta de segurança em nenhuma plataforma de monitoramento. O SIEM do fornecedor não cobria o cluster. O monitoramento do provedor de DevOps não incluía alertas de segurança em tempo de execução. A lacuna existia desde a implantação do cluster.
Qual é, de fato, o problema da visibilidade entre plataformas?
As lacunas de visibilidade entre plataformas são os pontos cegos do monitoramento de segurança que existem nas interfaces entre diferentes plataformas tecnológicas, serviços gerenciados e operadores terceiros, especificamente os sistemas e ambientes em que a fronteira de responsabilidade pelo monitoramento entre duas partes é ambígua, presumida em vez de confirmada, ou explicitamente excluída do escopo de uma parte sem ter sido explicitamente incluída no escopo da outra. Essas lacunas não são falhas técnicas de uma plataforma de monitoramento específica; são falhas de governança na definição de qual parte é responsável por monitorar quais sistemas.
O problema da suposição de responsabilidade é o mecanismo operacional. Em ambientes tecnológicos complexos, com vários provedores de serviços gerenciados e operadores terceiros, o escopo do monitoramento é frequentemente presumido, em vez de especificado em contrato. O fornecedor supõe que o provedor de DevOps monitora a segurança do cluster. O provedor de DevOps supõe que a equipe de segurança do fornecedor monitora os aspectos de segurança. A suposição é razoável da perspectiva de cada parte: cada uma acredita que a outra assumiu a responsabilidade. Nenhuma confirma a suposição. Na prática, o monitoramento de segurança do cluster Kubernetes não está atribuído a ninguém.
O problema da ambiguidade de escopo dos serviços gerenciados é a falha de governança específica. Os contratos de serviços gerenciados frequentemente especificam o escopo do monitoramento em termos operacionais (saúde do cluster, desempenho, disponibilidade) sem tratar explicitamente do monitoramento de segurança. A passagem do monitoramento operacional para o monitoramento de segurança é uma distinção de escopo significativa que exige tratamento explícito no contrato de serviço. Sem esse tratamento explícito, cada parte adota sua interpretação natural: o cliente supõe que a segurança está incluída no monitoramento, e o provedor de serviços gerenciados supõe que a segurança é responsabilidade do cliente.
- Lacuna de responsabilidade pelo monitoramento: cada parte supõe que a outra cobre a segurança do cluster Kubernetes
- Contrato de serviço gerenciado que especifica o monitoramento operacional sem tratar explicitamente da segurança
- Inventário de cobertura incompleto: cluster Kubernetes fora do escopo de segurança confirmado do fornecedor e do provedor de DevOps
- Fuga de contêiner e acesso aos nós sem gerar alertas em nenhuma plataforma de monitoramento
- Suposição, em vez de confirmação, do escopo de monitoramento na fronteira do serviço gerenciado
Por que isso importa
A visibilidade entre plataformas é relevante para TPRM porque ambientes tecnológicos complexos de fornecedores, com vários serviços gerenciados, operadores terceiros e infraestrutura híbrida, criam oportunidades de lacunas de monitoramento em cada interface entre as partes. Um fornecedor cujo monitoramento de segurança confirmou a cobertura de endpoints, nuvem e rede pode ter um portal do paciente em um cluster Kubernetes que não é coberto por nenhum desses três programas de monitoramento, e nem o fornecedor nem seu provedor de DevOps confirmaram a responsabilidade pelo monitoramento de segurança desse cluster.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar confirmações de monitoramento por categoria (segurança de endpoints confirmada, segurança em nuvem confirmada, segurança de rede confirmada) sem perguntar se há componentes tecnológicos não cobertos por nenhuma dessas categorias. A lacuna normalmente existe em serviços gerenciados e em componentes operados por terceiros.
- Cobertura por categorias confirmada sem inventário: o que está e o que não está coberto
- Escopo de monitoramento de segurança dos serviços gerenciados não avaliado
- Segurança de Kubernetes e de contêineres não avaliada especificamente
- Monitoramento de componentes operados por terceiros não verificado
- Responsabilidade pelo monitoramento confirmada para cada componente, em vez de presumida
Como é uma boa prática
Programas maduros de visibilidade entre plataformas mantêm um inventário completo dos componentes tecnológicos associado à responsabilidade confirmada pelo monitoramento, garantindo que cada sistema, serviço e componente tenha um responsável identificado pelo monitoramento, e não uma lacuna preenchida por suposição.
- Inventário de componentes tecnológicos: todos os sistemas associados a um responsável confirmado pelo monitoramento
- Escopo de monitoramento de segurança dos serviços gerenciados definido explicitamente nos contratos
- Monitoramento de segurança de contêineres e de Kubernetes: segurança em tempo de execução confirmada, e não presumida
- Confirmação da responsabilidade pelo monitoramento: o responsável por cada componente explicitamente confirmado, e não presumido
- Revisão para identificação de lacunas: revisão anual que identifica componentes sem monitoramento confirmado
Ferramentas
Segurança de contêineres: Falco, Sysdig, Aqua Security para segurança em tempo de execução do Kubernetes
As plataformas de segurança em tempo de execução para Kubernetes monitoram o comportamento dos contêineres, a aplicação das políticas de rede e o acesso aos nós em tempo real, o monitoramento de segurança que as plataformas operacionais de monitoramento de DevOps não oferecem. Para profissionais de TPRM, perguntar se os ambientes Kubernetes do fornecedor têm monitoramento de segurança em tempo de execução, especificamente a detecção de fuga de contêiner e de acesso aos nós, constitui uma pergunta específica sobre cobertura entre plataformas.
Desafios de governança
O desafio de governança do monitoramento entre plataformas é a exigência de clareza nos contratos de serviços gerenciados. O escopo do monitoramento deve ser especificado explicitamente para cada componente nos contratos de serviços gerenciados: o monitoramento operacional e o monitoramento de segurança são escopos distintos que exigem tratamento explícito separado. A solução de governança é exigir a definição do escopo de monitoramento em todos os contratos de serviços gerenciados, com uma revisão do inventário de cobertura para identificar lacunas.
- Exigir um escopo explícito de monitoramento de segurança em todos os contratos de serviços gerenciados
- Manter um inventário de monitoramento dos componentes tecnológicos: todos os componentes, com responsável confirmado
- Implantar segurança em tempo de execução para Kubernetes nos ambientes de contêineres
- Revisão anual de lacunas de cobertura: identificar componentes sem monitoramento confirmado
- Confirmar o escopo de segurança do serviço gerenciado, sem presumir que corresponde ao escopo operacional
Se você faz parte de uma equipe pequena
Para o seu fornecedor de maior risco, solicite o inventário de monitoramento dos componentes tecnológicos: uma lista dos principais componentes tecnológicos e do responsável confirmado pelo monitoramento de cada um. Se ele não tiver esse inventário, pergunte especificamente: os seus ambientes Kubernetes ou de contêineres estão cobertos pelo seu monitoramento de segurança e, se ocorresse uma fuga de contêiner nesse ambiente, um alerta seria disparado no seu SIEM? Essas duas perguntas revelam se existe a lacuna de visibilidade entre plataformas no ambiente com maior probabilidade de não ser monitorado.
- Solicitar o inventário de monitoramento dos componentes tecnológicos
- Perguntar especificamente se os ambientes Kubernetes e de contêineres têm monitoramento de segurança em tempo de execução
- Perguntar se uma fuga de contêiner geraria um alerta no SIEM
- Perguntar sobre o escopo de monitoramento de segurança dos serviços gerenciados nos contratos
O que exigir
Pergunte diretamente:
“Nos seus ambientes Kubernetes e de contêineres, vocês têm monitoramento de segurança em tempo de execução capaz de detectar uma fuga de contêiner e um acesso no nível dos nós, e esse monitoramento de segurança está atribuído explicitamente, no seu contrato de serviço, à sua equipe ou à equipe do seu provedor de DevOps gerenciado?”
O que esperar como evidência
- Confirmação do monitoramento de segurança em tempo de execução do Kubernetes
- Capacidade de detecção de fuga de contêiner
- Escopo de monitoramento de segurança do serviço gerenciado no contrato
- Inventário de monitoramento dos componentes tecnológicos
Um fornecedor que confirma a cobertura de endpoints, nuvem e rede deve ser questionado especificamente sobre o monitoramento de segurança de contêineres e de Kubernetes. As categorias confirmadas cobrem os componentes confirmados. O cluster Kubernetes que hospeda dados dos clientes exige sua própria confirmação.
Como comprovar
- Inventário de monitoramento dos componentes tecnológicos
- Registros de monitoramento de segurança em tempo de execução do Kubernetes
- Documentação do escopo de monitoramento de segurança do serviço gerenciado
- Registros da revisão de lacunas de cobertura
Principal conclusão
O fornecedor monitora AWS. O provedor de DevOps monitora o cluster do ponto de vista operacional. Ninguém monitora a segurança do cluster. O portal do paciente está no cluster. Fuga de contêiner detectada por: ninguém. A lacuna existe não por uma limitação técnica, mas porque ninguém havia atribuído explicitamente a responsabilidade pelo monitoramento e confirmado essa atribuição. Suposição não é monitoramento. Um inventário de componentes tecnológicos com responsável confirmado pelo monitoramento é monitoramento. Exija o inventário. Confirme a responsabilidade. Especifique explicitamente o escopo de segurança nos contratos de serviços gerenciados. A lacuna existe no espaço entre duas partes que acreditam, cada uma, que a outra é a responsável.