Confiança Zero: Três componentes estratégicos principais do Assume Breach
Confiança zero é um tópico popular nos círculos de segurança cibernética atualmente, mas ainda recebo olhares estranhos sempre que menciono o conceito de suposição de violação como parte fundamental da mentalidade de confiança zero. Presumo que o motivo dessa reação decorra de uma de duas preocupações possíveis. Primeiro, alguns profissionais de segurança podem interpretar isso como uma visão terrivelmente pessimista do mundo; sua internalização de "assumir violação" seria algo como: "Então, você está dizendo que estamos todos condenados. Bem, então vamos simplesmente desistir e parar de tentar. ” Outros, talvez os mais orgulhosos, podem ter uma atitude do tipo: "Bem, suas coisas podem ser violadas, mas minha segurança é sólida como uma rocha, e não há como os bandidos passarem por minhas defesas ".
Minha intenção não é nenhum desses extremos, mas sim uma ênfase na internalização da realidade de operar em um mundo digital, ou seja, que violações ocorrerão e, portanto, podem e devem ser levadas em consideração no projeto de qualquer sistema de segurança. Este não é um conceito novo, e devemos nos inspirar na sabedoria adquirida por gerações de artesãos e trabalhadores do comércio que o adotaram.
Encanadores, eletricistas e outros profissionais que operam no mundo físico há muito internalizaram a verdadeira essência de “assumir violação”. Como são encarregados de criar soluções que devem ser robustas em ambientes tangíveis, eles aceitam e incorporam implicitamente o simples fato de que falhas ocorrem dentro do escopo de seu trabalho. Eles também entendem que falhas não são uma prova de suas habilidades, nem um motivo para abrir mão de seus serviços. Em vez disso, somente os mais habilidosos, entendendo que suas criações acabarão fracassando, incorporam aprendizados de fracassos passados e são capazes de antecipar prováveis fracassos futuros.
Recentemente, tive que lidar com uma falha dessas: uma tubulação de esgoto na minha casa ficou entupida no meio de um caminho de drenagem. A casa tem mais de 30 anos, então uma falha — uma violação — não deveria ser uma surpresa. Afinal, a probabilidade de violação de qualquer sistema durante um longo período de tempo se aproxima de 100%.
Esse é o ponto. Antecipar uma falha ao longo do tempo é tão verdadeiro para uma solução de segurança de aplicativo quanto para meu sistema de encanamento. Além disso, assumir que “o meu sistema de canalização nunca irá falhar” não é mais apropriado como estratégia de manutenção doméstica do que “as minhas defesas cibernéticas nunca serão violadas”.
Portanto, a mentalidade do encanador — e do profissional de segurança cibernética — deve abranger como lidar com a falha, ou seja, a violação, que eventualmente ocorrerá.
Três componentes estratégicos principais do Assume Breach
Uma estratégia eficaz para lidar com falhas de sistemas — físicos ou cibernéticos — geralmente tem três componentes.
Visibilidade. Garanta visibilidade suficiente para permitir a detecção de uma falha o mais rápido possível. Um vazamento de encanamento no ralo do banheiro, se não for controlado, resultará em podridão e mofo no contrapiso, o que pode levar meses ou anos para ser notado. Ou alguém pode notar água pingando do teto do espaço sob o banheiro do segundo andar depois que um reservatório de água sob o piso transbordou e a parede de gesso ficou saturada. Em qualquer um desses cenários, a primeira detecção do problema ocorre algum tempo após a falha inicial e após a ocorrência de danos secundários adicionais .
O primeiro princípio para assumir uma falha/violação deve ser fornecer indicadores claros de possível comprometimento o mais rápido possível após a falha, idealmente até mesmo fornecendo notificação ativa para prováveis falhas. Por exemplo, porões que dependem de bombas de depósito para remoção de água geralmente têm sensores que emitem um alarme quando o nível da água excede um limite predefinido. Em outras situações, onde o alerta proativo não é viável para todos os modos de falha prováveis, verificações de manutenção de rotina são realizadas — por exemplo, inspeção de aquecedores de água semestralmente.
Em segurança cibernética, isso significa que a arquitetura de segurança do aplicativo deve incluir uma estratégia de telemetria considerada e testada que leve em consideração os modos de falha mais importantes, o que fornece visibilidade oportuna de quaisquer possíveis violações. Na prática, a telemetria deve ser transmitida para ferramentas de análise e notificação usando práticas AISecOps e também persistida simultaneamente em armazenamentos de dados para uso posterior. Ferramentas de IA e alertas devem ser usadas para melhorar a eficácia, fornecer contexto aos humanos e garantir uma resposta oportuna. Dados persistentes devem ser usados para aprender e ajudar a informar robustez adicional no futuro.
Robustez. As soluções devem incluir meios para contornar ou reduzir a duração de uma falha. Os padrões comuns de robustez neste contexto são (a) degradação gradual ou (b) redundância, com a escolha dependendo da viabilidade de operar com um componente degradado. Alguns sistemas, como aquecedores de água quente, podem ter ambos. Por exemplo, meu aquecedor de água usa um sistema de recirculação alimentado por bomba para sempre ter água quente pronta para uso. Mas se a bomba falhar, ainda terei água quente, mas terei que esperar um pouco mais. Por outro lado, a falha de um sensor de serpentina de aquecimento, onde o elemento de aquecimento não desliga, pode levar a uma falha catastrófica , portanto, é usada redundância, na forma de uma válvula de alívio de pressão.
A robustez deve ser considerada em vários escopos do sistema. Por exemplo, no caso apenas da linha de drenagem, um encanador trabalhando em uma solução de nível comercial pode instalar um par de linhas de descarte redundantes, de modo que a falha de qualquer uma das linhas não tornaria o dreno inutilizável. Por outro lado, um arquiteto que opera o nível de abstração do sistema poderia projetar redundância no nível do sistema, como adicionar uma segunda pia ou vaso sanitário nas proximidades, o que também teria o benefício de abordar mais modos de falha do que apenas canos de drenagem entupidos.
Certamente, a redundância é uma prática comum em segurança cibernética, pois muitos dispositivos de segurança são implantados no modo ativo/espera (redundância total) ou ativo/ativo (degradação gradual). No entanto, o mundo da segurança cibernética é um pouco diferente do mundo físico. Primeiro, o fato de o mundo da segurança cibernética ter invasores ativos, com intenção e inteligência, significa que as falhas raramente resultam de causas naturais. Uma segunda diferença mais significativa é a escala. Como o software é virtual, não físico, ele segue o paradigma “escreva uma vez, implante muitas vezes”. Embora essa seja uma propriedade maravilhosa para dimensionamento, ela também implica que uma vulnerabilidade de código em um componente de software principal provavelmente afetará todas as instâncias desse código no sistema. Como tal , a solução de segurança cibernética para robustez também se baseia em evitar pontos únicos — e classes únicas de elementos — de falha; uma estratégia às vezes referida como “defesa em profundidade”. A autenticação multifator é um ótimo exemplo dessa ideia na prática. O modo de falha (o meio de comprometer) para cada fator é diferente, e o comprometimento de qualquer fator sozinho não comprometerá o sistema como um todo.
Contenção. É fundamental restringir o impacto — a zona de explosão — de uma falha. Assim como aceitamos que falhas ou violações ocorrerão, também devemos aceitar que não seremos capazes de evitar completamente pontos únicos de falha ou criar redundância para cada requisito funcional. Consequentemente, o arquiteto também deve considerar como minimizar o impacto de uma falha, usando tanto o esforço quanto a consequência como duas métricas importantes de qualidade. Por exemplo, um encanador pode adicionar portas de limpeza estrategicamente localizadas nas linhas de drenagem para reduzir o tempo de remediação. Para falhas mais catastróficas, um empreiteiro pode escolher PVC em vez de linhas de drenagem galvanizadas para facilitar o reparo de um vazamento na linha, reduzindo o esforço de remediação. Uma prática comum de encanamento doméstico é a inclusão de válvulas de fechamento para limitar as consequências de uma falha (detectada), evitando assim danos secundários a vaidades e pisos.
No mundo da segurança cibernética, os conceitos análogos são isolamento, manutenibilidade e modularidade . O isolamento visa minimizar danos colaterais ou estancar o sangramento; uma boa prática é ter uma infraestrutura que possa atuar como um disjuntor, usando tecnologias como microssegmentação. Manutenibilidade significa que, sempre que possível, permitir um caminho rápido e de baixo esforço do estado comprometido de volta ao não comprometido; por exemplo, reiniciar uma carga de trabalho comprometida por ataques de estouro de memória pode ser um método de mitigação eficaz (embora incompleto). Modularidade é a prática de construir sistemas que permitem que componentes funcionais comparáveis sejam trocados facilmente, de modo que, nos casos em que a manutenção não é possível ou suficiente, o esforço necessário para remediação seja minimizado.
Estas são algumas das melhores práticas que aprendi sobre como lidar com violações, embora eu certamente não afirme que não existam outras. O mais importante é que os desenvolvedores e profissionais de segurança encarregados de proteger aplicativos entendam que vazamentos ocorrerão e violações ocorrerão inevitavelmente. Nessa perspectiva, a forma como planeamos e lidamos com essas falhas é tão importante e merece tanta reflexão deliberada como o que fazemos para minimizar a frequência dessas falhas.
Em última análise, seremos julgados não apenas pela frequência com que as violações ocorrem, mas também pela forma como reagimos a essas violações quando elas inevitavelmente ocorrem .