Founder of MalwareIntelligence, a site dedicated to research on all matters relating to anti-malware security, criminology computing and information security in general, always from a perspective closely related to the field of intelligence.

viernes, 16 de marzo de 2007

SUCESOS DE SEGURIDAD

A veces, las cosas más sencillas acaban pareciendo las más complicadas. Una de ellas suele ser lo relativo a la gestión de sucesos de seguridad. Incidentes, eventos, incidencias, fallos... Un montón de términos que a veces se confunden, se entremezclan, y que a los encargados de tratar con ellos dan más quebraderos de cabeza de los que debieran. Y sin embargo, las cosas suelen ser más sencillas de lo que parecen...

Por un lado, tenemos las incidencias de seguridad. Entendidas, sencillamente, como que "ha pasado algo relacionado con la seguridad". Qué ha pasado? Tenemos tres opciones. La primera es que haya pasado "algo malo". Hemos tenido un problema, algo ha fallado. Técnicamente, una amenaza ha conseguido explotar una vulnerabilidad sobre un activo. Y qué hay que hacer? Simplemente, arreglarlo. A eso se le llama corrección.

Otra opción es que la incidencia haya quedado "en nada". Ha sucedido un evento, pero no ha llegado a ser incidente. Una amenaza que nos ha atacado pero finalmente no se ha materializado, una vulnerabilidad nueva que ha aparecido, pero que aún no ha sido explotada...

Lo que haya sucedido todavía no nos ha hecho ningún daño. Aunque si no hacemos nada, podría llegar a causarlo. Qué hay que hacer? Evitarlo antes de que suceda: corregir aquello que acabamos de descubrir que está mal, antes de que pase nada (acciones correctivas) o reforzar nuestras medidas de protección, por si acaso (acciones preventivas).

Todavía tenemos una tercera opción. Lo que ha pasado es que hemos descubierto que nuestros controles no funcionan bien. No es que haya pasado algo malo, sino que hemos encontrado un fallo en nuestro sistema de gestión. La incidencia, en este caso, se cataloga como no conformidad, y lo que tendremos que arreglar en este caso es el control en sí, mediante las acciones correctivas correspondientes.

Por último, existe otro tipo de entrada que puede dar lugar a este tipo de acciones. En este caso yo no lo catalogaría como incidencia, ya que no es que "haya pasado algo", sino que alguien realiza una aportación (sugerencia, comentario).

En este caso, la aportación (realizada por cualquier persona de la organización) puede ser una propuesta de mejora (lo que desencadenaría la correspondiente acción preventiva si así se considera) o puede "levantar alguna liebre", descubrir algún fallo que deba ser resuelto, mediante las correspondientes acciones correctivas.

Y no olvidemos que una corrección puede conllevar, en su tratamiento a posteriori, una acción correctiva para resolver la causa que ha provocado el incidente. Y que a su vez las acciones correctivas también pueden desencadenar acciones preventivas que ayuden a optimizar las protecciones existentes en relación al origen de los hipotéticos incidentes. En el fondo, todo está relacionado, no?

Fuente

Ver más

EL ENEMIGO INTERIOR
Tanto tiempo echando la culpa a malvados "hackers" de la revelación de datos confidenciales y ahora un estudio de la Universidad de Washington en Seattle revela que los intrusos sólo son responsables de menos de un tercio de esos episodios, mientras casi dos tercios son responsabilidad de las propias empresas.

Pérdidas de equipos, puesta on-line inadvertida de información confidencial, pérdidas de backups y otros errores de administración conforman el grueso de la responsabilidad empresarial en este campo...

Para Philip Howard, coautor del trabajo, cuando la empresa pierde un montón de datos de sus clientes, lo más fácil es echarle la culpa a un supuesto "hacker".

Otro estudio similar publicado la semana pasada por IT Policy Compliance Group proporcionaba resultados similares: 75% de responsabilidad atribuible a la empresa, 25% a intrusos externos.

Fuente
Mas información

Ver más