OWISAM: Open WIreless Security Assessment Methodology

OWISAM es una metodología abierta para el análisis de seguridad Wireless. Sus fundadores, los hermanos Tarascó, la presentaron en la pasada RootedCon, para que todo aquel que estuviera interesado colaborase editando sus páginas y contribuyendo con ideas.

A día de hoy, aun me pregunto cómo es posible que no existiese antes una metodología similar, con lo comunes que son las auditorias de redes inalámbricas. Si bien es cierto que OSSTMM incluye en el capítulo 9 vagas referencias, muy lejos queda, de lo que ya es hoy por hoy este proyecto.

Es en concepto y forma similar  a OWASP, donde se habla de controles técnicos a bajo nivel, herramientas y procedimientos para el análisis. Entre sus páginas ya hay algunas entradas creadas, como por ejemplo los riesgos Top 10:

Pero queda mucho trabajo por hacer, páginas que editar, procesos que documentar, textos que traducir e ideas que debatir. Hace falta que la comunidad una sus fuerza y se ponga las pilas, al igual que ocurrió en su momento con OWASP.

En España y en Latinoamérica en general hay mucho talento en este campo, hay claros ejemplos como seguridadwireless y su wifislax, donde todos los temas que trata OWISAM seguramente se han tratado alguna vez. ¿Por qué no darle orden y forma?  Todo el mundo se beneficia, los auditores podrán saber qué y cómo mirar en una auditoría y aquellos que quieran ser auditados, sabrán que controles se han estudiado.

Para colaborar, la mejor forma es empezar por subscribirse en su lista de correo y ver en que se puede aportar, para ello, tan solo hace falta mandandar un mensaje a la dirección: owisam_es-subscribe@owisam.org

Fuente: Security by Default

Contenido completo en www.segu-info.com.ar

Guías de seguridad para Android, iPhone e iPad

Nos hacemos eco a través del Twitter de Luis Delgado, de la publicación por parte del CNN-STIC, enmarcado en el ámbito de “Guías de seguridad en las TIC” (tecnologías de la información y comunicación), de la publicación en formato PDF de 4 guías para promover el Uso Seguro en Dispositivos Móviles y guías para Android, iPhone e iPad (enlaces a las descargas).

Las 3 guías son muy completas y algún caso llegan a las 200 páginas. En ellas, intentan abarcar muchos de los problemas de seguridad más comunes en este tipo de dispositivos y cómo paliarlos. No está de más recordar que muchos atacantes ya buscan estos vectores de entrada, debido al alto uso de los mismos y un cierto desconocimiento general.

Fuente: DaboWeb

Contenido completo en www.segu-info.com.ar

Desarrollando para Nmap Scripting Engine (NSE)

Hace 5 años Nmap dió luz a su propio motor de scripts que facilita a administradores de sistema y pentesters ha realizar una variedad impresionante de tareas como recolección de información, detección de servicios y hasta explotación de vulnerabilidades.

Su flexibilidad y poder lo han convertido en una herramienta indispensable, no solo para escaneo de puertos, sino durante todas las etapas de una prueba de penetración.
En este taller de Paulino Calderón (calderpwn) los asistentes se familiarizarán con el motor de scripts de Nmap, aprenderán casos de uso avanzado y crearán sus propios scripts. Los participantes desarrollarán módulos para diversos fines incluyendo escaneo, análisis de tráfico y explotación web y de otros dispositivos.

Fuente: GuadalajaraCon

Contenido completo en www.segu-info.com.ar

Asegurar tu red WiFi para que no te graben con tu webcam

Esta semana, con la noticia del pedófilo que espiaba a sus vecinos por la webcam se ha creado mucho ruido mediático en televisiones, radios y medios de comunicación. La noticia ha sido que se colaba en las redes WiFi de su vecino, tomaba el control del equipo de la víctima y les infectaba con un troyano para activar la webcam y grabarles en su casa, lo que a muchos les parecía de ciencia ficción. Esto es porque no están al día y no conocen casos como el del técnico de Mac que espiaba a sus clientes por la webcam, que los ladrones de tecnología caen en estas grabaciones y no saben que hasta a los espías les cazan de esta forma, así que quería escribir un poco sobre esto.

