Chat with us, powered by LiveChat

A ascensão do DASB

A prevenção de perda de dados (DLP), o modelo antiquado de proteção de dados, adota uma abordagem de 'gerenciamento por regra', em que todos os dados fluem livremente, a menos que a equipe de segurança tenha escrito uma regra para proteger especificamente os dados. As regras vêm em muitas formas - regras de descoberta e classificação que determinam quais dados são confidenciais, regras que ditam quais aplicativos, versões e tipos de arquivo podem ser usados com base nas limitações de DLP e regras que determinam o que os usuários finais podem fazer com os dados (cópia , compartilhar, etc.). Infelizmente, há um enorme esforço para as equipes de segurança desenvolverem todas as regras que se aplicam, agora e no futuro, e se alinharem com as unidades de negócios antes e durante a implementação e em andamento. O gerenciamento por regras também é um fardo enorme para a produtividade dos funcionários, pois mais e mais restrições são impostas aos fluxos de trabalho diários. E apesar de todo esse esforço, o DLP ainda é altamente sujeito a erros. As empresas, mesmo depois de investir consideráveis dólares, tempo e esforço tentando implementar e operacionalizar o DLP, ainda são vítimas de violações de dados.

O corretor de segurança de acesso a dados (DASB) da SecureCircle vira a abordagem 'gerenciar por regra' e 'gerencia por exceção'. Em vez de investir esforços na construção de um conjunto duvidoso de regras que identificam os dados e tentam proteger todos os vetores de ameaças em potencial, o DASB adota uma abordagem abrangente. Isso é possível porque o DASB é completamente transparente para o usuário final, não há necessidade de modificar nenhum aplicativo e o DASB não impõe nenhuma restrição ao fluxo de trabalho. Como resultado, todos os dados podem ser protegidos, sem a necessidade de descobrir, classificar ou solicitar aos usuários finais que rotulem os dados manualmente. Com essa abordagem, o DASB ultrapassa os limites do DLP.

Neste artigo, examinamos as diferenças entre a pilha de tecnologia de proteção de dados tradicional centrada em DLP e comparamos com o DASB da SecureCircle, destacando casos de uso derivados de violações recentes do mundo real.

O infeliz caso de DLP

Por padrão, o DLP permite que um arquivo flua livremente, a menos que tenha sido especificamente identificado como confidencial e exista uma regra para bloquear o que o usuário está fazendo para / com aquele arquivo.

Alguns tipos de informações confidenciais podem ser detectados programaticamente, como cartões de crédito e números de previdência social que seguem uma estrutura previsível, no entanto, isso é altamente sujeito a erros. Primeiro, a equipe de segurança deve investir muito tempo no desenvolvimento de regras de correspondência de padrões estáticos. Informações como cartões de crédito podem assumir muitas formas diferentes na prática; portanto, mesmo escrever dezenas de regras de detecção pode não capturar todas e bloquear muitas informações indesejadas no processo. Por exemplo, o DLP pode encontrar esse número de telefone (819661820893) e identificá-lo como um número de cartão de crédito, um falso positivo. Um anexo de e-mail de saída com este número de telefone pode ser bloqueado, causando uma desaceleração nos negócios onde nada é garantido. Essa interferência nas operações normais de negócios é uma das muitas desvantagens principais do DLP. Quanto mais agressivamente a equipe de segurança adiciona e atualiza regras para regular dados confidenciais, aplicativos e ações do usuário, mais frequentemente ocorrem falsos positivos, resultando em reação dos funcionários. Os funcionários reclamam e tentam contornar as ferramentas DLP completamente.

O DLP também falha em detectar informações confidenciais que foram ligeiramente alteradas, permitindo que passem livremente, um falso negativo. Para cartões de crédito, o desvio clássico de exfiltração é soletrar o número do cartão de crédito (“oito um nove seis ...”), alterar o número do cartão de crédito para a fonte Wingdings ou reescrevê-lo como algarismos romanos. É fácil pensar em maneiras de superar a correspondência de padrões do DLP.

