Nos últimos 20 anos tem sido fomentada a monitorização reactiva.
No entanto, como vamos ver, algumas vezes pode ser mais um problema que uma solução.
A monitorização reactiva/automática, é quando existe uma resposta automática (comando, script, etc) a um determinado evento, indo para além da sua notificação.
Muitas vezes, existe a tentação de utilizar a reação automática a um alarme como uma solução, quando, na verdade, o que normalmente está a acontecer é que se está a utilizar esta forma de actuar para esconder um problema que pode ser muito mais profundo e de consequências imprevisíveis.
Um reactivo deve ser utilizado apenas como uma solução pontual e única perante um evento que já foi devidamente mitigado e analisado.
Por norma, e de modo similar, é o que se passa com quase todos os incidentes em TI: não interessa se são “resolvidos” muitos por dia, o real problema é eles existirem, pois a sua existência repetida significa que não foi efetuado o trabalho de modo profundo e completo para deixarem de ocorrer ditos incidentes.
Assim, na perspetiva de Segurança da Informação, os reactivos serão úteis?
A monitorização deteta sempre eventos que já ocorreram (o filesystem já desmontado, o CPU já sobre utilizado, o tráfego de rede que não deveria ter existido, o vírus ou “payload” que não deveria existir, mas que já foi carregado, etc).
No entanto é essencial para a segurança da informação a detecção, mesmo que se refira a eventos do passado e que não seja garantida uma resposta atempada (normalmente nunca o é…), pois, só devido à correcta mitigação, analise e implementação correctiva, se irá, de forma proactiva, permitir que, no futuro, o respectivo evento não volte a ocorrer.
É como pôr um alarme na porta de entrada de uma casa: pode ajudar a evitar alguns furtos, ou não, mas confiar apenas nele e nas suas possíveis reacções é algo muito limitado, pois podem existir furtos ou roubos por outros métodos. Mas, se for mitigado o que é possível de furtar, todas as possibilidades do “como” e deixar de ser aliciante efetuar o furto (retirando os “valores” de casa, por exemplo), esse alarme passa apenas a aviso, onde os impactos do furto deixam de existir. Com as monitorizações reativa e proactiva passa-se o mesmo.
Todas as formas automáticas devem ser sempre cautelosas; Imaginam desativar um PLC, ou um servidor financeiro de forma automática e paralisar o negócio? Claro que não…
Mas a informação é muito útil, de modo a impedir que essa reação automática a um evento deixe de ser necessária, pois foi mitigado de modo a prevenir e como ação proactiva.
Uma vez que Segurança da Informação é mitigar e prevenir, como é que então se enquadram os reativos?
Os reativos, no contexto da segurança de informação, devem ser enquadrados numa mitigação.
Quando é criada uma arquitetura de TI (não apenas no “fácil”, “óbvio” e “comercial”), é possível desde logo criar “zonas” ou “áreas” de vários níveis, onde se podem criar “locais” de controle sem impactos no negócio.
Imaginem por um momento um castelo, onde:
- em primeiro lugar se tem a arriba ou fosso;
- depois a barbacã;
- a seguir a cintura exterior com a primeira entrada;
- posteriormente a cintura da praça de armas (normalmente oposta à entrada) com a 2ª entrada;
- por fim a Torre de Menagem com mais algumas barreiras de acesso.
Ou seja, quanto “mais dentro” entram os atacantes, mais vulneráveis e expostos estão e mais controlados, embora sem nunca impedir ou limitar o objetivo do mesmo (um bom exemplo é o Castelo de Almourol).
Assim, é relativamente fácil, de forma prévia, criar esses “controles”, onde a capacidade reativa é possível e desejável, sem, no entanto, pôr em perigo o negócio e a sua continuidade.
Resumindo
Reativos são muito úteis, mas:
- Não devem esconder problemas;
- Não são uma forma de mitigação nem resolução;
- Não devem ser utilizados como uma consequência da “nossa preguiça”;
- Devem ser utilizados de forma:
- A serem mínimos e quânticos;
- A não terem impactos no negócio.
- Não devem ser utilizados como forma de “operação automática” nem como “panaceia universal”.
Aplicando e seguindo os princípios anteriores, estes já não vão ser aplicados de forma “expedita” ou “leviana”, mas sim utilizando o que eles têm de melhor.
Entre a “monitorização proativa” e a “monitorização reativa” a escolha é óbvia.
Não esquecer, que a resolução e prevenção não é efetuada pela monitorização, mas sim, por tomadas de decisão e mitigação de forma proactiva (a monitorização apenas fornece dados).
Exemplo: um alarme não previne o roubo; isso é apenas conseguido mitigando as condições de acesso e o aliciante para o tentar levar a cabo.
Deste mesmo modo a plataforma Sentinelya é uma forma de concentração e mitigação dos eventos detetados pela monitorização contínua.
Mais informação em: