Diez pasos para planear una respuesta eficaz frente a un incidente cibernético

agosto 15, 2013 § Deja un comentario

Los ciberdelincuentes exitosos, tienen como objetivo atacar las organizaciones de todos tamaños en todos los sectores de la industria. Las organizaciones tienen que estar preparadas para responder a un ataque inevitable de sus datos.

La respuesta debe estar guiada por un plan de acciones que tienen como objetivo gestionar un incidente de seguridad cibernético con el fin de limitar el daño, aumentar la confianza de las partes externas interesadas y reducir los costos y el tiempo de recuperación.

Lo que encontramos en nuestro trabajo con las grandes organizaciones globales es que muchas empresas tienen planes de respuesta, pero no están realmente operativos. A menudo, la documentación de cómo actuar en tal caso de ataque, no está actualizada, inaccesible a los encargados de decisiones, o alguna combinación de estos.

En muchos casos, especialmente en las organizaciones globales, planes de respuesta no están integrados en los departamentos susceptibles a un ataque. Los planes de desarrollo en grupos individuales inhiben el intercambio de información crítica y las mejores prácticas. Esto conduce a una falta de coordinación en los esfuerzos que necesitan más atención.

Hay organizaciones que son muy conscientes y siguen practicando simulacros de incendio, pero no practican los pasos que conducirían a un caso de un ataque de datos.

Aquí están los 10 pasos principales para orientar a las empresas en la creación – y la aplicación – de los planes de respuesta a incidentes:

  1. Asignar un ejecutivo para asumir la responsabilidad por el plan y para integrar los esfuerzos de respuesta de incidentes a las regiones geográficas y unidades de negocio.
  2. Desarrollar una auditoria de los fallos potenciales, amenazas y riesgos. Actualizarlos continuamente basado en los cambios en el entorno de las amenazas.
  3. Desarrollar guías de respuesta rápida de fácil acceso para los escenarios más probables.
  4. Establecer procesos para tomar decisiones importantes, como cuando aislar las zonas comprometidas de la red.
  5. Mantener las relaciones con los grupos clave de interés externos como los en forzadores de la ley.
  6. Mantener los acuerdos de nivel de servicio y relaciones con proveedores externos y especialistas para la remediación.
  7. Asegúrese de que la documentación de los planes de respuesta están disponibles para toda la organización y se actualizan de forma rutinaria.
  8. Asegúrese de que todos los miembros del equipo entiendan sus funciones y responsabilidades en el caso de un incidente cibernético.
  9. Identificar las personas que son críticas para la respuesta a incidentes y asegurarse de que haya redundancia de las personas.
  10. 10. Formar un grupo responsable para realizar simulaciones de práctica para una respuesta rápida. Algunas organizaciones realizan rutinariamente juegos de guerra para sus planes para aumentar de la concientización de los gestores y para perfeccionar sus capacidades de respuesta en caso de un ataque.

Todo eso no sería posible sin el patrocinio eficaz de los ejecutivos. Viendo el impacto de los ataques recientes, la respuesta a incidentes debe tener una prioridad mayor en la agenda de los ejecutivos.

Poner en desarrollo un plan sólido es imperativo para las empresas. Cuando un ataque cibernético es exitoso y la escala y el impacto del ataque es notable a los clients, estos se preguntarán “que es hecho esta institución para prepararse?”.

Fuente: Technet (Inglés)

Plan para la Recuperación de Desastres de TI

marzo 25, 2013 § 1 comentario

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

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

Ejercicios para los CERT/CSIRT

febrero 22, 2013 § Deja un comentario

La Agencia Europea de Seguridad de las Redes y de la Información (ENISA) ha actualizado recientemente los materiales formativos desarrollados para la realización de ejercicios y capacitación en el ámbito de los centros de de respuesta a incidentes de seguridad (CERT/CSIRT).

