Construindo um Programa de Segurança do Zero

Ser contratado como a primeira pessoa de segurança em uma empresa é um tipo específico de caos. Não há fila de tickets, sem ferramentas estabelecidas, e geralmente nenhuma linha de orçamento esperando por você. O que se segue é um mapa aproximado de como esses primeiros 90-180 dias costumam acontecer, e o que realmente move a agulha versus o que apenas parece produtivo.

O que "nada" geralmente significa

Quando as pessoas dizem que uma empresa não tem função de segurança, raramente significa zero controles. Significa nenhum dono dedicado. A engenharia provavelmente habilitou algumas políticas básicas de IAM da AWS, a TI tem algum antivírus distribuído por uma ferramenta MDM, e alguém em finanças tem opiniões sobre SOC 2 porque um cliente perguntou. Seu primeiro trabalho é inventário, não implementação. Antes de escrever uma única política, descubra o que já está rodando: contas na nuvem (e quantas ninguém se lembra de ter criado), ferramentas SaaS com acesso de admin ao código-fonte, e se existe uma única fonte da verdade para offboarding de funcionários. Uma planilha serve para isso. Uma plataforma GRC não é a prioridade ainda.

Os primeiros 30 dias: visibilidade em vez de controle

Resista ao impulso de escrever uma política de uso aceitável na semana um. Ninguém vai ler e não vai parar os riscos reais. Em vez disso, obtenha visibilidade sobre três coisas:

• Identidade: puxe uma lista completa de usuários do seu provedor de identidade (Okta, Google Workspace, Azure AD) e faça referência cruzada com a lista de funcionários ativos do RH. Você vai encontrar contas fantasma.
• Footprint na nuvem: execute algo como aws organizations list-accounts se estiver na AWS, ou verifique o Asset Inventory do GCP, para ver quantos ambientes existem versus quantos alguém consegue nomear de memória.
• Exposição de código e secrets: execute gitleaks detect ou trufflehog filesystem . contra seus repos principais. Encontrar uma chave de API codificada no histórico de commits de dois anos atrás é quase garantido e é uma forma rápida de demonstrar valor.

documente os achados, mas não transforme isso em um relatório de 40 páginas que ninguém abre. Um sumário de risco de uma página com cinco bullet points é lido por um CTO. Um PDF longo não.

Escolhendo seus três primeiros controles

Sem headcount e sem orçamento de ferramentas, você não pode fazer tudo de uma vez. Ordem de operações que costuma funcionar:

1. MFA em tudo que ainda não tem, começando pelo provedor de identidade, depois GitHub/GitLab, depois consoles na nuvem. Isso por si só fecha o caminho mais comum de account takeover.
2. Logging centralizado para eventos na nuvem e autenticação. Mesmo um nível gratuito de uma ferramenta similar a SIEM, ou apenas enviando logs de auditoria CloudTrail/GCP para um bucket com retenção, é melhor que não ter nada quando um incidente acontece.
3. Um plano de resposta a incidentes escrito e conciso, mesmo que com duas páginas: quem recebe o page, quem fala com clientes, quem tem autoridade para desligar algo. Ninguém se lembra de construir isso até o dia que precisa, e aí é tarde demais.

Note que nenhum desses requer um grande contrato de vendor. Requerem decisões e execução.

Conseguindo buy-in sem uma linha de orçamento de segurança

A forma mais rápida de perder credibilidade como primeira contratação de segurança é aparecer com uma lista de desejos de ferramentas antes de mostrar qualquer resultado. Em vez disso, vincule cada pedido a algo concreto: "encontramos três usuários de IAM com chaves de acesso não rotacionadas de 2021" funciona melhor que "precisamos de uma ferramenta CSPM." Enquadre pedidos em termos pelos quais engenharia e finanças já se importam: raio de explosão reduzido, auditorias mais rápidas, menos pages às 2 da manhã. Se a empresa está perseguindo SOC 2 ou ISO 27001, esse prazo de conformidade é frequentemente seu melhor ponto de alavancagem para conseguir recursos, mesmo que conformidade em si não seja o objetivo.

Erros comuns no primeiro ano

Comprar uma plataforma cara (SIEM, EDR, CSPM) antes de ter o processo ou headcount para realmente operá-la é o desperdício de orçamento inicial mais comum. Uma ferramenta de $50k que ninguém ajusta gera ruído, não detecção. Da mesma forma, escrever políticas copiadas de um template sem adaptá-las a como a empresa realmente funciona garante que sejam ignoradas na primeira vez que alguém precisar de uma exceção. E tentar ser dono de tudo sozinho depois dos primeiros seis meses é um caminho para burnout; no momento em que há tração, a próxima contratação geralmente deve ser alguém que possa ser dono de detecção e resposta para que você possa continuar construindo a estrutura do programa.

Segurança do zero é principalmente sobre sequência: veja o que existe, feche as lacunas mais altas, construa processo suficiente para que as decisões não dependam da sua memória, e expanda a partir daí.

Se esse tipo de construção de programa de nível inicial te interessa, Korra Studio tem segmentos relacionados sobre fundamentos de resposta a incidentes e postura de segurança em nuvem que combinam bem com este.