Segurança da informação - SecOps e SOC

Operações de Segurança: SecOps e SOC

As operações de segurança podem parecer muito diferentes de empresa para empresa, variando muito em tamanho e maturidade. Se as funções de segurança são um simples dispositivo de gerenciamento e incidente, ou são centros de controle de missão completos com os mais altos níveis de proteção, cada um compartilha o mesmo objetivo: prevenir, identificar e mitigar ameaças à organização.

Embora as equipes de cibersegurança continuem a evoluir graças a novas tecnologias e filosofias, temos de entender as diferenças conceituais entre SecOps e o SOC, e como eles podem trabalhar juntos para a empresa moderna.

O que é SecOps?

As Operações de Segurança (SecOps) são a combinação entre segurança de TI e operações de TI para mitigar efetivamente os riscos. Os membros da equipe da SecOps assumem responsabilidade conjunta e propriedade por quaisquer preocupações de segurança, garantindo que a segurança seja infundida em todo o ciclo de operações.

Historicamente, as equipes de segurança e operações muitas vezes tinham objetivos de negócios diferentes e conflitantes. As equipes de operações estavam focadas na criação de sistemas de forma a atingir metas de desempenho e tempo de atividade. As equipes de segurança estavam focadas em cumprir os requisitos regulatórios, colocar defesas e responder a preocupações de segurança.

A desvantagem desse modelo é que a segurança era abordada como um algo que “a gente vê depois”, às vezes até visto como um fardo que desacelera operações, criando sobrecarga. Porém, à medida que as ameaças continuam a aumentar e se tornar mais sofisticadas, muitas organizações estão reconhecendo que esse ambiente do passado não está mais atendendo às necessidades dos negócios modernos.

Com a adoção de uma equipe de SecOps integrada na equipe de desenvolvimento, a Looplex passou a injetar segurança em todo o processo de operações, a partir do início. Abordar a segurança desde a “estaca zero” garante que estejamos atendendo aos requisitos e projetando sistemas com a segurança em mente. Esse pensamento "shift-left" permite que a segurança funcione coesamente na configuração de um sistema e também desafia os membros da equipe de operações a ajustar a forma como criam e desenvolvem as soluções em nossa plataforma.

O que é SOC?

Um Centro de Operações de Segurança (SOC) é um grupo de profissionais de segurança que trabalham juntos para:

1. Identificar e mitigar proativamente os riscos de segurança contra a empresa

2. Defender contra quaisquer violações de segurança

No passado, este SOC era na verdade uma instalação física com enormes proteções cibernéticas. Dentro de um SOC, a equipe monitorava estatísticas de segurança e alertas. Nosso SOC, tal como de outras empresas de arquitetura cloud-first, é totalmente virtual, mas os papéis e responsabilidades do SOC não mudaram.

Para SOCs que estão seguindo as melhores práticas, algumas de suas responsabilidades esperadas incluem:

• Aplicando conformidade (compliance)

• Teste de penetração

• Planejamento de arquitetura

• Teste de vulnerabilidade

• Inteligência de ameaças

• Analisando dados de log e eventos

• Identificando e respondendo a incidentes

• Gerenciamento de identidade e acesso

• Gerenciamento de chaves

• Administração de firewall

• Gerenciamento de endpoint

Não é difícil imaginar que equipes invariavelmente ficam sobrecarregadas, com pressão crescente causada pela quantidade massiva de dados, escassez de habilidades, aumento de equipes remotas e preocupações de segurança. No entanto, ao incorporar algumas metodologias modernas, nossa equipe de segurança passou a compartilhar a responsabilidade com outros membros da empresa, aumentando suas capacidades de identificar riscos proativamente e mitigar ameaças.

Integrando SecOps no SOC

O SecOps em si é um conjunto de processos, ferramentas e práticas SOC que ajuda as empresas a cumprir suas metas de segurança de forma mais bem-sucedida e eficiente. No entanto, o SOC clássico não é compatível com a cultura SecOps. No passado, o SOC ficava completamente isolado do resto da organização, desempenhando suas funções específicas sem muita interação com outras partes do negócio.

Hoje, a segurança deve ser um esforço conjunto. Um SOC moderno é aquele que promove a colaboração e a comunicação entre as operações e equipes de segurança, por isso resolvemos integrar segurança nos processos de TI e desenvolvimento.