Deixando de lado os números de cartão de crédito e SSNs, a grande maioria dos dados pessoais e IP valiosos não tem marcadores óbvios que uma máquina possa detectar automaticamente (código-fonte, segredos comerciais, designs internos, atividade de M&A, informações de saúde, a lista continua). O resultado é que o DLP acaba focando no menor e mais óbvio subconjunto de informações confidenciais, como números de cartão de crédito, enquanto resmas de dados realmente confidenciais são deixados totalmente desprotegidos.

Para piorar as coisas, a implementação do DLP é trabalhosa, demorada e altamente restritiva. O DLP força a empresa a exigir aplicativos, versões e tipos de arquivos específicos com base nas limitações do DLP, por exemplo, uma versão específica do Microsoft Office, Adobe ou um aplicativo de engenharia específico. No entanto, se for descoberto que a versão com suporte do aplicativo tem uma vulnerabilidade de segurança, não será possível fazer upgrade ou downgrade para uma versão segura até que o ambiente DLP seja atualizado para funcionar com essa nova versão. Funcionários e parceiros bem-intencionados são, portanto, penalizados por terem que trabalhar com DLP, enquanto os agentes mal-intencionados ainda contornam facilmente as tentativas de proteção do DLP. Dependendo do fornecedor de DLP e das regras definidas, um usuário com acesso de leitura a um arquivo pode simplesmente violar os dados convertendo-os em um tipo de arquivo diferente, salvando como um nome de arquivo diferente, copiando / colando os dados ou pegando uma captura de tela dos dados. Com o DLP, as equipes de segurança precisam pensar em cada caminho de exfiltração e criar explicitamente uma regra para cada um - isso requer uma quantidade enorme de tempo e esforço manual e é extremamente sujeito a erros.

Como resultado, as equipes de segurança são criticadas simultaneamente da suíte executiva e da empresa por não protegerem os dados de forma eficaz e sob pressão da suíte executiva e da empresa para sair do caminho da usabilidade e produtividade. As organizações cansadas recorrem à configuração do DLP no "modo de monitoramento", registrando silenciosamente os acessos e compartilhamentos de dados, mas sem fazer nenhuma tentativa de impedir as violações. Nesse ponto, todos os dados confidenciais e pessoais estão desprotegidos e fluem livremente dentro e fora da organização. Não há restrição de controle de aplicativo / processo. Os dados são totalmente vulneráveis a malware, violações e registros de desvios.

Nos últimos anos, as empresas têm explorado maneiras alternativas de detectar informações confidenciais, como pedir aos funcionários que classifiquem manualmente seus dados. Isso pode ocorrer na forma de cada funcionário da empresa preencher um pequeno formulário sempre que enviar um e-mail ou salvar um arquivo, o que representa um grande investimento de tempo. No entanto, seus colegas não são profissionais de segurança e seu incentivo é a realização de seu trabalho, portanto, a precisão de sua classificação é duvidosa. Uma vez que os internos são conhecidos como o maior vetor de ameaças, dar aos funcionários o poder de classificar se os dados são confidenciais ou não é entregar aos internos as chaves do reino. Na prática, a classificação acaba sendo uma muleta para permitir os cenários de DLP mais óbvios, e geralmente apenas em dados recém-criados, enquanto anos de dados valiosos já armazenados na empresa permanecem sem classificação e, portanto, desprotegidos e não auditados. Uma tendência mais recente tenta aplicar o aprendizado de máquina para detectar dados confidenciais, exigindo um grande investimento no treinamento dos algoritmos, com muito hype, porém pouco ganho mensurável foi relatado até o momento.

Dada a quantidade de esforço exigido da equipe de segurança para desenvolver regras que detectem dados confidenciais e a sobrecarga incorrida pelos funcionários que classificam seus próprios dados, usando apenas aplicativos e tipos de arquivo prescritos, a abordagem DLP acaba sendo opt-in para a menor quantidade de dados a serem protegidos quanto possível. Este é o velho paradigma, este é DLP.

DASB - um novo paradigma de proteção de dados