La ENISA comenzó a desarrollar y difundir estos materiales en 2008 (primeros doce ejercicios) hasta completarlos en 2012 con un total de veintitrés ejercicios para que los CERT/CSIRT puedan realizar prácticas de preparación y/o entrenamiento de sus capacidades de respuesta ante incidentes de seguridad.

Entre los materiales publicados se encuentran el manual para el instructor, los ejercicios a realizar con su enunciado y tiempo estimado, y el conjunto de materiales que pueden utilizar los estudiantes. Este conjunto de instrumentos incluyen todo el material necesario para llevar a cabo los ejercicios y prácticas incluyendo tanto maquinas virtuales para la realización de las prácticas como trazas de red para ejercicios concretos, etc.

En los ejercicios planteados se encuentran algunos de carácter básico, relacionados con gestión de incidentes , como puede ser el tratamiento de una vulnerabilidad por parte de un CERT/CSIRT, el establecimiento de los contactos necesarios para la resolución de incidentes, o cómo escribir un aviso de seguridad. También existen otro tipo de pruebas que se centran más en los aspectos técnicos como pueden ser el análisis forense de redes, las amenazas e incidentes en dispositivos móviles, los incidentes generados por APT’s o la gestión de incidentes en la nube.

Los primeros doce ejercicios disponen también del manual y de la información complementaria sobre el conjunto de herramientas en español traducidas por INTECO-CERT y publicadas en 2010, así como de una versión online para consultar la información de cada ejercicio.

La ENISA ha publicado junto con todo el material un video donde se explica el objetivo y contenido de estas guías, así como su utilidad para los CERT/CSIRT. En él también se analizan los pilotos sobre los que se utilizaron estos materiales para la formación de los equipos de respuesta a incidentes congregados en Moldavia y en Japón.

Fuente: INTECO-CERT

Cómo preparar un plan de contigencias de una empresa (IBM)

diciembre 5, 2012 § Deja un comentario

Tornados, inundaciones, sismos, huracanes y cenizas volcánicas son apenas algunos de los “regalos” que la naturaleza nos brinda con frecuencia y que pueden afectar gravemente la continuidad de las operaciones de cualquier compañía. IBM resumió en 6 consejos cuales son los puntos que hay que tener previstos antes de la eventual llegada de un desastre natural.
Las contingencias climáticas y los desastres naturales son cotidianos: terremotos, huracanes, cenizas volcánicas y muchas otras circunstancias imprevistas interfieren no sólo con la vida cotidiana de las personas sino también con la actividad laboral de cualquier compañía, grande o pequeña.
Por eso, todo responsable de tecnología, o directivo general de una empresa, tiene que tener preparado -y ensayado- un plan de acción previo a cualquier pronóstico problemático.

Los expertos de IBM generaron una lista de chequeo con seis tips para que cualquiera pueda verificar su grado de preparación ante de una contingencia.
1) Validar el Plan de Back-up.
Hay que verificar primero que tenemos un plan de respaldo de datos e información en marcha y luego considerar si el acceso a esa data es posible desde otro ubicación geográfica. Una posibilidad que está surgiendo en los últimos tiempos es recurrir a servicios en la nube para alojar los datos claves y permitir a cualquier organización responder a cualquier condición con una mínima interrupción en los procesos.

2) Considerar el impacto de un desastre en los empleados.
Hace ya tiempo que hay una coincidencia: el capital humano es el elemento principal de cualquier compañía y eso debe ser considerado en cualquier plan de contingencias. Pero con una salvedad: para cada integrante de la empresa su propio elemento central es la familia. Y por lo tanto la compañía debe considerar este dato en el caso de, por ejemplo, tener que mudarse a otra locación en forma temporaria. En ese caso es posible que también tenga que movilizaslos junto a su familia, con los correspondientes gastos y problemas asociados que deberán ser previamente considerados.

3) Las comunicaciones.
En segundo lugar, una vez considerado el punto del recurso humano, hay que desarrollar un sistema de comunicación entre personal de la empresa. Hay que tener pensado en forma previa como y con qué medios se comunicará la compañía con sus empleados, con sus clientes, con sus socios de negocios y proveedores tras un desastre natural.

