El 40% de los teléfonos inteligentes en venta tienen información de su anterior propietario

Actualmente, la información que almacenamos en nuestros teléfonos es muchísima, y también, privada. De acuerdo a un estudio realizado por NAID (National Association on the Destruction of Information of the United States), casi el 50% de los teléfonos analizados de segunda mano que encontraron en venta, contenían información personal del vendedor. 

El estudio tuvo un universo de 250 equipos, en el que 2 de 5 equipos revisados contenían información de su antiguo propietario, lo cual claramente facilita el accionar de los delincuentes quienes acceden a dicha información sin proponérselo. 

La información personal es muy fácil de borrar en los smartphones, aunque debe hacerse con minucia para evitar que alguna información que haya sido alojada en la nube pueda ser recuperada, como por ejemplo los passwords que llevamos sin cambiar por una eternidad. 

Para las organizaciones es obligatorio que los equipos móviles sean reseteados de manera tal que se restablezcan los equipos a su configuracion de fabrica, borrando así toda la información que haya podido ser almacenada en tales dispositivos. Los cybercriminales buscan tener en sus redes a cualquier persona que les pueda inadvertidamente generar beneficios o un redito economico. La recomendación es obvia: antes de vender y/o regalar un smartphone, hay que restablecer el equipo a su configuracion de fabrica. Puede sonar difícil de hacer pero es muy fácil, y en internet hay guías para hacerlo en cualquier marca y modelo. 

 FUENTE

NIST: Guia para manejo de Incidentes de Seguridad

La National Institute of Standards and Technology o mas conocida como NIST acaba de publicar  una revisión de su guia "Computer Security Incident Handling Guide" la cual incluye  los siguientes capítulos:

1. Introducción
2. Construcción del equipo de atencion de incidentes de seguridad: Definición de política de gestión de incidentes,  plan y procedimientos de respuesta a incidentes.
3. Gestión de incidentes: Preparación, detección, Contención, erradicación y recuperación, actividades post-incidente, check list de manejo de incidentes.
4. Distribución de registros de incidentes de seguridad.

Como es ya habitual en el material elaborado por NIST, es muy completo y util para aplicarlo en cualquier organización.

La guiá (únicamente en ingles) la pueden encontrar en este LINK

Publicada la ISO 27035:2011 Gestion de Incidentes de Seguridad

Desde piratas informáticos tratando de irrumpir en las redes de seguridad, a personal interno usando sus conocimientos y derechos internos de acceso al uso de datos de la empresa para su beneficio personal, el impacto de una amplia variedad de amenazas de seguridad de la información puede ser reducida usando la nueva Norma Internacional ISO / IEC 27035:2011 de gestión de incidentes de seguridad de la información.

 

La violación de la seguridad de la información puede poner en peligro sus sistemas de negocio y causar perturbaciones en las operaciones comerciales. El estar preparados y responder de una manera eficaz y oportuna puede significar la diferencia entre un incidente menor y un desastre en el negocio. El uso de un sistema de gestión de incidentes de seguridad de la información permite a las organizaciones los controles y procedimientos para gestionar una amplia variedad de incidentes de seguridad y vulnerabilidades. 

ISO / IEC 27035:2011, Tecnología de la información - Técnicas de seguridad – Gestión de Incidentes de Seguridad de la Información, es una orientación sobre  "cómo hacer" para la detección, notificación y evaluación de incidentes de seguridad de la información y las vulnerabilidades. La norma ayudará a las organizaciones a responder ante incidentes de seguridad informática, incluyendo la activación de los controles adecuados para la prevención y la reducción de, y la recuperación de los impactos, y, al hacerlo, aprender y mejorar su enfoque global.

La integración del sistema de gestión de incidentes de seguridad de la información ofrece varias ventajas:

• Mejorar la seguridad de la información general
• Reducir los impactos adversos en los negocios
• Reforzar el enfoque de prevención, establecimiento de prioridades y la evidencia de incidentes de seguridad de la información.
• Contribuir a las justificaciones presupuestarias y de recursos
• Mejorar cambios en la evaluación de riesgos de seguridad de información y los resultados de la gestión
• Proporcionar una mayor conciencia en seguridad de la información y en el material del programa de formación
• Proporcionar información en su política de seguridad de la información y comentarios relacionados con la documentación.

Edward Humphreys, cuyo equipo desarrolló la versión original de la norma, ISO / IEC TR 18044:2004, comentó: "el manejo eficaz y oportuno de los incidentes importantes puede marcar la diferencia entre la supervivencia o la" muerte "de una organización. La nueva norma ISO / IEC 27035 proporciona consejos de probada eficacia en los procesos y métodos que deben implementarse para garantizar una gestión eficaz de los incidentes de seguridad de la información.