Defenderse contra la grabación en WebCam

Respecto al tema del software R.A.T. (Remote Administration Tool) que te graba con la webcam, ya es muy conocido, y las recomendaciones son cuidar de tu sistema operativo. En uno de los libros que más se han vendido de nuestra colección, Sergio de los Santos (@ssantosv) se pasa más de 250 páginas hablando de cómo obtener la Máxima Seguridad en Windows sin necesidad de utilizar un antimalware – el cual es archirecomendable para saber más de seguridad -, pero para resumir todo en una pequeña lista yo os propondría.

Contenido completo en fuente original Un Informático del Lado del Mal

Contenido completo en www.segu-info.com.ar

Guía para clientes que contraten servicios de Cloud Computing

Podemos decir que se están utilizando servicios de cloud computing cuando encontramos empresas, entidades, departamentos, etc., a los que llamaremos usuarios o clientes, que para implementar sus procesos de tratamiento de información comparten los mismos recursos a través de la red; recursos proporcionados por una entidad distinta, llamada proveedor de servicios de cloud computing o proveedor de la nube.

Aparte de clientes y proveedores, existen otros actores en el mundo del cloud computing. Entre ellos destacan los socios o partners de los proveedores de cloud. Estos crean, ofrecen y soportan servicios adicionales en la nubeque venden al usuario final como licencias de uso, por ejemplo, creando una aplicación de marketing que se ejecuta en la nube a partir de servicios más básicos de la misma. Los partnersse sitúan entre el cliente y el proveedor de la nube, pudiendo formalizar su relación con este
último con distintas figuras contractuales (reseller, vendedor independiente, etc).

La contratación de servicios de cloud computing se realizará a través de un contrato de prestación de servicios. Resulta imprescindible que ese contrato incorpore entre sus cláusulas las garantías a las que obliga la Ley Orgánica de Protección de Datos.

Atendiendo a la relación contractual establecida entre el cliente y el proveedor de la nube, también este contrato se puede clasificar como negociado o de adhesión. Podemos decir que un contrato entre el cliente y el proveedor es negociado si el primero tiene, o se le ofrece, la capacidad para fijar las condiciones de contratación en función del tipo de datos que se van a procesar, las medidas de seguridad exigibles, el esquema de subcontratación, la localización de los datos, la portabilidad de los mismos y cualquier otro aspecto de adecuación a la regulación española y a las restricciones que esta regulación implica.

La Agencia Nacional de Protección de Datos Personales de España ha publicado esta Guía de Cloud Computing para quienes contratan un servicio [PDF] y Orientaciones para prestadores de servicios de Cloud Computing [PDF] para conocer cuales son las necesidades a tener en cuenta la contratación de servicios de cloud computing y ofrece información práctica dirigida a PyMEs y profesionales.

Fuente: Agencia Nacional de Protección de Datos Personales de España

Contenido completo en www.segu-info.com.ar

SQL Injection "a mano"

Seguramente cualquiera que esté leyendo este post ya abrá leído esto, esto y esto pero ninguna de esas guías dan un ejemplo definitivo sobre cómo encontrar, enumerar y explotar los diferentes inyección a mano.

Básicamente este tipo de pruebas permite explicar cómo ejecutar manualmente una inyección SQL y mostrar ejemplos de los diferentes tipos de inyecciones y la forma de enumerar y obtener las diferentes piezas de información crítica en un ataque SQLi.

Así que aquí dejo algunas referencias rápidas:

• Ejemplos de SQLi por OWASP
• OWASP Cheat Sheet para prevenir SQLi 
• Documento y Cheat Sheet de Veracode
• Paso a paso del proceso, por Imperva
• SQL Injection Cheat Sheet, para evasión de filtros
• Trucos en MySQL, MSSQL, ORACLE y otras bases de datos
• An Introduction to SQL Injection Attacks for Oracle Developers

