Skip to content

Você deveria fazer Segurança do SaaS por conta própria?

A aceleração das iniciativas digitais e a adoção do SaaS estão aumentando as preocupações sobre a segurança do SaaS. Os CISOs sabem que as suas tecnologias dependerão cada vez mais dos SaaS. Eles esperam que as suas equipes sejam capazes de responder questões sobre os riscos, ameaças e vazamentos dos SaaS como quais contas foram comprometidos, quais arquivos foram compartilhados externamente, se há privilégios de administrador não utilizados que podem ser removidos etc.

Para detectar, caçar, investigar e responder de forma eficiente as brechas e ameaças na nuvem, equipes de segurança focadas em ameaças precisam de dados. Assim como a detecção e resposta de endpoint (EDR) dá aos times de segurança a telemetria, contextualização visual e capacidades de detecção automáticas que eles precisam para assegurar os endpoints, a segurança do SaaS requer visibilidade e analise unificadas para os aplicativos SaaS. A falta de visibilidade operacional sempre foi algo não endereçado na segurança do SaaS.

Equipes de segurança em organizações mais maduras e ingressadas no SaaS constroem capacidades de telemetria dentro da organização agregando logs de atividade das aplicações SaaS a um data lake central ou a um SIEM. Agora, com soluções inovadores de detecção e resposta na nuvem (CDR) disponíveis, surge a pergunta: Você deve continuar investindo na construção e manutenção do seu próprio CDR? E se você ainda não foi por este caminho, é uma opção que vale a pena seguir? Para responder essa questão, vamos primeiro olhar o que precisamos para construir capacidades de CDR dentro da organização e então usando essa informação nós iremos considerar se iremos ou não com o método de “faça você mesmo” (DIY).

“A falta de visibilidade operacional sempre foi algo não endereçado na segurança do SaaS.”

Conteúdo relacionado: A Detecção e Resposta em Cloud é o elemento que falta na segurança

Então você quer CDR

Qualquer equipe que for iniciante com a segurança do SaaS terá que considerar as mesmas etapas gerais para começar a pensar sobre a detecção e investigação nos seus ambientes SaaS. Essa seção mostra um pouco do que está envolvido.

Segurança do SaaS

Passo 1: Agregação de dados

O primeiro passo é a consolidação dos dados das aplicações SaaS que você quer monitorar. As aplicações SaaS mais usadas normalmente oferecem formas de extrair dados relacionados a contas, privilégios, funções e atividades através de APIs. Mas cada aplicativo tem um schema API com limites de taxa. Enquanto algumas APIs são bem arquitetadas e estáveis, outras tem sérias limitações e podem mudar frequentemente.

Você precisa extrair dados sobre contas, privilégios e funções (dados de acesso), eventos (dados de atividade) e configurações de serviço. A obtenção destes dados passará por muitas chamadas de API. Esses dados devem ser coletados e armazenados centralmente para análise. Data lakes como o Snowflake e SIEMs como o Splunk oferecem boas opções para armazenamento.

Você tem duas opções quando se trata da extração de dados:

  1. Alguns dos principais SIEM oferecem conectores que tornam mais fácil mandar os logs das aplicações SaaS para o Siem;
  2. Você pode construir seus próprios conectores. Para isso, você deve levar em conta o design do API, o ciclo de vida e os limites de taxa ao projetar a ingestão.
Leia também:  Segurança Office 365: Compartilhamento de arquivos

Passo 2: Normalização dos dados

Apenas jogar o dado bruto dos aplicativos SaaS no SIEM ou no data lake como um fluxo de blobs JSON torna seu uso limitado. Um SIEM é um motor de agregação e correlação de eventos agnósticos. Enquanto alguns SIEMs podem oferecer conectores para aplicações SaaS, os dados extraídos precisam ser limpos e normalizados. Dados de atividade através de serviços existem em diferentes níveis de granularidade e usa marcações e nomenclaturas da plataforma. Então uma vez que os dados são agregados eles precisam ser normalizados para que um analista de segurança ou responsável em responder pelo incidente seja capaz de entender o uso dos dados para detecções e investigações, sem se preocupar com as nuances e diferenças especificas da aplicação. Isso requer que você crie um modelo de dados agnóstico a plataforma que torne fácil para os analistas de segurança explorar e analisar os privilégios e o comportamento do usuário.

Passo 3: Enriquecimento

Dados de diferentes aplicações variam na quantidade de conteúdo disponível. Enriquecendo o dado bruto com informação sobre a geolocalização, ISP, usuários de agente, inteligência de ameaça etc. é o próximo passo. Prender uma conta de usuário e seus privilégios com a sua atividade na nuvem pode ser útil para detectar sinais de atividade suspeita e ameaças internas.

