Dois artigos no blog da SANS me chamaram a atenção recentemente. Ambos tratam de algo que já comentei há algum tempo aqui no blog, sobre uma lei lançada em alguns estados nos Estados Unidos onde exige-se uma licença de Private Investigator para trabalhar com Forense Computacional. Nem é preciso dizer o quanto de ruído que deu essa lei por lá. O mais interessante é que agora, quase um ano depois, já podemos ver claros desdobramentos da lei e os problemas colaterais que ela causou. Alguns são surreais ...
- No Texas, uma empresa que opera sinais de trânsito e câmeras de vigilância foi taxada como estando violando a lei porque essa atividade exigiria a tal licença de PI, e a empresa não tinha. Isso tudo porque a empresa usa as imagens como evidencia em processos judiciais.
- Isso desencadeou um efeito cascata, porque todo mundo que foi multado por lá a partir de imagens dessas câmeras alegou que tal evidência deveria ser inaceitável, por ser ilegal. Estão querendo o dinheiro das multas de volta ...
Surreal, não ? Mas ainda não acabou !
- Em Michingam, essa lei foi posta em prática imediatamente. Vários "Computer Forensics Practitioners", como eles chamam os peritos/praticantes de Informática Forense, tiveram de largar casos em que estavam trabalhando do dia para a noite. A lei considera crime doloso quem investiga ou faz perícia envolvendo Informática e não tem a tal licença, e ainda por cima não considerou nenhum caso de "grandfathering" (alguma regra que garanta licença automática para os que tenham n anos de experiência, ou algo parecido).
- Nos casos em Michigam, algo que foi bastante criticado é que a nova lei não criou condições ou requisitos novos para quem já tinha a licença de Private Investigator. Ou seja, na intenção de proteger a qualidade dos resultados das perícias, exigindo a licença, acabaram dando um tiro no pé ao autorizar quem não tem o mínimo de conhecimento a fazê-lo só porque já tinha a licença antes da lei.
- A lei chegou por volta de maio de 2008, mas em outubro ainda havia muita gente dizendo que faltava informação sobre quais seriam os requisitos a serem apresentados que qualificariam para receber a licença. Somente então decidiram criar um grupo de trabalho para discutir a questão.
- Durante a discussão, percebeu-se que os requisitos atuais para a licença de Private Investigator (são vários, mas entre eles está ter feito uma graduação na área de justiça criminal ou administração policial, ou ainda ter experiência anterior como agente da lei) eram muito onerosas para quem somente faz ou atua com Forense Computacional.
- Entre os requisitos que acabaram ficando estão ser um CISSP (ou CISA, CISM, etc) e uma certificação forense específica que envolva teoria, prova escrita e prática. No fim das contas, o requerente precisará ser um CISSP + SANS GCFA Silver ou Gold. Isso da noite para o dia.
Levando-se em consideração que muita gente tem essa atividade como ganha-pão, já podemos ter uma idéia de como as coisas ficaram por lá.
Ah, antes que você imagine alguma esperteza do tipo "basta se mudar de lá", esse tipo de lei está virando moda ... Vai ser difícil correr, hein ?!?
Comentários ???
Até o próximo post !
Mostrando postagens com marcador Leis. Mostrar todas as postagens
Mostrando postagens com marcador Leis. Mostrar todas as postagens
quarta-feira, 28 de janeiro de 2009
terça-feira, 23 de dezembro de 2008
Resposta a Incidentes para gente grande
Por enquanto, acredito que podemos dividir quem pratica Resposta a Incidentes de Segurança de Informações em mais ou menos dois grupos:
- Os que nunca fizeram nada a respeito, e provavelmente nem vão fazer;
- Os que fingem que fazem alguma coisa.
Para não ser injusto com a turma que trabalha em Telecom e/ou o pessoal específico dos grupos de resposta em backbones, vou tirar eles desses dois grupos. Talvez a eles não se aplique o que vou escrever aqui, mas tenho visto que se aplica a maioria dos pobres mortais.
O primeiro grupo é composto por empresas que, de uma forma ou de outra, não sofrem pressão regulatória, e acabam por não ter histórico de incidentes que justifique um investimento em um time de Resposta. O problema é que isso provavelmente nunca vai acontecer até que algo realmente ruim (e dos grandes) ocorra. Isso porque a turma, no geral, não aprende a identificar os diversos problemas que ocorrem como incidentes, e portanto ficam se agir diretamente sobre a fonte de alguns problemas.
O outro grupo pode ser até pior. É aquela turma que recebeu um "apronte logo isso para segunda-feira" e correram a Internet na busca de montar (ou pegar pronto, que seja) um manual de resposta a incidentes que possa ter seu título trocado e imediatamente publicado. Ninguém na organização está realmente a par do que precisa ser feito em caso de um incidente, mas o manual é uma beleza, muito bem diagramado ...
Esse quadro vai mudar. Por bem ou por mal, na verdade. Não posso prever quando, até porque aqui na nossa terrinha amada a tendência de certas coisas é andar em um rítmo mais lento, mas a coisa já está pegando por aí. Nos EUA já está virando moda cada setor lançar um regulamento ou norma específica tratando sobre a perda de dados de clientes (os chamados PII - Personal Identifiable Information). HIPAA e PCI já implementam versões de normas que tem por objetivo fazer a empresa que teve dados de clientes comprometidos a ir na Mídia se explicar. Imagine você se um CEO gosta de fazer aquela cara de bule e ficar se explicando para jornalista ... O resultado disso é um aumento substancial na conscientização dos envolvidos em Resposta a Incidentes, de quem trabalha com resposta imediata (os First Responders) ao pessoal da faxina digital. Infelizmente, por aqui ainda não tem nada parecido, apesar do PCI DSS estar sendo auditado.
O que teremos quando esse quadro mudar, principalmente por conta dessas novas regulamentações ?
- A fase de Preparação vai finalmente ganhar importância. Os dias estão contados para aquele quadro recorrente de chegarmos a um local para fazer algum levantamento e termos a desapontadora resposta de que não há nenhum tipo de log no ambiente. A fase de Preparação, muito ignorada por enquanto, vai ser levada a sério. Teremos um aumento nos treinamentos sobre Incident Response e os softwares que permitem capturar detalhes do estado da máquina com maior facilidade vão se tornar mais frequentes e parte do orçamento de qualquer boa empresa preocupada com seus clientes e seus dados. Os softwares versão Enterprise, a exemplo do F-Response e do EnCase, permitirão procedimentos mais efetivos.
Um pequeno comentário aqui: Sou o único aqui que tem problemas em marcar treinamento para a equipe que compõe o CIRT ? Sou o único a ter dificuldades, como gestor, de mostrar que um grupo que se diz CIRT não pode achar que Resposta a Incidentes é desligar a máquina na parede (o famoso pull-the-plug) ?
- A memória vai assumir um status tão importante quanto o HD na Resposta a Incidentes. O CIRT vai estar preparado e com ferramentas para realizar não só os inúmeros comandos que capturam o estado da máquina, suas conexões e outros itens, mas também estará preparado para capturar a memória e analisá-la.
- Verdadeiras equipes de Resposta a Incidentes vão aprender que a rotina deles é muito parecida com a de uma turma de ER de hospital. Triagem será uma operação fundamental na fase de Contenção, na medida em que mais eventos (incidentes) grandes acontecem e atingem mais servidores em uma rede. Um excelente artigo do HogFly explica alguns detalhes sobre esse assunto, mas basicamente a equipe terá que seguir cada vez mais uma ordem de prioridades para determinar quem será "atendido" primeiro. Em um caso de ER, uma pessoa que chega possui as classificações de atendimento Morto, Imediato, Menor grau e Pode aguardar (ou postergar). Um servidor atacado e comprometido em um datacenter com vários outros vai entrar em uma fila de acordo com classificações parecidas. HogFly sugere que a ordem de atenção para conter o impacto de um incidente, e a consequente hemorragia de informações, seja:
4) Servidores que não podem ser bloqueados no perímetro;
3) Servidores/Sistemas que não podem ser colocados offline;
2) Servidores/Sistemas que podem ser bloqueados no perímetro;
1) Servidores/Sistemas que podem ser colocados em offline;
- As metodologias irão amadurecer, baseadas principalmente em procedimentos já bastante maduros em disciplinas correlatas. Uma extensão ao manual de resposta a incidentes que trate casos comuns de incidentes e respostas pré-estudadas, com detalhes nos procedimentos, será comum nas empresas. Os detalhamentos deverão documentar, por exemplo, como um tipo específico de incidente pode ser detectado.
- O CIRT vai finalmente ganhar independência para agir. Os que já precisaram de atuar em uma Resposta a Incidente sabe como é frustrante coordenar um grupo que não é coeso, geralmente composto por equipes distintas e com gestores que nem sempre cooperam. Hoje, o CIRT é obrigado a agir, mas ainda tem uma dependência enorme das áreas operacionais. Em geral, elas acabam por emperrar o processo. Mas isso também está para acabar. O CIRT não poderá ficar de braços cruzados, esperando que a turma operacional habilite alguma coisa, para que ele comece a atuar. Em resumo, enquanto isso acontece hoje, o impacto do incidente continua agindo e, em geral, piorando a situação. Hackers agradecem. Com a independência do CIRT, assim que o incidente for detectado e o CIRT acionado, ele ganha uma espécie de status semelhante a um Estado de Sítio ou de Calamidade Pública. O CIRT passa a ter a agilidade necessária para fazer parar o incidente, atuando efetivamente na contenção, ao invés de ficar com as mãos amarradas.
Você poderia comentar como funciona a sua estrutura de resposta a incidentes ? Você passa ou já percebeu alguma das situações escritas aqui ? Já foi acionado para conter um incidente e quando chegou lá já tinham formatado tudo ? Comente !!!
Até o próximo post !
- Os que nunca fizeram nada a respeito, e provavelmente nem vão fazer;
- Os que fingem que fazem alguma coisa.
Para não ser injusto com a turma que trabalha em Telecom e/ou o pessoal específico dos grupos de resposta em backbones, vou tirar eles desses dois grupos. Talvez a eles não se aplique o que vou escrever aqui, mas tenho visto que se aplica a maioria dos pobres mortais.
O primeiro grupo é composto por empresas que, de uma forma ou de outra, não sofrem pressão regulatória, e acabam por não ter histórico de incidentes que justifique um investimento em um time de Resposta. O problema é que isso provavelmente nunca vai acontecer até que algo realmente ruim (e dos grandes) ocorra. Isso porque a turma, no geral, não aprende a identificar os diversos problemas que ocorrem como incidentes, e portanto ficam se agir diretamente sobre a fonte de alguns problemas.
O outro grupo pode ser até pior. É aquela turma que recebeu um "apronte logo isso para segunda-feira" e correram a Internet na busca de montar (ou pegar pronto, que seja) um manual de resposta a incidentes que possa ter seu título trocado e imediatamente publicado. Ninguém na organização está realmente a par do que precisa ser feito em caso de um incidente, mas o manual é uma beleza, muito bem diagramado ...
Esse quadro vai mudar. Por bem ou por mal, na verdade. Não posso prever quando, até porque aqui na nossa terrinha amada a tendência de certas coisas é andar em um rítmo mais lento, mas a coisa já está pegando por aí. Nos EUA já está virando moda cada setor lançar um regulamento ou norma específica tratando sobre a perda de dados de clientes (os chamados PII - Personal Identifiable Information). HIPAA e PCI já implementam versões de normas que tem por objetivo fazer a empresa que teve dados de clientes comprometidos a ir na Mídia se explicar. Imagine você se um CEO gosta de fazer aquela cara de bule e ficar se explicando para jornalista ... O resultado disso é um aumento substancial na conscientização dos envolvidos em Resposta a Incidentes, de quem trabalha com resposta imediata (os First Responders) ao pessoal da faxina digital. Infelizmente, por aqui ainda não tem nada parecido, apesar do PCI DSS estar sendo auditado.
O que teremos quando esse quadro mudar, principalmente por conta dessas novas regulamentações ?
- A fase de Preparação vai finalmente ganhar importância. Os dias estão contados para aquele quadro recorrente de chegarmos a um local para fazer algum levantamento e termos a desapontadora resposta de que não há nenhum tipo de log no ambiente. A fase de Preparação, muito ignorada por enquanto, vai ser levada a sério. Teremos um aumento nos treinamentos sobre Incident Response e os softwares que permitem capturar detalhes do estado da máquina com maior facilidade vão se tornar mais frequentes e parte do orçamento de qualquer boa empresa preocupada com seus clientes e seus dados. Os softwares versão Enterprise, a exemplo do F-Response e do EnCase, permitirão procedimentos mais efetivos.
Um pequeno comentário aqui: Sou o único aqui que tem problemas em marcar treinamento para a equipe que compõe o CIRT ? Sou o único a ter dificuldades, como gestor, de mostrar que um grupo que se diz CIRT não pode achar que Resposta a Incidentes é desligar a máquina na parede (o famoso pull-the-plug) ?
- A memória vai assumir um status tão importante quanto o HD na Resposta a Incidentes. O CIRT vai estar preparado e com ferramentas para realizar não só os inúmeros comandos que capturam o estado da máquina, suas conexões e outros itens, mas também estará preparado para capturar a memória e analisá-la.
- Verdadeiras equipes de Resposta a Incidentes vão aprender que a rotina deles é muito parecida com a de uma turma de ER de hospital. Triagem será uma operação fundamental na fase de Contenção, na medida em que mais eventos (incidentes) grandes acontecem e atingem mais servidores em uma rede. Um excelente artigo do HogFly explica alguns detalhes sobre esse assunto, mas basicamente a equipe terá que seguir cada vez mais uma ordem de prioridades para determinar quem será "atendido" primeiro. Em um caso de ER, uma pessoa que chega possui as classificações de atendimento Morto, Imediato, Menor grau e Pode aguardar (ou postergar). Um servidor atacado e comprometido em um datacenter com vários outros vai entrar em uma fila de acordo com classificações parecidas. HogFly sugere que a ordem de atenção para conter o impacto de um incidente, e a consequente hemorragia de informações, seja:
4) Servidores que não podem ser bloqueados no perímetro;
3) Servidores/Sistemas que não podem ser colocados offline;
2) Servidores/Sistemas que podem ser bloqueados no perímetro;
1) Servidores/Sistemas que podem ser colocados em offline;
- As metodologias irão amadurecer, baseadas principalmente em procedimentos já bastante maduros em disciplinas correlatas. Uma extensão ao manual de resposta a incidentes que trate casos comuns de incidentes e respostas pré-estudadas, com detalhes nos procedimentos, será comum nas empresas. Os detalhamentos deverão documentar, por exemplo, como um tipo específico de incidente pode ser detectado.
- O CIRT vai finalmente ganhar independência para agir. Os que já precisaram de atuar em uma Resposta a Incidente sabe como é frustrante coordenar um grupo que não é coeso, geralmente composto por equipes distintas e com gestores que nem sempre cooperam. Hoje, o CIRT é obrigado a agir, mas ainda tem uma dependência enorme das áreas operacionais. Em geral, elas acabam por emperrar o processo. Mas isso também está para acabar. O CIRT não poderá ficar de braços cruzados, esperando que a turma operacional habilite alguma coisa, para que ele comece a atuar. Em resumo, enquanto isso acontece hoje, o impacto do incidente continua agindo e, em geral, piorando a situação. Hackers agradecem. Com a independência do CIRT, assim que o incidente for detectado e o CIRT acionado, ele ganha uma espécie de status semelhante a um Estado de Sítio ou de Calamidade Pública. O CIRT passa a ter a agilidade necessária para fazer parar o incidente, atuando efetivamente na contenção, ao invés de ficar com as mãos amarradas.
Você poderia comentar como funciona a sua estrutura de resposta a incidentes ? Você passa ou já percebeu alguma das situações escritas aqui ? Já foi acionado para conter um incidente e quando chegou lá já tinham formatado tudo ? Comente !!!
Até o próximo post !
Assinar:
Postagens (Atom)