Cristian de la Redacción de Segu-Info

Contenido completo en www.segu-info.com.ar

12 Consejos de Seguridad para tu Mac

Aunque se dice que el sistema operativo de Mac es generalmente muy seguro, hay cosas que se pueden hacer para asegurarse de que se tiene un sistema totalmente bloqueado. Estos trucos y consejos de Mac Tricks and Tips sirven para asegurarse de que no se deja ninguna puerta trasera abierta inadvertidamente. No es necesario aplicarlos a todos, pero sin embargo cuanto más se aplican más se protege el sistema.

1. Habilitar el Firewall

Aunque puede haber mejores firewalls el de Mac es suficiente para la mayoría de las necesidades de los usuarios. Activar el firewasll es una de las cosas más básicas que se pueden hacer para protegerse. Puede activarlo desde las Preferencias del Sistema.

2. Cifrar la información con FileVault

FileVault es un sistema de cifrado incorporado en Mac desde su versión 10.3. Esta aplicación cifra los datos on the fly, lo que significa que todos los datos que se almacenan en una unidad son inaccesibles si la unidad se retira o se lee desde otro equipo. Esto es muy útil si el Mac o su disco son robado.

Tener en cuenta que FileVault puede ralentizar casi imperceptiblemente equipo y que si se olvida la contraseña, no se podrán descifrar los datos.

3. Mantener actualizado el software

La App Sore informa automáticamente cuando hay actualizaciones y cuándo deben aplicarse. Esto es especialmente importante en lo que respecta a las actualizaciones de seguridad y actualizaciones de Java. Cada actualización de software corrige errores y agujeros en el sistema para asegurarlo

4. Permitir aplicaciones sólo de fuentes de confianza

El último sistema operativo de Apple incluye una aplicación de llamada GateKeeper que asegura que las aplicaciones se han firmado y que provienen de fuentes de confianza. Esto significa que las aplicaciones no pueden provenir de desarrolladores no identificados y por lo tanto no se ejecutan en el Mac. Todas las aplicaciones de la App Store se firman para garantizar que son seguros y la mayoría de las aplicaciones de terceras partes, que no se venden en la tienda de aplicaciones, están firmadas por los desarrolladores de confianza. Habilite al menos la segunda opción para garantizar que aplicaciones que se ejecutan son de confianza.

Si usted es demasiado estricto puede activar la primera opción.

5. Deshabilitar Java

Java está lleno de agujeros de seguridad y en general es un dolor de cabeza y no permite garantizar que no se ponga en peligro el sistema. Si usted no utiliza Java, apáguelo. Para desactivarlo, abra las preferencias del navegador web que utilice desmarque la pestaña “Enable Java”, por ejemplo en Safari.

Adicionalmente se puede tratar de usar páginas web con Java lo menos posible.

6. Hacer copias de respaldo de los datos

Una característica simple, pero útil, es siempre tener una copia de seguridad de sus datos. Esta es una característica de seguridad para asegurar de que siempre se tendrán los datos cuando se los necesite.
Time Machine es un software de backup desarrollado por Apple para hacer copias de seguridad. Viene incluido con el sistema operativo Mac OS X y fue introducido con el lanzamiento de la versión 10.5. Aquí se puede ver un tutorial de uso.

7. No utilizar la cuenta de Administrador

Una cuenta de administrador (root) tiene muchos privilegios y por eso en su lugar se debe crear una cuenta de usuario normal con menos “poderes”. Usted todavía será capaz de hacer todas las cosas que quiera en su Mac y tendrá una capa adicional de seguridad para detener cualquier tipo de ataque de aplicaciones dañina. Adicionalmente evitará poner en riesgo su equipo ante un error involuntario.

Para crear una nueva cuenta, abra Preferencias del Sistema y seleccione “Grupos y usuarios” desde el panel. En la parte inferior añada una nueva cuenta “estándar” y rellene los datos solicitados.