Passo 4: Análises

Depois de centralizar e limpar os dados, a equipe de segurança precisa ser capaz de interagir com eles para saber o que eles são e o valor deles. Aqui é onde as questões precisam ser feitas sobre fluxos de trabalho e casos de uso. Quais tipos de ameaça a equipe quer detectar? Como isso pode acelerar a resposta ao incidente? Esse conjunto de dados enriquecerá os alertas e eventos de outras partes da segurança?

Independentemente das respostas a essas questões, é provável que a equipe queira detectar atividades de múltiplos eventos como eventos de logins suspeitos, inspecionar picos de atividades relacionados ao download e upload de arquivos e auditar a atividade nos níveis de administrador.

Atividades maliciosas nas aplicações SaaS normalmente não geram indicadores simples de comprometimento como IPs ou domínios que representam comando e controle de infraestrutura, então a maioria das detecções irão requerer muito mais do que consultas simples para eventos individuais, aumentando o nível de esforço de esforço para detecção.

Além do mais, as equipes irão querer ver a atividade como uma linha do tempo de eventos para fazer a triagem e investigação das situações. De uma perspectiva técnica, decisões de design precisam ser tomadas sobre como consultas e trabalhos são executados contra conjuntos de dados, assim sobre como analistas e investigadores interagem e se articulam através dos dados.

Você deveria fazer?

A detecção e resposta na nuvem (CDR) oferecem grandes benefícios para assegurar as aplicações SaaS, mas como vimos na sessão anterior, construir e manter um sistema de CDR leva tempo, esforço e especialização.

Então aqui estão algumas questões para você perguntar a si mesmo se construir as capacidades de CDR dentro da organização é a melhor opção para você.

  • Você está pronto para investir em engenharia de dados? O CDR tem várias dependências externas em APIs de terceiros. Sua equipe precisa se manter atualizada das alterações e ajustas as frequências de extração e as arquiteturas de dados. Você também precisa monitorar e resolver problemas de falhas de extração de dados.
  • Você está disposto a esperar meses para construir cada integração de aplicativo? De acordo com os CISOs com quem conversamos, cada aplicação nova requer diversos meses de desenvolvimento e testes. Os engenheiros precisam entender a identidade da aplicação SaaS e o modelo de acesso, estrutura de API e as suas peculiaridades. Mesmo com ferramentas como o Splunk que oferece integrações com aplicações de SaaS populares, você precisaria normalizar e enriquecer os dados.
  • Como você lidará com a rotatividade da equipe? Já vimos diversos projetos em andamento desmoronarem quando um engenheiro ou arquiteto deixou a equipe. Manter um projeto desse tamanho requer planejamento para transições organizacionais. O projeto será uma prioridade de investimentos nos próximos anos? Mantenha em mente que você está levando com si um risco associado com um grande projeto de software.
  • Você tem especialistas de segurança com turnos disponíveis? Com uma solução caseira, você está começando do zero quando se trata de detecções de segurança. Você precisa que especialistas de segurança usem seu tempo com os dados para caça de ameaças e construção de novas detecções de violações de política, atividade interna suspeita, exfiltração de dados e outras ameaças. Com novas ameaças surgindo todos os dias, as equipes de segurança precisam fazer isso com frequência.
  • O seu ambiente tem alguma necessidade especial que uma solução convencional não pode resolver? Antes de ir com tudo na construção das suas próprias capacidades de DR, veja o que uma solução CDR de terceiro como a que a Obsidian oferece. Há diversos benefícios em usar soluções fornecidas por SaaS baseadas em API. Você pode iniciar rapidamente e usa as detecções e alertas inovadoras para melhorar a sua segurança quase que imediatamente. Com um parceiro com uma solução confiável, você consegue uma equipe de engenharia que está dedicada a ter o trabalho de se manter com as alterações na API e construir novas integrações e alertas de segurança. Dessa forma você não corre risco adicional com software. Sua equipe pode focar suas atenções em proteger os usuários e dados ao invés de manter a segurança do software.
Leia também:  A segurança de TI baseada na nuvem irá dominar em 2022

Conclusão

Os dados são o coração da segurança do SaaS. As organizações estão cada vez mais dependentes das aplicações SaaS, as equipes de segurança precisa de visibilidade continua para detectar, investigar e responder a vazamentos e ameaças. Enquanto no passado as equipes precisavam construir suas próprias capacidades de CDR para as aplicações SaaS, novas soluções de CDR se tornaram disponíveis fazendo com que o processo de agregação, normalização e análise dos dados ficassem mais fáceis de se realizar, permitindo que as equipes de segurança focassem em proteger os ativos críticos da organização.

Comente o que achou do artigo