Apesar
disto, vi alguns problemas estruturais na minha segunda revisão do framework. O
Framework tem muita informação dispensável sobre políticas e procedimentos de
segurança e não tem suficientes dados sobre a importância da colaboração e de
compartilhar inteligência sobre ameaças. Ele não contém nenhuma menção de
investigações proativas, muito menos investigações forenses proativas. O
framework contém uma vasta quantidade de detalhes sobre regras e processos para
assegurar a segurança da informação, mais muito pouca informação sobre
requisitos e procedimentos para que as organizações trabalhem juntas. O
framework também tem um grande buraco na sua categorização da detecção e da
reposta às ameaças.
A detecção é o ponto de tração
O framework
lista cinco funções para a execução: Identificação, Proteção, Detecção, Resposta
e Recuperação. Destas cinco, a “detecção” é da que deveríamos nos preocupar.
Identificação: Saber o que é que precisa ser protegido.
Infelizmente, isto é só um sonho: as equipes de segurança da informação têm
tentado fazer isto por décadas sem sucesso. Não é uma novidade, e pôr isto no
framework não vai mudar nada.
Proteção: Todas as políticas, procedimentos e controles
de acesso envolvidos. Isto ajuda, mas a maioria das ameaças atuais estão
engenhadas para contornar estes controles.
Resposta: Contenção, erradicação e notificação são
importantes, mas o que estamos vendo atualmente é que este passo ocorre muito
tarde para ter um impacto real. No momento em que damos este passo, o prejuízo
já foi feito.
Recuperação: Administrar as relações públicas e o dano à
reputação. Provavelmente o passo menos importante do processo.
Todo este
enfoque em protocolo de segurança, permissões e reputação é louvável, mas ao
final das contas, a detecção é o ponto de tração. A pesar da nossa sempre
crescente habilidade em criar controles de acesso e políticas de segurança,
continuamos vendo um maior número de invasões. Os hackers black-hat vão continuar encontrando maneiras de
contornar protocolos, procedimentos e controles de acesso. Se você não pode
detectar o ataque, você não pode respondê-lo nem recuperar-se.
E as divergências à base de referência?
A detecção
é onde nos preocupamos com dar passos ousados e representa nossa maior
oportunidade de colaboração. Estou feliz de ver que “as anomalias e os eventos”
foram classificados como os primeiros passos na detecção. Temos estado falando
sobre “eventos” e “administração de eventos” durante anos, mais todos sabemos
que as palavras mais amedrontadoras da língua Portuguesa são: “O que é isso? Tá
meio estranho”.
Uma coisa
estranha ou peculiar (em resumo, uma anomalia) é usualmente a primeira pista de
um potencial incidente de segurança. Infelizmente, normalmente as ignoramos.
Precisamos
enfocar-nos na detecção da anomalia e ver a diferença no seu comportamento em relação
a sua ação normal. A primeira subcategoria do framework na detecção (DE.AE-1)
pede estabelecer uma base de referência do comportamento normal, mas não há uma
menção explícita sobre detectar divergências em relação à base de referência.
Estas divergências do comportamento normal comumente são a única indicação de
uma Ameaça Avançada Persistente: um ataque que certamente contará com malware
personalizado que evadirá todos os sistemas de detecção baseados em
assinaturas.
Eu também
gostaria de ver uma menção explícita de investigações forenses proativas. Esta
é uma prática é realizada por muitos grupos de segurança ao redor do mundo, mas
gera pouca discussão. Os grupos de segurança bem informados comumente auditam
vários componentes nas redes, mesmo sem causa alguma, para detectar incidentes
antes que cresçam. Não vejo nenhuma menção disto aqui.
Paranoia Vs. Colaboração
Tenho outro
problema com o framework em geral: a falta de uma linguagem colaborativa. ID.RA-2
discute como receber informação sobre ameaças a partir de recursos de
compartilhamento de informação, mas não como contribuir informação. PR.AT-3
fala sobre como terceiras partes precisam entender suas próprias
responsabilidades, mas não inclui nada sobre como assignar responsabilidades.
DE.CM-6 fala sobre monitoração dos provedores externos de serviços. RS.CO-5 usa
o termo “voluntária” para descrever a coordenação com partes interessadas fora
da organização caso ocorra um evento ou incidente. Finalmente, RC.CO-1 e
RC.CO-2 discutem a reparação da reputação e das relações públicas, sem falar de
como divulgar claramente uma ameaça ou como prevenir que outras organizações
sofram um ataque similar.
Isto não é
colaborativo, é paranoico. Entendo que todos estamos participando em uma defesa
mundial, que todos precisamos planejar nossos próprios procedimentos, mas
precisamos mais informação sobre colaboração. Entendo a necessidade de proteger
a reputação de uma organização e entendo a natureza altamente competitiva do
ambiente corporativo, mas os “caras bons” devem trabalhar juntos senão o
panorama das ameaças cibernéticas somente ficará mais assustador, e os “caras
ruins” serão os beneficiados.
Considerações Finais
A final de
contas, estou contente com o framework?
Em uma
palavra, sim. Acho que o framework preliminar é um bom começo, até ótimo. Seus
autores reconhecem claramente a necessidade de que este seja um padrão
crescente e mutante, oferecendo áreas para melhoras potenciais.
Mas é isso, só um começo.
Precisamos
ter mais conversações sobre colaboração contra ameaças e detecção de ameaças
antes que causem estragos, e menos sobre reparação da reputação quando o dano
já foi ocasionado. Esse é o caminho que oferece um maior benefício a todos, e é
o caminho que espero que o framework siga no futuro.
Artigo original em inglês escrito por Jason
Fredrickson, Diretor Senior de Desenvolviento de Aplicações Empresariais da
Guidance Software.
RELACIONADOS
No comments :
Post a Comment