8. Desactivar inicio de sesión automático

Si tienes un MacBook se debe desactivar el acceso automático para evitar que cualquiera pueda iniciar su Mac y tener acceso a sus archivos.

Dentro de las opciones de inicio de sesión de los usuarios y en el panel de preferencias de grupos, apague el inicio de sesión automático. Esto asegura que se tiene que escribir una contraseña para acceder a su cuenta de usuario.

9. Requerir una contraseña en el Screen Saver

Al igual que con el consejo anterior, se debe establecer una contraseña para desbloquear el sistema o para salir del protector de pantalla. Esto significa que cualquier persona que acceda al Mac, necesitará la contraseña para acceder a sus archivos.

Esta configuración de seguridad está habilitada en el panel Seguridad y privacidad dentro de Preferencias del Sistema y se debe activar la casilla de verificación para requerir una contraseña al desactivar el protector de pantalla.

10. Cierre de sesión automático

Otro consejo de seguridad en la línea con los anteriores. El cierre de sesión automático significa que si se deja la Mac desatendida durante demasiado tiempo, la sesión se cerrará y que se requerirá una contraseña para acceder.

11. Deshabilitar los servicios de localización

Los servicios de localización permiten a ciertas aplicaciones localizar el Mac en base a la información de un GPS que este tiene. Si no se desea que la gente sepa dónde está usted, puede desactivar esta función desde  el panel de Seguridad y Privacidad en las Preferencias del Sistema.

Este consejo también aplica para otros dispositivos como el iPhone y el iPad.

12. Vaciar la papelera de forma segura

Cuando se elimina cualquier archivo, sólo se marca un puntero para que el archivo deje de estar “accesible” normalmente. Esto significa que los bits y los bytes que componen el archivo todavía están presentes en el disco y algunas aplicaciones pueden leer estos datos y reconstruir el archivo.

Se puede tener una seguridad adicional cuando se borra desde Finder, utilizando la opción “Secure Empty Trash” desde la barra de menús. Esto sobrescribe los archivos con datos en blanco para que los datos originales no se pueden recuperar.

Conclusión

Muy muchos métodos para asegurar un sistema y quizas no se puedan cumplir con todos ellos pero,al seguir algunos de ellos. marcará una diferencia importante.

Cristian de la Redacción de Segu-Info

Contenido completo en www.segu-info.com.ar

Recomendaciones contra ataques DDoS como el de Spamhaus

Hace unos días publicamos una nota sobre un ataque cibernético contra SpamHaus, una organización sin ánimo de lucro dedicada a combatir el spam en internet. Esta organización incluyó en sus listas a un proveedor de alojamiento de internet holandés llamado CyberBunker, conocido por no discriminar a los clientes y temas que aloja, con excepción de pornografía infantil o material terrorista.

Poco después de hacerse pública la noticia, los servidores DNS de Spamhaus recibieron un potente ataque de Denegación de Servicio (DDoS) el cual, consiguió tumbar sus servicios, al tiempo que logró que internet perdiera velocidad en distintas partes del mundo.

De acuerdo con un análisis de la firma de seguridad Corero Network Security, la técnica (conocida como amplificación DNS y similar al ataque llamado smurf) aprovecha la potencia de un puñado de ordenadores robots para generar una cantidad enorme de tráfico, utilizando la amplificación de servidores DNS abiertos e inundando el sistema atacado.

Así, los atacantes utilizaron una red de bots, con unos 1,000 equipos infectados que fueron controlados remotamente por los atacantes. Cada uno de ellos, simulando ser Spamhaus (Spoofing), envió peticiones de información a servidores en internet llamados open resolvers o DNS abiertos a recibir peticiones recursivas, es decir, peticiones provenientes de IP’s desconocidas en Internet. En este caso, se utilizaron aproximadamente 100,000 DNS abiertos para amplificar el ataque.
Los resolvers crearon respuestas más largas (dirigidas a Spamhaus), consiguiendo el efecto de amplificación y multiplicación, por lo que Spamhaus se vio inundado de respuestas DNS y no pudo atender a las peticiones de clientes legítimos. Tras unos días de interrupción de servicio, Spamhaus reaccionó contratando los servicios de una compañía de protección en la nube.