A abordagem de proteção por regra do DLP impõe limites a cada passo - limites sobre quais dados podem ser protegidos, limites sobre tipos de arquivo, limites indesejados sobre tipos e versões de aplicativos, limites sobre fluxos de trabalho. O 'gerenciamento por exceção' do DASB permite uma abordagem ilimitada, onde qualquer dado pode ser protegido de forma transparente, sem obstáculos à proteção ou à produtividade. Um programa de proteção de dados verdadeiramente Zero-Trust.

Proteção de dados ilimitada - ao contrário da abordagem redutiva do DLP de optar por apenas o menor subconjunto de dados a serem protegidos, o DASB tem uma abordagem abrangente para proteção de dados. Reconhecemos que a maioria, senão todos, os dados corporativos contêm informações confidenciais ou valiosas e não devemos permitir que esses dados vazem. DASBachieves proteção persistente, entregando-a de forma totalmente transparente para os usuários finais. O DASB protege todos e quaisquer dados sem impacto na experiência do usuário final.

O DASB é baseado em um sistema de arquivos criptografado virtual e portátil patenteado que insere uma camada transparente entre os processos de leitura e gravação de aplicativos e seus sistemas de armazenamento. O acesso aos sistemas de armazenamento por meio do DASB é idêntico ao modo como os dados são acessados hoje. Se os dados protegidos pelo DASB forem acessados por um usuário, dispositivo ou processo autorizado, a política de controle de acesso permitirá que o processo, dispositivo, usuário leia bytes descriptografados. Se os dados protegidos forem acessados por um usuário, dispositivo ou processo não autorizado, a política de controle de acesso não servirá o processo, dispositivo, bytes descriptografados do usuário, apenas bytes criptografados são acessados. Como resultado, os usuários nem mesmo estão cientes da existência do DASB, a menos que tentem acessar dados que não deveriam estar acessando.

Produtividade ilimitada - a transparência do DASB permite que ele proteja de forma ampla todos os dados. O DASB não impõe limites aos aplicativos, versões, tipos de arquivo, tamanhos de arquivo, repositórios, ferramentas de desenvolvedor, fluxos de trabalho ou qualquer outra coisa no ambiente, não importa quão complexo ou específico da empresa.

O DASB pode ser implementado em toda a empresa ou com uma abordagem em fases, selecionando os casos de uso mais importantes primeiro (código-fonte, CRM, segredos comerciais, finanças, PCI / PHI, etc.) e protegendo todos os dados relacionados a esses casos de uso. Para dados que podem ser compartilhados externamente, como material de marketing ou cotações de vendas, as permissões baseadas em funções permitem que os usuários colaborem com segurança com partes interessadas externas sem abrir mão de qualquer controle, proteção, visibilidade ou responsabilidade.

Controle ilimitado - com DLP, o controle só é persistente se as regras de DLP foram configuradas exatamente para o aplicativo, versão, tipo de arquivo e caminho de migração específicos (copiar / colar, copiar arquivo, nuvem para nuvem, etc.). Esses cenários são quase impossíveis de configurar na profundidade e nuance necessárias, resultando em mais interrupções do fluxo de trabalho do que na proteção real dos dados. O DASB move as políticas de controle de acesso do sistema de armazenamento de dados para os próprios dados - de centrado no dispositivo para centrado nos dados. Não importa onde os dados são criados, consumidos, modificados e armazenados, eles são protegidos de forma persistente pelo DASB. Os dados podem ser migrados do local para a nuvem ou de nuvem para nuvem e permanecem protegidos em todos os estados: em repouso, em trânsito, durante a migração, no novo local de armazenamento e até mesmo em uso. Isso ocorre porque a proteção e o controle de acesso seguem os dados e toda e qualquer ação que atinge os dados.

Vejamos os quatro principais recursos de proteção de dados do DASB que tornam essa proteção ilimitada possível. Eles podem ser usados individualmente ou em combinação para proteger contra a exfiltração de dados, seja inadvertida ou intencional.

MagicFolder ™

Com o DASB, os usuários ou administradores podem direcionar um local para proteger com MagicFolder. Todos os dados dentro de uma pasta mágica são automaticamente e imediatamente protegidos. Isso inclui todas as subpastas e diretórios. Qualquer sistema de arquivos pode ser uma pasta mágica - a área de trabalho de um usuário, uma pasta de documentos, até mesmo C: \. Os servidores de arquivos e tudo dentro deles podem ser pastas mágicas. Mesmo um bucket do Amazon S3, comumente envolvido em violações de dados, é simplesmente um sistema de arquivos em nuvem que pode ser protegido automaticamente, como qualquer armazenamento de Blob do Azure, intervalo de armazenamento em nuvem do Google, etc.

A partir daí, todos os dados que já existem na pasta ou são baixados, arrastados, copiados, criados, etc. na pasta são protegidos de forma instantânea e automática.

Seguindo o paradigma DASB com a capacidade de proteger tudo, a maioria das empresas protege sistemas de arquivos e repositórios de armazenamento inteiros, optando por não proteger o subconjunto muito pequeno de dados específicos que precisam ser gerenciados por uma exceção.

No mundo real: A questão da segurança do bucket S3 atingiu o ápice nos últimos anos com violações de dados proeminentes afetando empresas como Capital One, Uber, Accenture e o Departamento de Defesa dos Estados Unidos. Essas violações continuam acontecendo pelos mesmos motivos, repetidamente. Os buckets do S3 são convenientes para a colaboração, no entanto, costumam ser configurados incorretamente, deixando seu conteúdo aberto ao público. As vítimas dessas violações de alto perfil tinham DLP, mas nenhuma regra de DLP bloqueou com sucesso o caminho de exfiltração. Pior ainda, em vários casos, os dados nunca foram descobertos e a empresa só tomou conhecimento quando a violação foi divulgada. Em contraste, o DASB protegeria os dados confidenciais automaticamente antes mesmo de chegarem ao S3, evitando a violação por completo.

Outro caso de uso do mundo real é proteger dados gerados por aplicativos da web cliente / servidor legados. Os aplicativos da web cliente / servidor legados são notórios por ter recursos de proteção de dados desatualizados, embora as empresas frequentemente tenham linhas de negócios inteiras construídas em torno deles. Imagine um editor de CAD legado que produz os principais designs industriais de uma empresa, no entanto, o editor não é mais suportado pelo fornecedor. Ou uma ferramenta de autoria de conteúdo desenvolvida internamente que não tem mais uma equipe de desenvolvimento interna. Esses aplicativos legados estão tão arraigados nos fluxos de trabalho de negócios que mudar para outro aplicativo por motivos de segurança não é realista. Com o DASB, o MagicFolder protege a pasta de dados do aplicativo da web legado, sendo o aplicativo da web o único processo com permissão para acessar essa pasta. Isso permite a criptografia da saída de dados pelo aplicativo legado, com nenhuma alteração no aplicativo e nenhum impacto nas integrações ou fluxos de trabalho existentes.

MagicProcess ™

Com o DASB, os administradores também podem especificar um “processo mágico” a partir do qual todos os dados que saem do processo são protegidos ou desprotegidos. Pode ser um navegador da web, Microsoft Word, Outlook, Adobe Acrobat - qualquer processo. Seguindo o paradigma DASB com a capacidade de proteger tudo, as empresas definem todos os processos para serem protegidos por padrão. O DASB também permite proteger apenas certos processos para dar suporte a casos de uso de proteção específicos, por exemplo, tornar apenas o aplicativo de RH ou contabilidade um processo mágico.

No mundo real: o código-fonte tornou-se uma das formas mais valiosas de propriedade intelectual. No entanto, vimos vários gigantes da tecnologia, incluindo AWS, Tesla, Waymo, violados devido a um único funcionário exfiltrando centenas de milhares de linhas de código-fonte. Historicamente, a proteção do código-fonte era limitada a quando ele era armazenado em um repositório, no entanto, assim que um desenvolvedor obtém o código do repositório, o DLP e outras ferramentas tradicionais não são configuradas para proteger o código-fonte ou podem falhar em identificá-lo completamente. Já com o DASB, essa violação não é possível, pois as ferramentas de acesso ao repositório são feitas um 'processo mágico' e no checkout de qualquer código-fonte, por meio de qualquer processo aprovado, o código-fonte é protegido de forma automática e transparente.