4) El efecto dominó.
Tal como mostró el reciente accidente de la planta nuclear en Japón, un desastre regional puede terminar en otros eventos impensados. Así, un huracán no sólo provocará vientos y lluvias sino que también puede desatar una posterior inundación lo que, a su vez, puede agravar los cortes de energía de comunicaciones y causar cortes de rutas y complicaciones en la logística y el transporte.

5) Planear la duración de una catástrofe.
Al momento de pensar un plan de contingencias es necesario considerar el impacto que tendrá la duración de la interrupción de la vida cotidiana. Un huracán puede pasar en dos días, una inundación puede durar una semana, y la emisión de cenizas volcánicas varios meses. Cada uno de esos eventos tendrá un impacto en forma diferente en la operación de la compañía.

6) Pensamiento lateral.
Aunque los directivos de la empresa tengan a punto y actualizado un plan de contingencias es necesario considerar qué pasa con los proveedores de productos y servicios. Nuestra preparación podría no servir de nada si nos encontramos con que un proveedor crítico deja de operar durante semanas. Esos elementos también deben ser considerados en un plan de recuperación de desastre.

Fuente: ITendencias

Distancia entre sitio primario y alternativo

noviembre 20, 2012 § 1 comentario

El sitio alternativo para su centro de datos debe estar ubicado a 50 kilómetros de distancia del sitio primario. No, mejor a 100 kilómetros… o ¿eran 200 millas? Pues bien, nada de esto es correcto, la verdad es que no hay una distancia única para todos y que permita responder a esta pregunta.

En 2002 y 2003, los reguladores federales de Estados Unidos habían previsto exigir a las instituciones financieras trasladar sus centros de recuperación de desastres a 200 o 300 millas de distancia de los sitios principales. Sin embargo, esta iniciativa no sólo fracasó porque los bancos se opusieron firmemente a dicha regulación, sino también porque ha demostrado ser absolutamente inviable.

La situación en la mayoría de los países es similar. Por supuesto, no estoy familiarizado con todas las regulaciones en el mundo, pero de los que he leído, no he encontrado ninguno con una definición precisa. La mayoría de las regulaciones que tienen que ver con este asunto, sin embargo, dicen que debe haber un sitio de recuperación de desastres a una “distancia segura”.

Evaluación del riesgo

Por lo tanto, la decisión es, obviamente, dejada a las propias compañías, y estas decisiones no pueden tomarse en base a sentimientos de alguien sino basados en un estudio serio. En este caso, el estudio se llama “evaluación del riesgo”, y su propósito es tener en cuenta todos los factores pertinentes.

Estos son los factores que tienden a empujar la ubicación cada vez más lejos:

  • Terremotos: si su ubicación está en una zona sísmica o sensible
  • Inundaciones: posicionar el sitio alternativo a una altura distinta del primario
  • Tsunamis: no colocar la ubicación primaria y secundaria en la misma costa de un océano
  • Otros desastres naturales, por ejemplo, incendios forestales, tornados/huracanes, volcanes: si el sitio primario se encuentra cerca de estas zonas, el sitio de recuperación de desastres debe estar lo más lejos posible
  • Grandes instalaciones industriales, centrales nucleares o instalaciones militares: de nuevo, por lo menos uno de las ubicaciones deben estar a una distancia segura
  • Dependencia de la misma fuente de energía eléctrica: buscar ubicaciones en una red eléctrica diferente

Incluso si su evaluación de riesgos no demuestra nada de lo anterior, tome en cuenta otros riesgos como las enfermedades pandémicas porque en tales casos, las autoridades probablemente cerrarán el área metropolitana.

Sin embargo, hay algunos factores que obligan a colocar un sitio de recuperación de desastres tan cerca como sea posible:

  • Enlaces de telecomunicaciones: cuanto más alejados están los sitios, más difícil se hace comunicarlos (es decir, más costoso) y replicar los datos entre ellos
  • Si sus empleados tienen la responsabilidad de viajar al lugar alternativo en caso de desastre, tienen que ser capaces de hacerlo en el RTO (Recovery Time Objective) fijado, además, el camino entre los sitios no debe estar lleno de puentes y túneles.