Esto permitió a Spamhaus salvarse temporalmente, gracias a la posibilidad de absorber más tráfico, pero entonces, los atacantes se focalizaron en atacar a los nodos de comunicaciones utilizados por la compañía de protección en Europa y en Asia, afectando a los clientes de esta compañía, pero también al resto de usuarios que transitaban por estos nodos. El ataque paro el día 26 y volvió a empezar el día 28 de marzo, causando una congestión aislada en Europa.

Recomendaciones para mitigar los efectos de DDoS

A continuación, Corero expone un par de mejores prácticas para reducir el riesgo frente a este tipo de ataques en las empresas.

• La defensa contra DDoS y tráfico no deseado en el centro de datos es imprescindible. Las conexiones a Internet, incluyendo servicios de tipo “Clean Pipe” proporcionadas por ISPs, dan una falsa sensación de seguridad. Las soluciones de protección deben ser instaladas inmediatamente frente a las aplicaciones y los servidores de bases de datos, para lograr una respuesta granular a los ataques por inundaciones, así como, para detectar y desviar los cada vez más frecuentes ataques DDoS contra la capa de aplicación.
• Proteger el DNS. El DNS es un sistema de nombres distribuido que permite el acceso a Internet mediante el uso de denominaciones reconocibles y fáciles de recordar, en lugar de direcciones IP numéricas, en las cuales la infraestructura de red enruta los mensajes de un ordenador a otro. Desde que DNS es distribuido, muchas organizaciones utilizan y mantienen sus propios servidores DNS para que sus sistemas sean visibles en Internet. Sin embargo, estos servidores son a menudo blanco de ataques DDoS, y si el atacante consigue alterar las operaciones del DNS, todos los servicios de las víctimas pueden desaparecer de Internet, causando el deseado efecto de Denegación de Servicio. Es imprescindible disponer de mecanismos de protección bi-direccionales permitiendo realizar un tracking de las peticiones y respuestas, tanto a aplicaciones Web, como a DNS.

Fuente: Search Data Center

Contenido completo en www.segu-info.com.ar

Guía de seguridad SCADA

Durante un tiempo CSO ha cubierto numerosos casos de sistemas SCADA que han sido atacados o a los cuales se le han encontrado vulnerabilidades:

• Sistemas SCADA en Australia son blanco fácil para ataques de malware
• Importantes sistemas SCADA establecen conexiones con claves débiles
• Casi dos docenas de bugs encuentrados en software de infraestructura crítica
• DHS investiga vulnerabilidades en Siemens Ruggedcom
• EE.UU. busca construir una unidad internacional para la ciberdefensa de sistemas de control industrial

No se espera que ninguno de estos ataques a SCADA e ICS se puedan frenar a corto plazo. En la charla, Who’s Really Attacking Your ICS Devices? [PDF], presentada recientemente en BlackHat Europa, el investigador Kyle Wilhoit explicó cómo se había construido un Honeypot SCADA/ICS. Una vez desplegado, la honeypot fue atacada dentro de las primera 18 horas de estar conectado a Internet. Durante casi un mes la honeypot registró 39 ataques provenientes de 14 países. El 35% de los ataques provino de China.

“En este momento lo mejor que tienen para proteger estos sistemas industriales son las listas de control de acceso en el perímetro. Desde la perspectiva de la seguridad de TI, los sistemas ICS/SCADA están en 1995″, dice James Arlen, experto de seguridad de Leviathan Security Group.

“A pesar de ser vulnerable, se están tomando medidas para aislar y proteger estos sistemas, y en realidad se piensa que pueden ser más resistentes a los ataques debido a que la industria desarrolla una mezcolanza de equipos y tecnologías dispares. Además, un ataque puede interrumpir una plataforma individual pero es dificil producir una catástrofe generalizada”, dice Patrick C. Miller, presidente y CEO de Energy Sector Security Consortium.

Si bien hay algo de consuelo en esa opinión, si una planta eléctrica se cae, ¿quién consolaría a las víctimas?

Aquí hay resumen sobre cómo reducir las probabilidades de que esto ocurra:

• Cambios radicales necesarios para aumentar la seguridad de infraestructuras críticas
• El futuro de la seguridad en sistemas SCADA
• Las empresas se preparan para ataques cibernéticos en secreto
• Los vendedores se unen para proteger los sistemas de infraestructura crítica
• Expertos hablan sobre ataques a gasoductos

Cristian de la Redacción de Segu-Info

Contenido completo en www.segu-info.com.ar

Plan para la Recuperación de Desastres de TI

Los planes de recuperación de desastres (RD) en tecnologías de la información (TI) proporcionan un enfoque estructurado para responder a los incidentes no previstos que ponen en peligro la infraestructura de TI, compuesta por hardware, software, redes, procesos y personas. Proteger las inversiones realizadas por su firma en la infraestructura tecnológica y garantizar la capacidad empresarial para ejecutar sus operaciones corporativas son las principales razones para poner en marcha un plan de recuperación de desastres en TI.

En esta guía conoceremos todo lo necesario acerca de la elaboración del plan. Aprenderemos a desarrollar paso por paso el plan de RD de TI y los aspectos más importantes a tener en cuenta durante su elaboración.

¿Qué es un plan de recuperación de desastres TI?

Los planes de recuperación de desastres TI proporcionan unos procedimientos detallados a seguir, paso a paso, para recuperar los sistemas y redes que han sufrido disrupciones y ayudar a resumir la normalidad en las operaciones. El objetivo de estos procesos es minimizar cualquier impacto negativo en las operaciones de la compañía. El proceso de recuperación de desastres identifica los sistemas y redes críticos de TI; fija las prioridades para su recuperación y dibuja los pasos necesarios para reiniciar, reconfigurar y recuperar dichos sistemas y redes. Todo plan integral de recuperación de desastres debería incluir también a todos los proveedores relevantes, las fuentes de experiencia para recuperar los sistemas afectados y una secuencia lógica de los pasos a seguir hasta alcanzar una recuperación óptima.

Asumiendo que hemos completado una evaluación de riesgos e identificado amenazas potenciales a nuestra infraestructura de TI, el siguiente paso será determinar qué elementos de dicha infraestructura son los más importantes para las operaciones corporativas. Además, asumiendo que todos los sistemas y redes TI funcionan con normalidad, nuestra empresa debería ser plenamente viable, competitiva y sólida desde el punto de vista financiero. Cuando un incidente —interno o externo— afecta negativamente a la infraestructura de TI, las operaciones corporativas pueden verse amenazadas.

Según la NIST SP 800-34 [PDF], Contingency Planning for Information Technology Systems (Planificación de contingencias para los sistemas de tecnologías de la información), del National Institute for Standards and Technology (NIST, o Instituto Nacional de Estándares y Tecnología) de los Estados Unidos, lo que viene a continuación resume la estructura ideal de un plan de recuperación de desastres TI.

1. Elaboración de la declaración de políticas para el plan de contingencia. Contar con unas directivas formales proporciona la autoridad y orientación necesaria para elaborar un plan de contingencia efectivo.

2. Realización del análisis de impacto sobre el negocio (BIA). El análisis del impacto sobre el negocio ayuda a identificar y priorizar los sistemas y componentes críticos de TI.

3. Identificación de controles preventivos. Medidas que reducen los efectos de las disrupciones al sistema y pueden aumentar su disponibilidad y reducir los costos de contingencia del ciclo de vida.

4. Desarrollo de estrategias de recuperación. Tener una estrategia integral garantiza que el sistema se recuperará de manera rápida y efectiva después de una disrupción.