"Los incidentes pueden variar de los menores, que pueden tener un impacto en el negocio de manera aislada, a un incidente grave, que afecta a todos los sistemas empresariales. Algunos de los incidentes tienen el efecto de perturbar a la organización y al uso de los recursos de su negocio de 24 a 72 horas o más, por una gran pérdida y / o destrucción de datos y otros pueden ser delitos graves. ISO / IEC 27035:2011 ofrece una solución. "

ISO / IEC 27035:2011, que sustituye al informe técnico ISO / IEC TR 18044:2004, es compatible con los conceptos generales especificados en la norma ISO / IEC 27001:2005, Tecnología de la información - Técnicas de seguridad - Sistemas de gestión de seguridad - 

Requisitos.

La nueva norma es aplicable a cualquier organización, independientemente de su tamaño. Cubre una amplia gama de incidentes de seguridad de la información, ya sean deliberados o accidentales, y ya sea causada por medios técnicos o físicos.

ISO / IEC 27035:2011, Tecnología de la información - Técnicas de seguridad – Gestión de Riesgos de Seguridad de la Información, fue desarrollada por el Comité Técnico Conjunto ISO / IEC JTC 1, Tecnología de la Información, subcomité SC 27, Técnicas de seguridad de TI. La norma está disponible en los institutos nacionales miembros de ISO. También se puede obtener a través de la web de ISO.

*Fuente iso.org

ISO 27001 e ISO 27002: Dominio 13 Gestión de los incidentes de la seguridad de la información

Continuando con los Dominios de la ISO 27002 (Numeral 13) o Anexo A de la ISO 27001 (Anexo A13), hoy vamos a revisar la Gestión de los incidentes de la seguridad de la información. Que dicen la ISO 27001 e ISO 27002? Bien, incluyen dos objetivos de control:

13.1 reporte sobre los eventos y las debilidades de la seguridad de la información

Objetivo: asegurar que los eventos y las debilidades de la seguridad de la información asociados con los sistemas de información se comunican de forma tal que permiten tomar las acciones correctivas oportunamente.

Es conveniente establecer el reporte formal del evento y los procedimientos de escalada.

Todos los empleados, contratistas y usuarios de tercera parte deberían tener conciencia sobre los procedimientos para el reporte de los diferentes tipos de evento y las debilidades que puedan tener Impacto en la seguridad de los activos de la organización. Se les debería exigir que reporten todos los eventos de seguridad de la información y las debilidades tan pronto sea posible al punto de contacto designado.

13.2 Gestión De Los Incidentes Y Las Mejoras En La Seguridad De La Información

Objetivo: asegurar que se aplica un enfoque consistente y eficaz para la gestión de los incidentes de seguridad de la información.

Es conveniente establecer las responsabilidades y los procedimientos para manejar los eventos y debilidades de la seguridad de la información de manera eficaz una vez se han reportado. Se debería aplicar un proceso de mejora continua a la respuesta para monitorear, evaluar y gestionar en su totalidad los incidentes de seguridad de la información.

Cuando se requiere evidencia, ésta se debería recolectar para garantizar el cumplimiento de los requisitos legales.

Interpretando los requisitos de la norma, podemos encontrar lo siguiente:

La gestión de los incidentes de seguridad se ha convertido en un componente importante dentro de los programas de tecnología de información y seguridad de la información.

Las acciones preventivas y correctivas que se generan una vez se realizan análisis de riesgos y auditorias del SGSI pueden disminuir el número de incidentes que sean susceptibles de presentarse, pero no todos pueden ser prevenidos.

Deben definirse lineamientos para la gestión de varios tipos de incidentes específicos:

• Negación de Servicio (DoS – Denial of service):

Los ataques de denegación de servicio se refieren al uso específico de ciertas herramientas por parte de intrusos con el fin de causar que las redes y/o sistemas dejen de operar apropiadamente.

Los ataques de denegación de servicio distribuido son aquellos realizados por un grupo de atacantes localizados en diferentes sitios geográficos en donde simultáneos ataques son lanzados hacia el sistema víctima. Debido a ello, es difícil localizar las fuentes del ataque.

• Ataques de Código malicioso:

Código malicioso pueden ser programas como virus, gusanos, troyanos, spyware o scripts utilizados por intrusos para lograr acceso privilegiado, capturar contraseñas o información confidencial. Los ataques de código malicioso son a veces difíciles de detectar debido a que ciertos virus o gusanos son diseñados para modificar su propia firma después de lograr infiltrar un sistema, algunos incluso son capaces de ocultar logs de auditoría para ocultar las actividades no autorizadas.

• Acceso no autorizado:

El acceso no autorizado va desde el uso no autorizado de credenciales hasta la modificación o cambio de archivos y directorios almacenados en un sistema o medio de almacenamiento. Esto adicionalmente puede lograr acceso a otros sistemas a través de programas o dispositivos de “sniffing” que pueden ser instalados para capturar información confidencial que este moviéndose por la red.

• Usos no apropiados:

Ocurren cuando un usuario lleva a cabo acciones que violan las políticas de uso aceptable de los recursos computacionales.

Estos lineamientos deben incluir la definición de procedimientos para la preparación frente a incidentes, identificación, análisis, contención, eliminación y recuperación de incidentes.

Ya teniendo como base una identificación de posibles incidentes que se puedan presentar en la Organización, como seria entonces la gestión de incidentes de seguridad de la información? Veamos:

Un incidente de seguridad de la información se debe entender como un evento relevante que atenta contra la seguridad de los sistemas de cómputo, redes de computadores u otro recurso informático o no informático de la organización; generalmente interrumpe su procedimiento de operación normal.

Los tipos de incidentes de seguridad de la información pueden estar relacionados con cualquier tipo de evento que pueda considerarse que atenta contra la seguridad de los componentes de la infraestructura de tecnología informática y telecomunicaciones u otros activos de la Organización.

1. Detección y reporte de incidentes

Deben existir mecanismos que permitan la detección y el registro de eventos informáticos de forma que sea posible realizar el análisis de los mismos por medio de una evidencia de su ocurrencia.

Los incidentes pueden ser detectados y registrados a través de los siguientes medios:

a) Equipos IDSs, IPSs de red e IDSs basados en Host (HIDS).

b) Alertas generadas por medio de software antivirus, antispyware o antyspam.

c) Software de verificación de integridad de archivos.

d) Servicios externos de monitoreo contratados por la Organización.

e) Logs de sistemas operativos, servicios de red y aplicaciones como sitios Web, entre otras.

f) Logs de los dispositivos de red (router, switch, access point, etc).

g) Información de vulnerabilidades conocidas sobre diferentes tecnologías.

h) Información de incidentes ocurridos en otras Organizaciones.

i) Personas dentro de la organización (usuarios de los servicios informáticos, administradores de red, administradores de sistemas de información, etc.) que hacen uso del servicio de soporte de sistemas y/o tecnologia.

j) Personas de otras organizaciones que detectan vulnerabilidades en diferentes servicios y notifican a la Organización.

Todos los incidentes de seguridad deben ser reportados en el menor tiempo posible, para acelerar la detección, restauración y reparación de cualquier daño causado, y para facilitar la obtención de cualquier evidencia asociada.

Todos los funcionarios involucrados con la Organización, deben ser conscientes y estar alertas a que la evidencia relacionada con incidentes de seguridad de la información debe ser adecuada y formalmente registrada, retenida y entregada al Administrador de Seguridad de la información, utilizando los medios que estén disponibles para tal fin.

2. Preparación ante Incidentes

Según la complejidad de los incidentes se deben asignar prioridades de atención a éstos. Estas prioridades están clasificadas de la siguiente manera:

a) Incidentes Críticos:

• Estos incidentes pueden afectar la integridad o la confidencialidad de la información, lo cual tiene como resultado la pérdida directa del negocio y/o la reputación.
• El problema y/o incidente requiere solución inmediata, ya que este causa la completa pérdida de un servicio o la interrupción de las actividades laborales.
• Se genera un impacto crítico en el cliente.
• Se genera un impacto crítico en aplicaciones o procesos de negocio
• Afecta una comunidad de usuarios o a un usuario de servicios informáticos de alto rango.

b) Incidentes Severos:

• Estos incidentes afectan típicamente la disponibilidad de la información, pero no la integridad de la misma.
• El servicio informático, sistema de información o aplicación opera con problemas críticos.
• El servicio informático, sistema de información o aplicación no está operativo, pero no requiere solución inmediata.
• El impacto del negocio no es crítico.

c) Incidentes Normales:

• Estos incidentes pueden afectar la confidencialidad, integridad o disponibilidad de la información, sin embargo no existe pérdida alguna.
• El servicio informático, sistema de información o aplicación opera con funcionalidades limitadas.
• El servicio informático, sistema de información o aplicación no está operativo, pero existen alternativas paralelas y están disponibles.
• No se ven afectados servicios informáticos importantes para el negocio.