O código-fonte é um exemplo comovente, no entanto, os casos de uso de processos mágicos são de longo alcance, incluindo o funcionário mal-intencionado que faz login no CRM da empresa e baixa todos os contatos da empresa ou pipeline para um arquivo CSV, ou a ameaça externa que compromete um conta interna e tenta baixar dados pessoais e financeiros do ERP. Em todos esses casos, o DASB evita a violação de dados.

MagicClipboard ™

Com o DASB, as empresas controlam como os dados da área de transferência podem ser colados. Os usuários podem ter permissão para copiar e colar de processos protegidos em outros processos protegidos, ou certos dados podem ser copiados de uma fonte desprotegida para uma fonte protegida sob certas condições, dependendo da política definida.

No mundo real: uma fonte de vazamentos frequentemente esquecida é copiar / colar dados confidenciais para aplicativos de colaboração como Slack, Skype ou simplesmente e-mail. Isso gerou manchetes como Cuidado! Slack leaks são os novos vazamentos de e-mail que documentam o impacto dos vazamentos de e-mail que aconteceram com o The New York Times, Breitbart e Reddit por meio de "meios ridiculamente simples de copiar e colar conversas internas". O Magic Clipboard protege contra esses vazamentos, onde as tecnologias tradicionais normalmente não são capazes de proteger esse vetor de ameaça cada vez mais comum.

MagicDerivative ™

Não importa o quão cuidadosa uma empresa planeje e direcione suas políticas de proteção de dados, alguns dados certamente serão perdidos, agora ou no futuro. É aqui que o MagicDerivative do DASB o protege. Sempre que dados desprotegidos são acessados, o mecanismo de detecção de similaridade patenteado do DASB entende o DNA dos dados (dDNA) e procura uma correspondência com o dDNA que já está protegido. Se houver uma correspondência, MagicDerivative aplica proteção a esses dados automaticamente, com as mesmas políticas de acesso dos dados originalmente protegidos. Isso significa que, mesmo que você não tenha "descoberto" os dados confidenciais ou que seus colegas criem ou importem novos dados confidenciais no decorrer do processo, o DASB reconhecerá automaticamente esses dados como confidenciais e os protegerá.

No mundo real: grandes empresas podem ter dezenas de milhares de servidores ou mais, muitos dos quais são desconhecidos ou contêm dados desconhecidos. E todos nós vimos os infográficos que mostram a rapidez com que 'novos' dados estão sendo criados. Quais desses dados são confidenciais e precisam ser protegidos? O que é relevante? E o que é legado e pode ser descartado? O mercado de ferramentas de descoberta de dados é muito ativo, mas a única coisa que essas ferramentas podem fazer é fornecer, no mínimo, pistas sobre quais dados existem dentro das paredes de uma empresa. No entanto, MagicDerivative funciona com todos os dados, mesmo dados “desconhecidos” que não foram descobertos ou classificados. MagicDerivative encontra os dados da empresa conforme eles estão sendo acessados (quando estão mais vulneráveis) e os protege automaticamente, esteja a equipe de segurança ciente desses dados ou não. Com o tempo, ele se espalha como um “vírus benevolente”, protegendo todos os dados com as políticas corretas, de acordo com seu dDNA.

MagicDerivative funciona até mesmo com dados não textuais, como imagens. Se um usuário copiar / colar sua foto protegida em um arquivo PowerPoint, o PowerPoint é reconhecido como tendo o mesmo dDNA da imagem e é automaticamente protegido com os mesmos controles de acesso.

Juntando tudo

As violações estão ocorrendo em taxas extraordinárias, tornando uma questão de quando, e não se, seus dados serão explorados. 'Gerenciar por regra' provou ser ineficaz e as empresas modernas exigem uma abordagem de mudança de paradigma para a proteção de dados.

Com o Data Access Security Broker da SecureCircle, as violações de dados são eliminadas. Os usuários finais não são mais sábios e a empresa não precisa se conformar com as limitações do DLP.

Entre em contato com um especialista em DASB para saber mais sobre como podemos ajudar sua organização a eliminar violações e mitigar ameaças internas.