5. Desarrollo de un plan de contingencia TI. El plan de contingencia debería contener orientaciones y procedimientos detallados para la restauración del sistema dañado.

6. Prueba, formación y ejecución del plan. La prueba del plan identifica lagunas en la planificación, mientras que la formación prepara al personal de recuperación para la activación del plan; ambas actividades mejoran la eficacia del plan y la preparación general de la entidad.

7. Mantenimiento del plan. El plan debería ser un documento vivo que se actualiza regularmente para mantenerlo al día con mejoras al sistema.

Desarrollo paso a paso del plan de recuperación de desastres TI

Utilizando la estructura apuntada en la publicación SP 800-34 del NIST, podemos ampliar esas actividades a la siguiente secuencia estructurada de actividades.

1. El equipo de desarrollo del plan debería reunirse con el equipo interno de tecnología, el equipo de aplicación y los administradores de redes, y establecer el alcance de la acción, como por ejemplo, elementos internos, activos externos, recursos de terceros y enlaces a oficinas/clientes/proveedores; debemos asegurarnos de informar a la dirección del departamento de TI sobre dichas reuniones para que estén bien informados.

2. Recopilar todos los documentos relevantes de la infraestructura de redes, como los diagramas de las redes, la configuración de los equipos y bases de datos.

3. Obtener copias de los planes de recuperación de redes y de TI existentes; si no los hay, proceder con los siguientes pasos.

4. Identificar las amenazas contra la infraestructura de TI que la dirección considere más preocupantes: por ejemplo, incendios, errores humanos, apagones de energía, fallo de los sistemas.

5. Identificar aquello que la dirección considera que son las principales vulnerabilidades de la infraestructura: por ejemplo, inexistencia de sistemas de respaldo en caso de apagón eléctrico, copias de bases de datos obsoletas.

6. Examinar el historial previo de apagones y disrupciones, y cómo fueron gestionados por la empresa.

7. Identificar los activos TI que la dirección considera de importancia crítica. Por ejemplo: centro de llamadas, granjas de servidores, acceso a internet.

8. Determinar el tiempo máximo de apagón eléctrico que está dispuesta a aceptar la dirección en caso de indisponibilidad de los equipos TI.

9. Identificar los procedimientos operativos que se utilizan actualmente para responder a los apagones críticos.

10. Determinar cuándo se probaron estos procedimientos para validar si siguen siendo adecuados o no.

11. Identificar el/los equipo/s de respuesta de emergencia para todas las disrupciones de la infraestructura crítica de TI; determinar su nivel de conocimientos y preparación para manejar los sistemas críticos, especialmente en casos de emergencia.

12. Identificar las capacidades de respuesta de los proveedores en casos de emergencia; si se han utilizado alguna vez; si funcionaron correctamente; cuánto paga la compañía por estos servicios; el estado del contrato de servicio; la existencia del acuerdo de nivel de servicio (SLA) y si se usa alguna vez.

13. Recopilar los resultados de todas las evaluaciones en un reporte de análisis de carencias que identifique lo que se está haciendo frente a lo que debería hacerse, con recomendaciones sobre cómo lograr el nivel requerido de preparación y las inversiones necesarias para ello.

14. Lograr que la dirección lea el repote y acuerde tomar las acciones recomendadas.

15. Preparar un plan de recuperación de desastres IT que cubra los sistemas y las redes esenciales de TI.

16. Realizar pruebas de los planes y activos de recuperación de sistemas para validar su operatividad.

17. Actualizar la documentación del plan de RD para que recoja los cambios efectuados.

18. Programar la próxima revisión/auditoría de capacidades de recuperación de desastres TI.

Aspectos clave a considerar al planificar la recuperación de desastres TI

