*Por Pierre Rodrigues
Os que me conhecem já sabem, mas para o contexto aqui é importante citar que eu atuo no Movimento Escoteiro já tem um tempão, e eu vou usar um pouquinho do que aprendi por lá pra fazer um contraponto lúdico aqui. O lema do escoteiro é “Sempre Alerta” ou “be prepared”, na versão original concebida pelo criador do Movimento.
Mas estar alerta e preparado para o que? Para as situações adversas, desafiadoras, inesperadas, ou que de alguma maneira possam pôr em risco seus planos, objetivos e estabilidade. Esta resposta se encaixa muito bem em um contexto de cybersecurity.
Já é um jargão de mercado a afirmação de que “não é SE seremos invadidos, mas QUANDO isso vai acontecer”, e se a invasão representa um incidente, significa que precisamos estar alertas e preparados para lidar com esta situação.
O velho chinês Sun Tzu já ensinava que conhecer o inimigo (e a si mesmo) é a chave para o sucesso nas batalhas, e isso tem tudo a ver com o “Be Prepared”! Mas como chegar neste estado? Como alcançar esta condição?
“Quanto mais eu treino, mais sorte tenho”, citação que costuma ser atribuída a Gary Player, Arnold Palmer e Jerry Barber, também vale nestes contextos. No Movimento Escoteiro um dos princípios do Método é “Aprender fazendo”, e isso tem muito a ver com nossos conceitos de Red e Blue Team. São raras as ferramentas usadas por threat actors que não estão ao alcance dos profissionais de segurança, e as técnicas ou estratégias de ataque também são razoavelmente bem conhecidas. Surgem novas, é claro, e por isso é importante permanecer atento, ler bastante, pesquisar muito, e manter-se atualizado. No geral, as ferramentas em si não são nem “do mau” nem “do bem”, elas são só ferramentas! Mau ou bom é o sujeito, ou sua intenção, ao usar e aplicar tais ferramentas.
Então o negócio é treinar bastante para termos “sorte” quando formos para a batalha? Sim, mas o Pérola Negra (não o do capitão Jack Sparrow, o Didi (não o dos trapalhões, o do futebol, o Valdir Pereira)) também tem uma frase célebre: “Treino é treino, jogo é jogo”. Sim, existe uma diferença muito grande nestas situações. É absolutamente inegável que quanto mais você estuda, quanto mais você se prepara, quanto mais você treina para determinada situação, melhores serão suas chances de sucesso, mas existem aspectos, nuances, situações e realidades que só serão materializadas na hora do jogo, na hora da guerra, na hora do risco materializado, na hora de responder a um incidente.
Na intenção de juntar as duas coisas, vou tentar compartilhar um pouco de minhas experiências no jogo para que vocês possam usar no treino. Sem pretender estabelecer uma ordem de importância, vou começar por Identificar um Incidente.
Dispor de mecanismos e capacidade para tomar conhecimento de que algo esteja fora da normalidade é essencial. O tempo de “paz” é o momento certo para você consumir todo o monitoramento possível e estabelecer qual é o “normal” do seu ambiente. Se você não souber qual é a temperatura normal do forno, será incapaz de responder se 180 graus é quente ou frio. Você precisa estabelecer o maior volume possível de pontos de observação e coleta de dados em seu ambiente, de modo a construir o desenho ou curva da normalidade para, a partir desta condição, poder identificar os pontos fora da curva, que podem representar indicadores de um incidente.
Isso não é um trabalho simples, pois os recursos geralmente nos limitam e não conseguimos monitorar todos os pontos que desejamos. Além disso, quando finalmente conseguimos gerar nossa primeira curva da normalidade, é hora de recomeçar e voltar a observar, porque o ambiente é vivo e a curva muda. Se não realizarmos uma permanente manutenção nisso, podemos cair numa condição de falso-positivos ou falso-negativos, e isso é muito ruim, podendo até mesmo derrubar a estratégia com um carimbo de descrédito.
Ainda nesta abordagem de identificar um incidente, outra dica valiosa é não descartar coisas aparentemente pequenas. Outro dia em um debate um colega comentou que muitas catástrofes começam com um evento pequeno e até fácil de tratar. Verdade. Um evento simples de autenticação incomum na VPN pode, em pouco tempo, se transformar em um threat actor com golden ticket no seu ambiente. Se tomarmos como pano de fundo a matriz ATT&CK do MITRE, o que eu chamei aqui de “coisas pequenas” acontecem nas primeiras etapas, um spoofing, um pendrive, um novo host na rede, uma tentativa de logon com conta desabilitada, etc, enquanto as catástrofes vão se materializar nas últimas etapas, quando sua base de dados aparece no Github, quando seus monitores mostram uma mensagem de ransomware, quando sua linha de produção interrompe a operação, ou quando seus clientes, aos milhares, começam a reclamar.
Outro aspecto importante é que você tenha a capacidade de lidar de forma inteligente e tempestiva, com estes eventos. Desenvolver a capacidade de reconhecer a relevância de determinado evento é fator decisivo. É claro que existem situações um pouco mais evidentes, mas a tendência é que estas já cheguem com uma tag vermelha, atribuída automaticamente pelas ferramentas, mas certamente você vai se deparar com eventos que irão demandar uma visão contextual, mais ampla e profunda, que considera a realidade de sua operação, e não espere que isso apareça magicamente na sua tela, fruto de uma inteligência artificial alienígena, porque isso não vai acontecer. E complementando, a janela de tempo para que o spoofing se transforme em golden ticket pode ser surpreendentemente curta, por isso você não pode se dar ao luxo de deixar para amanhã a análise dos eventos.
Resumindo então, trabalhe para dispor de tecnologias e mecanismos que permitam a você desenvolver uma boa condição de visibilidade sobre a segurança do seu ambiente, aplique bastante esforço e inteligência para otimizar esta visibilidade da forma mais assertiva possível, e torne-se capaz de atuar nisso em tempo hábil. Como em qualquer trabalho, mesmo o mais manual, boas ferramentas operadas por trabalhadores despreparados é a receita para um acidente de trabalho, enquanto trabalhadores, por mais experientes que sejam, operando ferramentas inadequadas ou mal preparadas, irão demandar muito mais tempo para realizar o trabalho. Outro dia escrevi para um amigo que tecnologia eficaz e pessoas competentes é a receita para transpor obstáculos.
Até aqui estivemos concentrados na função Detect do NIST CSF. Pense na cabine de comando de uma grande aeronave. Tudo o que for relevante a respeito da aeronave e do voo está transparecendo no grande painel de instrumentos. Os pilotos têm a flexibilidade de tomar café durante o voo, mas a qualquer momento sua atenção pode ser solicitada e decisões rápidas (e às vezes difíceis) podem ser necessárias.
OK. A luz vermelha acendeu! Algum evento gatilhou um workflow e estamos diante de uma suspeita de incidente grave. Sim, até este momento o que temos é uma suspeita, algo que eu chamo de “fato relevante”, algo que não é mais apenas um evento ou algo que tem tratamento automatizado, mas sim algo cuja análise vai nos levar a entender se de fato temos um incidente ou não, e à consequente decisão sobre declarar esta condição. É importante entender que o tratamento de um incidente não se inicia quando a luz vermelha acende, mas sim quando a pessoa responsável declara e comunica que de fato temos um incidente, um risco materializado, e iniciamos o seu tratamento.
A partir deste momento você vai efetivamente colocar em prática o seu treinamento, aqueles exercícios, o planejado, a teoria, o seu plano de resposta a incidentes. O treino se transforma em jogo!
Aproveitando a citação do Plano de Resposta, reflita que diante de um incidente crítico, diversas pessoas estarão ávidas e ansiosas por informação, e se a equipe que estiver operando a resposta for interrompida a cada instante para repassar status, a resposta será prejudicada. Você vai precisar de um porta-voz, e esta não é uma tarefa para qualquer pessoa. É necessário que esta pessoa tenha a capacidade de compreensão do que está acontecendo, entenda com relativa profundidade o que o time de operação está fazendo, e tenha a capacidade de “traduzir” isso tudo de forma adequada para as pessoas. Vai ser importante filtrar a enxurrada de questionamentos, apresentar a resposta A para o público A, B para o público B, e talvez nenhuma resposta para o público C. Sim! Algumas pessoas não precisam de fato receber respostas. Esteja ciente que se você não tem uma pessoa para desempenhar esta função, então esta pessoa é você mesmo. Outra dica importante é agendar checkpoints, momentos específicos nos quais haverá esta interação e os diversos públicos poderão receber atualização do status. Be prepared!
Pois bem, estamos oficialmente diante de um risco materializado, de um incidente em curso, e vamos considerar que você fez o trabalho direitinho e tem uma pessoa cuidando da comunicação. Aqui no artigo é um pouco difícil abordar este tema daqui pra frente. É preciso cuidar para não expor o que não deve e ao mesmo tempo oferecer algo de útil para quem estiver lendo. Eu vou tentar então sumarizar em algumas recomendações.
• Tome muito cuidado com as ações – entenda que você tem um invasor no seu ambiente, que este invasor já pode ter feito centenas de movimentos, e que uma ação sua pode gatilhar a bomba. Por exemplo, bloquear a comunicação com IPs de comando e controle (CC) pode deflagrar a ação de um ransomware, e em menos de 1 minuto após o bloqueio seus equipamentos podem começar a apresentar as temidas telas de resgate. Mas algumas ações podem ser inevitáveis, então analise os possíveis desdobramentos e cerque-se de contramedidas. Pense que sua ação pode resultar na perda do ativo.
• Documente, registre e preserve evidências – lembre que ao final de tudo você vai precisar dar explicações. Talvez o incidente extrapole o contexto interno de sua empresa e você pode ter que explicar para seus clientes ou para a polícia. É muito importante pensar neste momento futuro e se precaver. Pode ser que você tenha uma equipe grande atuando, inclusive com pessoas externas à sua organização e gestão direta, realizando ações operacionais. O mercado oferece algumas ferramentas para apoiar nisso.
• Dívida e delegue – Infelizmente é bastante comum que uma resposta a incidente se estenda por vários dias, e ninguém vai conseguir ficar acordado o tempo todo, nem você. São momentos de muita tensão e decisões difíceis, para os quais é importante uma condição física e psicológica adequada. Todos vão precisar descansar durante a operação. É necessário viabilizar isso e criar mecanismos que permitam que as pessoas que retornam do descanso possam rapidamente entender o que aconteceu nesse intervalo, de modo a retomar suas atividades sem prejuízo para a operação.
• Exercite a humildade – Saiba reconhecer no tempo apropriado que o atacante pode ser tecnicamente superior em relação ao que você dispõe, e seja diligente para buscar apoio externo. Penso que é mais fácil justificar o desembolso de X dinheiros na contratação de serviços especializados diante de um impacto pequeno do que justificar a economia de 2X dinheiros diante de uma situação catastrófica.
• Feche portas – É fundamental identificar com a maior exatidão possível os passos e o caminho percorrido pelo invasor. Provavelmente você vai percorrer este caminho de trás pra frente, até chegar no primeiro passo, no paciente zero, naquele que foi o ponto de acesso, a porta através da qual o invasor conseguiu entrar no seu ambiente. Esta porta precisa ser fechada, caso contrário, logo logo você estará tratando outro incidente, pois o invasor vai entrar de novo pela mesma porta. Ser invadido pode ser visto como uma fatalidade, mas ser invadido de novo do mesmo jeito provavelmente será visto como incompetência – “fool me once, shame on you; fool me twice, shame on me”.
Esta última recomendação já pode nos levar ao pós-incidente. A coisa não termina quando você faz a contenção, a erradicação e a recuperação do seu ambiente. Agora é a hora de gerar relatórios do incidente. Sim, é no plural. São diversos públicos que precisarão de um report final formal sobre o que aconteceu, e estes públicos consomem visões ou abordagens distintas sobre o mesmo fato. Não adianta nada você enviar um relatório escrito em tecniquês para o board. Este também é o momento de pensar a respeito das melhorias que o seu ambiente precisa para evitar que outros incidentes aconteçam.
É comum que um relatório de incidente apresente uma série de recomendações. Não esqueça que cada recomendação destas precisa de um responsável, uma pessoa que irá analisar e responder informando o que será feito (ou não) com cada recomendação. Sim, pode ser que nada seja feito com algumas de suas recomendações. Lembre que assumir um risco também é uma forma de tratá-lo. O que não pode é ficar sem desdobramentos. Você foi o responsável por tratar o incidente! Você conteve, limpou e recuperou o ambiente! Você precisa, habilmente, escalar as suas recomendações, e cuidar delas, com followups periódicos junto aos responsáveis. Uma mesma recomendação (implantar MFA, por exemplo) não deveria aparecer em relatórios de incidentes distintos. Se isso acontecer é sinal de que algo no pós-incidente não funcionou como deveria.
Enfim, acho que, de maneira sintética, e talvez sintética demais, consegui passar o que de mais relevante tenho a oferecer, e não esqueça do lema dos escoteiros: Be prepared!
*Pierre Rodrigues é Information Security na WEG