d) Incidentes Menores (no afectan la seguridad de la información ni de telecomunicaciones):

Se acuerda y programa con el usuario de servicios informáticos la atención, para una fecha determinada. En este tipo se incluyen:

• Actualizaciones de hardware y software.
• Nuevas instalaciones de PC, hardware y software.
• Movimientos de oficinas o reasignación de máquinas.
• Reporte y registro de fallas de software.

Con base en los requerimientos contractuales y para darle peso y solución inmediata a los incidentes reportados, se debe dar respuesta en máximo una hora al usuario sobre el tema o inconveniente reportado, con la fecha estimada inicial que se de de acuerdo a la valoración que se realice.

Se deben preparar, mantener y probar regularmente planes para asegurar que el daño producido por posibles ataques externos puede ser minimizado y que la restauración tendrá lugar lo más pronto posible.

3. Análisis de Incidentes

Los incidentes de seguridad deberán ser apropiadamente investigados por personal adecuadamente entrenado y calificado. Ningún incidente se dará por resuelto sin que sea cerrado por el responsable de su manejo, dependiendo de la categoría del incidente.

En caso de que el incidente se relacione con un sistema tecnológico específico, nunca se debe apagar o reiniciar el sistema comprometido de manera inmediata, ya que esto puede llevar a la pérdida de información o evidencia necesaria para una investigación forense posterior.

4. Contención

Se debe limitar la posibilidad de que el daño causado por el incidente se extienda. Para ello se debe evaluar si se aíslan los componentes comprometidos del resto de componentes de la red, teniendo en cuenta que esto puede afectar o interrumpir la operación normal en caso de que el sistema comprometido sea crítico o muchos sistemas sean afectados por el problema como sucede en una epidemia de virus.

En caso de que la atención de cualquier incidente implique riesgo para la seguridad de las personas involucradas en su atención, se deberá informar a la gerencia de la Organización, y no se realizará intervención hasta que no se realice el aseguramiento de las condiciones del sitio a intervenir.

5. Eliminación

Después de lograr la contención, se debe iniciar una etapa de investigación que permita establecer la causa del incidente. Si son incidentes relacionados con tecnología, es necesario realizar un análisis detallado de los logs, en diferentes dispositivos (firewalls, routers, logs de sistema/aplicaciones). Para ello se deben utilizar herramientas diferentes a aquellas existentes en el sistema comprometido.

Después de la investigación, el sistema afectado debe ser reinstalado.

6. Recuperación

• Se debe validar la ejecución de las tareas de eliminación.
• Se debe restaurar el componente afectado desde un backup limpio.
• Se debe monitorear el componente para determinar si su funcionamiento es normal, previo a la puesta en producción.
• Se debe implementar un monitoreo a nivel de red para detectar intentos posteriores de ataque.

7. Seguimiento

Se debe crear una base de datos de incidentes en la cual se consignen los reportes de incidentes y la solución dada a los mismos, que sirva en un futuro como primera alternativa de consulta en la resolución de incidentes informáticos.

La información de registro de administración de incidentes debe contener aspectos como: descripción de la secuencia exacta de eventos, forma de descubrimiento del incidente, acción preventiva utilizada, análisis que determine que los pasos de recuperación son suficientes y recomendaciones adicionales que deban ser consideradas.

La base de datos de incidentes que se generen al interior de la Organización será revisada con intervalos no mayores a un año para verificar que los mismos no se repitan o si se han modificado las circunstancias, desarrollar una nueva medida de control que minimice la posibilidad e impacto de este incidente en caso de que se diera la posibilidad de volver a presentarse.

8. Evidencias de Incidentes

Todo incidente de seguridad que se reporte debe venir acompañado de algún tipo de evidencia que respalde el reporte que se realice. Estas evidencias resultan fundamentales en situaciones como la aplicación del proceso disciplinario desarrollado para el SGSI

Cuando una acción de seguimiento contra una persona u organización después de un incidente de seguridad de la información implica acciones legales (civiles o penales), la evidencia se debe recolectar, retener y presentar para cumplir con las reglas para la evidencia establecidas en la jurisdicción pertinente.

Como se puede apreciar, la gestión de incidentes es un insumo de increíble valor para el SGSI, pues contribuye a robustecer cualquier areá que se vea afectada con un incidente, de alli la importancia de que este Dominio este aplicado en la Organización con una estructura muy fuerte de trabajo, respuesta y gestión de incidentes.