Na Looplex distribuímos o SOC (a) tirando a segurança de seu silo e espalhando responsabilidades entre departamentos, (b) estabelecendo uma cultura de colaboração, abrindo o SOC e CSIRT para qualquer membro cujas funções tenham impacto de segurança; (c) criação grupos de estudo e melhores práticas com membros selecionados das equipes.

Mais do que isso, na Looplex incorporamos o SOC e SecOps diretamente no desenvolvimento, tornando o nosso time em DevSecOps.

SecOps e DevSecOps oferecem maneiras de incorporar segurança em todo o ciclo de vida do produto

SOC vs. CSIRT: qual é a diferença?

No mundo de segurança de operações, é comum escutar menções a CSIRT, CIRT, CERT e CIRC, além do já mencionado SOC. Em resumo, os quatro primeiros normalmente são tratados como sinônimos para descrever times focados em respostas à incidentes, enquanto o SOC tipicamente tem um escopo mais amplo de segurança digital ou cibersegurança.

Entender a terminologia nos ajuda a evitar mal-entendidos, o que pode prejudicar os esforços de planejamento e adoção das melhores práticas.

CSIRT, CIRT, CERT e CIRC

• CSIRT é um acrônimo para Computer Security Incident Response Team;

• CERT quer dizer Computer Emergency Response (ou Readiness) Team,

• CIRT é usado como Computer Incident Response Team, ou menos frequentemente, Cybersecurity Incident Response Team;

• CIRC é usado como Computer Incident Response Center ou Computer Incident Response Capability

Esses termos são usados no mercado quase como sinônimos entre si e, como não há uma padronização formal, adotaremos CSIRT por parecer ser o mais popularmente usado atualmente.

Então podemos dizer que

CSIRT ou Computer Security Incident Respose Team é uma entidade organizacional (ou seja, composta por uma ou mais pessoas) para a qual foi delegada a responsabilidade de coordenar e dar suporte para responder a um evento ou incidente de segurança.

O CSIRT e seus irmãos sopa de letrinhas podem existir de forma permanente e dedicada, ou podem ser criados de maneira ad hoc em resposta a um evento. Em qualquer um dos casos, ele está sempre focado nas quatro fases de resposta a um incidente (ou evento de segurança, se um potencial problema fora identificado, mas ainda não gerou um incidente):

• Preparação

• Detecção e análise

• Contenção, erradicação e recuperação

• Atividades pós-incidente para prevenir novas ocorrências

As responsabilidades de um time de SOC muitas vezes englobam, no todo ou em parte, essas tarefas.

Como na Looplex temos um time de segurança de operações (SecOps) embedado na equipe de desenvolvimento – para implementação do conceito integrado de DevSecOps – decidimos que embora o time de SecOps tem um grupo de responsabilidades permanentes, podemos também criar caso a caso times de CSIRT, tal como montamos times para execução de projetos de engenharia jurídica ou desenvolvimento.

Dessa forma, sempre que um incidente ou evento de potencial incidente for identificado, comporemos um time de CSIRT para atuar nas já mencionadas (a) preparação, (b) detecção e análise, (c) contenção, erradicação ou mitigação e recuperação; (d) atividades pós-ocorrência para fortalecer nossa segurança e prevenção futura.

Caso concreto: criação do CSIRT na Looplex

Essa dinâmica já ocorreu uma vez, por exemplo, em resposta à notícia de uma vulnerabilidade de segurança zero-day (ou seja, para a qual não havia patch disponível ainda) do Java Spring Framework (CVE-2022-22965), que colocou em risco de invasão literalmente milhões de servidores e aplicações em todo o mundo.

Um de nossos membros viu o alerta dado por toda a comunidade – esse evento foi tão grande que foi publicado na mídia tradicional de todo o planeta – e no mesmo dia compusemos um time CSIRT para investigar se tínhamos uma das vulnerabilidades identificadas.

O time era composto pelas pessoas de SecOps, do CTO e de um dev sênior conhecedor dos sistemas potencialmente afetados.

A resposta, felizmente, foi negativa; não usávamos em nenhum lugar do nosso Stack o componente comprometido e, portanto, a vulnerabilidade não nos impactava. Após definição das medidas de prevenção futuras (bloqueio de uso do componente em qualquer projeto futuro por algum desenvolvedor desavisado), que adicionou mais uma camada de segurança em nossos sistemas para eventos similares, o time CSIRT foi desfeito, com os seus membros retomando suas atividades diárias.