• Apoyo de la alta gerencia. Asegúrese de tener el apoyo de la alta gerencia a fin de lograr alcanzar los objetivos del plan.
• Tomarse en serio el proceso de planificación de RD de TI. Aunque la recopilación y análisis de los datos para el plan de RD de TI puede llevar mucho tiempo, no es necesario que tenga docenas de páginas. Los plantes simplemente necesitan la información correcta, y esa información debería ser actual y precisa.
• Disponibilidad de estándares. Entre los estándares relevantes que podemos usar a la hora de desarrollar los planes de RD de TI están los siguientes: NIST SP 800-34, ISO/IEC 24762 y BS 25777.
• La sencillez es un grado. Es esencial reunir y organizar la información correcta.
• Estudiar los resultados con las unidades de negocio. Una vez finalizado el plan de recuperación de desastres, debemos cotejar sus conclusiones con los líderes de las unidades de negocio para comprobar que nuestras premisas son correctas.
• Flexibilidad. La plantilla sugerida en este artículo puede ser modificada en lo que sea necesario para conseguir nuestros objetivos.

Análisis de la plantilla del plan de RD de TI

A continuación, examinaremos el índice de la plantilla, señalando las cuestiones clave a tratar y las actividades a desarrollar.

1. Declaración de intenciones del departamento de TI — Marca la pauta y dirección del plan.

2. Declaración de políticas — Es muy importante incluir una declaración aprobada con las políticas relativas a la provisión de servicios de recuperación de desastres.

3. Objetivos — Principales metas del plan.

4. Información de contacto del personal clave — Muy importante tener la información clave de contacto cerca del comienzo del plan. Es la información más susceptible de ser utilizada de inmediato y debería ser fácil de ubicar.

5. Visión general del plan — Describe los aspectos básicos del plan, como la actualización.

6. Respuesta de emergencia — Describe lo que hay que hacer inmediatamente en caso de incidente.

7. Equipo de recuperación de desastres — Miembros y datos de contacto del equipo de RD.

8. Alerta de emergencia, escalada y activación del PRD — Pasos a seguir en las primeras fases del incidente hasta que se activa el plan de RD.

9. Medios — Consejos para tratar con los medios de comunicación.

10. Seguro — Resume la cobertura de seguros asociada con el entorno TI y otras políticas relevantes.

11. Cuestiones legales y financieras — Acciones a tomar para administrar las cuestiones legales y financieras.

12. Ejecución del PRD — Subraya la importancia de ejecutar el plan de recuperación de desastres.

13. Apéndice A — Plantillas del plan de recuperación de desastres tecnológicos — Plantillas modelo para una variedad de recuperaciones por incidentes tecnológicos; es útil tener disponible la documentación técnica de algunos proveedores selectos.

14. Apéndice B — Formularios recomendados — Formularios listos para usar que ayudarán a facilitar la finalización del plan.

Teniendo en cuenta las inversiones que las empresas realizan en infraestructuras TI, sería conveniente que inviertan también tiempo y recursos para proteger dichas inversiones de acontecimientos no previstos y potencialmente destructivos.

Articulos Relacionados

• Aspectos básicos del plan de recuperación de desastres: Actualización y revisión
• Ampliación del alcance de la recuperación de desastres
• Prueba de recuperación de desastres (DR)
• Opciones del sitio de recuperación de desastres: sitios calientes, templados y fríos
• Protegiendo los Centros de Contacto/llamadas
• La importancia de la continuidad del personal en un plan de recuperación de desastres
• Creación de una respuesta ante pandemias como parte del plan de recuperación de desastres
• Una muestra de procedimiento de lista de control de redes de recuperación ante desastres
• Proyectar con COBIT e ITIL el plan de recuperación de desastres
• Gestión de cambios en la planificación de la recuperación de desastres y la continuidad del negocio

Acerca del autor: Paul Kirvan, CISA, CISSP, FBCI, CBCP, tiene más de 20 años de experiencia en gestión de continuidad del negocio como consultor, autor y educador. Además, es secretario del Instituto de Continuidad del Negocio, capítulo de EE.UU.

Fuente: Search Data Center

Contenido completo en www.segu-info.com.ar