En conclusión, para mitigar la mayor parte de los riesgos sugiero que ponga un sitio de recuperación de desastres en alguna parte entre 30 millas (50 kilómetros) y 100 millas (160 kilómetros) de distancia de su ubicación principal. Pero, de nuevo, por favor haga su propia evaluación del riesgo.

Fuente: ISO27001Standard

Se cayó Wikipedia: le cortaron dos cables

agosto 8, 2012 § Deja un comentario

Este lunes Wikimedia, la fundación que maneja la enciclopedia más grande del mundo, reportó una caída en sus servidores por la mañana. El daño duró aproximadamente dos horas y después de que fue reparado, declaró que la falla se debió a que dos cables que se extienden entre Tampa y Virginia fueron cortados.

Un vocero de la fundación, David Gerard, bromeó diciendo que gran parte del equipo que utiliza la Fundación está hecho de “cinta aislante y cuerdas”, pero en realidad no sabe muy bien quién fue el responsable (si es que hay uno) de haber cortado los cables. Tampoco se sabe muy bien dónde ocurrió el daño.

Una hora después de que fue reportado el daño los cables fueron reinstalados. Las páginas se demoraron una hora más en restablecer sus funciones normales. Al parecer su servicio móvil no fue afectado por este daño, pero presentó algunas fallas menores que duraron un poco más de dos horas.

Wikimedia tiene dos grandes centros operativos: uno en Tampa y el otro en Virginia. “¡Todos fuimos afectados!“, declaró Gerad sobre lo sucedido. La fundación, que sigue recibiendo continuamente donaciones, aprovechó el anunció del daño en el sitio web para indicar que aun necesitan donaciones para mejorar el hardware con el que están trabajando. Gerard recordó que la fundación vive de las donaciones que todo el mundo le hace.

Lo importante es que Wikipedia y todos los demás sitios web de la fundación ya están funcionando bien. Puede que este sea un llamado de atención a todos los que usamos la enciclopedia a diario y la queremos disponible (gratis) por mucho tiempo más. Ojalá que si algún día deja de existir Wikipedia (que ojalá nunca ocurra), no sea por falta de recursos.

Fuente: Enter.co

El server de Amazon EC2 dejó de funcionar por el clima

junio 30, 2012 § 1 comentario

“Advertimos que algunos usuario están experimentando problemas en el streaming de películas y series de TV. Estamos trabajando para resolver el problema”, admitió Netflix en un Netflix admitió en twitter los problemas en el servicios posteado sobre la medianoche del viernes.

Sin embargo, el trending mundial fue My Instagram, sitio que, según informa Forbes.com, tuvo el mismo motivo que Netflix para sus problemas de servicio: la caída del server de Amazon EC2.

La Elastic Computer Cloud (una de las famosas “nubes”) que opera en North Virginia dejó de funcionar, debido a las violentas tormentas que cayeron sobre Washington y provocaron innumerables inconvenientes.

Vientos huracanados, rayos y cortes de energía masivos afectaron a la región donde se aloja el EC2, que presta servicios tanto para Netflix e Instagram como para Pinterest. Las últimas dos estuvieron fuera de servicio durante la noche.

El corte afectó a usuarios de todo el mundo, pero especialmente a los del este de los Estados Unidos, que estuvieron más de dos horas sin servicio en un momento de alto tráfico -viernes por la noche-, asestando un golpe que pone de relieve los riesgos de la tecnología de “nube”.

Hace dos semanas, el mismo servidor había sufrido un corte de servicio de seis horas, demostrando la vulnerabilidad, dependencia e impacto mundial que pueden tener las cuestiones climáticas en los servicios de las redes sociales más populares.

Fuente: Infobae

¿Dónde estoy?

Actualmente estás explorando la categoría bcp en Seguridad Informática.