Resposta ao que aconteceu na Tribune Publishing
3 de janeiro de 2019Resposta a incidentes sob o olhar público ou uma análise sobre o que aconteceu na Tribune Publishing
Por Mark Nunnikhoven*
Ciberataques acontecem constantemente.
Todos os dias organizações são atacantes online, quer elas percebam isso ou não. A maioria desses ataques são assuntos de passagem.
O mero fato de que os sistemas estão ligados à internet os torna um alvo de oportunidade. Na maior parte, esses ataques não são eventos.
Softwares de segurança, bugs no código de ataque e aplicativos atualizados param a maioria dos ataques. Com mais de 20 bilhões de dispositivos conectados à Internet, é fácil para o ataque seguir em frente.
Mas a cada duas semanas há um ataque grande o suficiente para atrair manchetes. Você viu um fluxo constante deles nos últimos anos. 10 milhões de registros aqui, milhares de sistemas, e assim por diante.
Quando falamos sobre esses ataques, para a maioria das pessoas, é uma discussão abstrata. É difícil visualizar um conjunto abstrato de dados que vive on-line em algum lugar.
O ataque recente à rede Tribune Publishing é diferente
Este ataque teve um impacto real no mundo. Nos Estados Unidos, os jornais chegaram atrasados e perderam seções significativas de conteúdo.
Timeline
Quinta-feira, alguns sistemas na rede Tribune Publishing estavam inacessíveis. Esta não é uma experiência incomum para quem trabalha em uma grande organização.
A tecnologia trouxe muitas maravilhas, mas a confiabilidade não é tipicamente uma delas. Quando o sistema está inacessível, não é difícil pensar primeiro: “Ugh, isso não está funcionando. Chame-o”.
Os tickets de suporte costumam ser os primeiros ataques cibernéticos … em retrospectiva. Todos os sinais públicos no ataque Tribune Publishing apontam dessa maneira. Depois que o suporte percebeu a extensão do problema e envolveu malware, o evento – uma solicitação de suporte – se transformou em um incidente. Isso inicia um processo de resposta a incidentes (IR).
É esse processo com o qual as equipes da Tribune Publishing estão lidando agora.
Whodunnit?
“Quem está por trás do ataque?” É a primeira pergunta na mente de todos. É da natureza humana – duplamente em uma organização de mídia – querer entender o “quem” e o “por que” em oposição ao “como”.
A realidade é que, para o processo de resposta a incidentes, essa é uma questão que desperdiça tempo. O objetivo do processo de resposta a incidentes é limitar os danos à organização e restaurar os sistemas o mais rápido possível.
Nesse contexto, a equipe de respostas só precisa classificar aproximadamente o atacante. É o atacante;
Um cibercriminoso de baixo nível que tem sorte com um ataque automatizado e tem poucos recursos para continuar ou sustentar o ataque?
Um cibercriminoso que pretende atacar uma classe específica de organização ou sistemas?
Um criminoso cibernético que segmenta sua organização?
Saber qual classe de cibercriminoso está por trás do ataque ajudará a ditar o esforço necessário em sua resposta.
Para um ataque simples, suas defesas automatizadas devem cuidar disso. Mesmo após uma infecção inicial, uma estratégia de defesa em profundidade isolará o ataque e fará a recuperação para frente.
Se o ataque fizer parte de uma campanha maior (por exemplo, WannaCry, NotPeyta, etc.), a resposta a incidentes é mais complexa, mas os mesmos princípios são verdadeiros. A terceira classe de invasores – especificamente visando sua organização – é o que causa uma alteração no processo. Agora você está defendendo contra um adversário que está ativamente mudando sua abordagem. Isso requer uma mentalidade completamente diferente em comparação com outras respostas.
O processo
Os processos de resposta a incidentes geralmente seguem seis etapas;
·Preparar
·Identificar
·Conter
·Erradicar
·Recuperar
·Aprender
No papel, o processo parece simples. A preparação começa com as equipes reunindo informações de contato, ferramentas e escrevendo – ou melhor, automatizando – procedimentos.
Uma vez que um incidente tenha começado, as equipes trabalham para identificar os sistemas afetados e o tipo de ataque. Eles então contêm o ataque para evitar que ele se espalhe. Em seguida, trabalhe para erradicar qualquer vestígio do ataque.
Quando o ataque termina, o trabalho muda para recuperar sistemas e dados para restaurar a funcionalidade. Depois, uma revisão ordenada é conduzida e as lições são compartilhadas sobre o que funcionou e o que não funcionou.
Fácil, certo?
Qualquer respondente de incidentes que ler este post, pode levar um minuto aqui, tendo apreciado uma boa risada. A próxima seção leva todos de volta à dura realidade do IR.
Realidade
As seis fases da resposta a incidentes ficam ótimas no papel, mas quando você está prestes a implementá-las no mundo real, as coisas nunca funcionam tão bem.
A maioria de uma resposta é gasta presa em um loop quase infinito. Identificando novas áreas de comprometimentos para tentar conter o ataque.
Esperançosamente, permitir que os respondentes erradiquem qualquer ponto de apoio para recuperar os sistemas afetados.
É com isso que a maioria das organizações luta. O tempo gasto na preparação é muitas vezes insuficiente porque é tudo teórico. Combinado com o ritmo acelerado de mudança na rede, as equipes se esforçam para acompanhar um incidente ativo.
Com uma organização como a Tribune Publishing, as coisas são ainda mais difíceis. Por sua própria natureza, é um negócio 24 horas por dia, sete dias por semana, com uma grande variedade de usuários em todo o país. Isso significa que há muitos sistemas a serem considerados e cada hora de inatividade tem um impacto muito real e significativo na linha de fundo.
Conforme o incidente progride, a equipe de resposta tomará uma decisão crítica após uma decisão crítica. Desligando vários serviços internos para protegê-los.
Alterando estruturas de rede para isolar atividades maliciosas. E uma série de outros desafios surgirá durante o incidente.
É difícil, difícil trabalho de condução. Feito duplamente com os olhos da gerência sênior, dos clientes e do público em geral.
Foco
Como líder de equipe de resposta a incidentes ou CISO, você precisa se concentrar no processo de RI e não na atribuição. É por isso que é preocupante ver a atribuição antecipada durante um incidente.
No ataque Tribune Publishing, foi relatado publicamente que o ataque veio de fora dos Estados Unidos. Isso leva à especulação em torno da motivação. É provável que essa declaração tenha sido baseada no malware encontrado e nas informações de endereço IP simples.
No início do processo de RI, evidências como essa serão encontradas. É facilmente acessível, mas também altamente não confiável. O malware é frequentemente vendido no subsolo digital e os endereços IP são facilmente falsificados ou proxied. A equipe de resposta sabe disso, mas a pressão do nível mais alto pode exigir alguma forma de resposta … quer ajude ou não a resolver a situação.
A equipe deve manter o foco na resolução do incidente, não gastando tempo e energia valiosos sendo acompanhados. A atribuição tem o seu lugar. Definitivamente não está no meio da resposta a um incidente.
Prática
A única verdade difícil da resposta a incidentes é que nada pode substituir a experiência. Dado o fato – esperançosamente óbvio – de que você não quer realmente ser atacado, isso leva ao conceito de um dia de jogo ou uma simulação ativa.
Popular em ambientes de nuvem – a AWS executa dias de jogos em seus eventos – esses exercícios proporcionam experiência prática. Normalmente realizado para a equipe de operações, eles são de importância crítica para a equipe de segurança também.
A segurança não funciona no vácuo, especialmente durante um incidente. Trabalhar com outras equipes durante um incidente é fundamental. Praticar assim é uma obrigação. Esse tipo de trabalho é um grande esforço, mas que vale a pena quando uma organização é atacada.
Próximos passos
A Tribune Publishing foi atingida por um ciberataque com impacto no mundo real. Esse nível de visibilidade é um lembrete gritante de como essas situações podem ser desafiadoras. A fase mais crítica da resposta a incidentes é a primeira: preparação.
Como CISO ou membro sênior da equipe de segurança, você precisa preparar não apenas o plano de resposta a incidentes. Com um plano em mãos, você precisa ter outras equipes a bordo e deixar claro para a gerência sênior como esse processo funciona. Crítico para o sucesso é garantir que o gerenciamento saiba que a prioridade é a recuperação … não a atribuição.
Combine isso com muita prática e, quando o próximo incidente acontecer, você colocará sua equipe em uma posição razoável para responder e se recuperar rapidamente.
*Mark Nunnikhoven é vice-presidente para Pesquisas em Cloud da Trend Micro
Ransomware suspected in cyberattack that crippled major US newspapers