|
Próxima revisión
|
|
tecnica:emergenciasprocedimiento [2025/11/10 11:28] fmolinuevo creado |
| Revisión previa
|
|
tecnica:emergenciasprocedimiento [2025/11/10 12:11] (actual) fmolinuevo [Otras ideas] |
|
====== Procedimiento War Room: procedimiento de emergencias para War Rooms ====== |
|
|
===== Procedimiento Maestro maestro de Respuesta respuesta a Emergencias emergencias (Datacenter) ===== |
|
| Este plan se activa ante cualquier evento **Nivel 1 (Grave)** que amenace la integridad física del datacenter, la seguridad de los datos, o la continuidad del negocio de forma masiva. |
|
==== Principios Rectores rectores ==== |
|
- **Seguridad Humana Primero:** Ningún equipo vale más que una persona. |
- **Calma y Metodología:** El pánico genera errores. Sigue Siga el plan. |
- **Contener, luego Erradicar:** Primero evita evite que el problema se extienda, luego soluciónalo.soluciónelo |
- **Comunicar y Documentar:** La falta de información es el segundo desastre. |
|
===== Fase 1: Detección y Declaración declaración de Emergencia emergencia ===== |
|
| El objetivo de esta fase es confirmar la emergencia y activar al equipo correcto en el menor tiempo posible. |
|
- **Recepción de Alerta:** La emergencia se detecta (vía monitoreo, alerta física [humo, agua], o reporte de usuario crítico). |
| - **Prioridad Cero (Triaje Físico):** |
| * **¿Hay fuego, inundación, o riesgo eléctrico?** |
| * **SÍ:** Evacuar personal del área afectada. Activar sistemas de supresión (si es seguro) y llamar a servicios de emergencia (Bomberos, 911/100). **La seguridad del personal anula cualquier paso técnico.** |
| * **NO:** Continuar al paso 3 |
| - **Declaración de Incidente Grave:** El primer técnico en confirmar la alerta (ej. NOC, Sysadmin de guardia) debe: |
| * Declarar un "Incidente de Nivel 1" (o código rojo). |
| * Activar el **Árbol de Llamadas de Emergencia** (Call Tree) o el sistema de alertas (ej. PagerDuty, Opsgenie) |
| - **Convocatoria del ERT (Equipo de Respuesta a Emergencias):** Se convoca al equipo //core//. Esto no es una reunión de "todo el mundo", es un equipo específico: |
| * **Comandante del Incidente (IC):** 1 persona (ej. Jefe de Infraestructura o Sysadmin Sr.) que **dirige** la respuesta. No es quien "teclea", es quien toma decisiones y coordina. |
| * **Especialista de Red (Network):** Aísla y gestiona la conectividad. |
| * **Especialista de Sistemas (Sysadmin):** Gestiona servidores, virtualización y storage. |
| * **Especialista de Seguridad (Infosec):** Clave si es un ciberataque. Analiza y preserva evidencia. |
| * **Encargado de Comunicaciones:** una sola persona que gestiona la comunicación con //stakeholders// (management, negocio) para que dejen trabajar al equipo técnico. |
| - **Establecer "Sala de Guerra" (War Room):** |
| * **Virtual:** Iniciar un //bridge// de conferencia dedicado (Teams, Zoom, etc.) que permanecerá abierto hasta el final |
| * **Física:** Una sala de reuniones designada si el equipo está en sitio |
| * **Regla:** Toda la comunicación técnica pasa por aquí |
|
* **¿Hay fuego, inundación, o riesgo eléctrico?** |
* **SÍ:** Evacuar personal del área afectada. Activar sistemas de supresión (si es seguro) y llamar a servicios de emergencia (Bomberos, 911/112). **La seguridad del personal anula cualquier paso técnico.** |
* **NO:** Continuar al paso 3. |
|
<HTML><ol start="3"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Declaración de Incidente Grave:** El primer técnico en confirmar la alerta (ej. NOC, Sysadmin de guardia) debe:<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* Declarar un "Incidente de Nivel 1" (o código rojo). |
* Activar el **Árbol de Llamadas de Emergencia** (Call Tree) o el sistema de alertas (ej. PagerDuty, Opsgenie). |
|
<HTML><ol start="4"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Convocatoria del ERT (Equipo de Respuesta a Emergencias):** Se convoca al equipo //core//. Esto no es una reunión de "todo el mundo", es un equipo específico:<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* **Comandante del Incidente (IC):** 1 persona (ej. Jefe de Infraestructura o Sysadmin Sr.) que **dirige** la respuesta. No es quien "teclea", es quien toma decisiones y coordina. |
* **Especialista de Red (Network):** Aísla y gestiona la conectividad. |
* **Especialista de Sistemas (Sysadmin):** Gestiona servidores, virtualización y storage. |
* **Especialista de Seguridad (Infosec):** Clave si es un ciberataque. Analiza y preserva evidencia. |
* **Encargado de Comunicaciones:** 1 persona que gestiona la comunicación con //stakeholders// (management, negocio) para que dejen trabajar al equipo técnico. |
|
<HTML><ol start="5"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Establecer "Sala de Guerra" (War Room):**<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* **Virtual:** Iniciar un //bridge// de conferencia dedicado (Teams, Zoom, etc.) que permanecerá abierto hasta el final. |
* **Física:** Una sala de reuniones designada si el equipo está en sitio. |
* **Regla:** Toda la comunicación técnica pasa por aquí. |
|
===== Fase 2: Evaluación y Contención contención ===== |
|
| El objetivo es entender el "radio de explosión" (blast radius) y **detener el sangrado** inmediatamente. |
|
| - **Diagnóstico Rápido (Triaje Técnico):** El IC coordina al ERT para responder: |
|
* **¿Qué está afectado?** (Servicios, servidores, racks, red). |
* **¿Cuál es el impacto?** (Ej: "La base de datos de facturación está caída", "El 50% de los hosts de VMware están inaccesibles"). |
* **¿Se está extendiendo?** (Ej: "El ransomware se está moviendo lateralmente", "El agua está llegando al Rack B"). |
|
<HTML><ol start="2"></HTML> |
<HTML><li></HTML><HTML><p></HTML> - **Acción de Contención Inmediata:** //No se intenta arreglar nada aún.// El objetivo es evitar que empeore.<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* **Ej. Ciberataque (Ransomware):** |
|
* **¡Desconectar!** Aislar la red afectada. (Desconectar uplinks del datacenter, segmentar VLANs, apagar puertos de switches, bloquear IPs en el firewall). |
* Apagar servidores //comprometidos// (no los sanos) para detener el cifrado. |
|
* **Ej. Falla de Refrigeración (HVAC):** |
|
* Iniciar **apagado controlado** de sistemas no críticos (Dev, Test) para reducir la carga térmica y ganar tiempo para los sistemas de producción. |
|
* **Ej. Falla de Storage/Corrupción de Datos:** |
|
* Poner las LUNs o bases de datos afectadas en modo //read-only// o //offline// para prevenir más corrupción. |
|
* **Ej. Inundación/Fuego:** |
|
* Si es seguro, ejecutar el **EPO (Emergency Power Off)** del área afectada para prevenir cortocircuitos o electrocución. |
|
<HTML><ol start="3"></HTML> |
<HTML><li></HTML><HTML><p></HTML> - **Preservación de Evidencia (Rol de Infosec):**<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* Si se sospecha de un ataque, **no apagar ni reiniciar** las máquinas clave //antes// de tomar snapshots de memoria (RAM dump) y de disco. |
* La contención (aislamiento de red) es prioritaria, pero la evidencia es crucial para la erradicación. |
|
| ===== Fase 3: Erradicación ===== |
|
|
| - **Identificación de Causa Raíz (RCA):** |
| * Aquí es donde el equipo investiga. ¿Por qué falló el HVAC? ¿Por dónde entró el atacante? ¿Qué causó la corrupción del array? |
| * Se analizan logs (Firewall, AD, VMware, SAN), métricas de monitoreo, y se correlaciona la línea de tiempo del incidente |
| - **Plan de Erradicación:** Una vez identificada la RCA, el IC aprueba un plan para eliminarla |
| * **Ej. Ciberataque:** |
| * Identificar y eliminar el malware |
| * Parchar la vulnerabilidad explotada (ej. actualizar el FortiOS, parchear el servidor Exchange) |
| * **Rotar TODAS las credenciales** (Admins, cuentas de servicio) que pudieron estar expuestas |
| * **Ej. Falla Física/Hardware:** |
| * Reemplazar la PDU fallida, el controlador de la SAN, o la cuchilla (blade) defectuosa |
| * Contactar a proveedores (ej. servicio técnico de la climatizadora, compañía eléctrica) |
| * **Ej. Falla de Software/Parche:** |
| * Realizar el //rollback// del parche defectuoso |
|
* Aquí es donde el equipo investiga. ¿Por qué falló el HVAC? ¿Por dónde entró el atacante? ¿Qué causó la corrupción del array? |
* Se analizan logs (Firewall, AD, VMware, SAN), métricas de monitoreo, y se correlaciona la línea de tiempo del incidente. |
|
<HTML><ol start="2"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Plan de Erradicación:** Una vez identificada la RCA, el IC aprueba un plan para eliminarla.<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* **Ej. Ciberataque:** |
|
* Identificar y eliminar el malware. |
* Parchar la vulnerabilidad explotada (ej. actualizar el FortiOS, parchear el servidor Exchange). |
* **Rotar TODAS las credenciales** (Admins, cuentas de servicio) que pudieron estar expuestas. |
|
* **Ej. Falla Física/Hardware:** |
|
* Reemplazar la PDU fallida, el controlador de la SAN, o la cuchilla (blade) defectuosa. |
* Contactar a proveedores (ej. servicio técnico de la climatizadora, compañía eléctrica). |
|
* **Ej. Falla de Software/Parche:** |
|
* Realizar el //rollback// del parche defectuoso. |
|
===== Fase 4: Recuperación y Verificación verificación ===== |
|
| El objetivo es restaurar los servicios de forma segura y ordenada, activando el Plan de Recuperación ante Desastres (DRP) si es necesario. |
|
| - **Priorización de Servicios:** No se levanta todo a la vez. Se sigue un orden de prioridad de negocio. |
| * **Prioridad 0 (Core):** Identidad (Active Directory, DNS, DHCP), Red Core, Firewalls |
| * **Prioridad 1 (Críticos):** ERP, Bases de Datos principales, Aplicaciones de cara al cliente |
| * **Prioridad 2 (Soporte):** Correo interno, BI, sistemas secundarios |
| * **Prioridad 3 (No urgentes):** Servidores de Dev/Test, archivos históricos |
| - **Restauración (El "cómo"):** |
| * **Si es por Ciberataque/Corrupción:** **Restaurar desde backups limpios y verificados.** Este es el paso más común. Asumir que el entorno actual está contaminado |
| * **Si el Datacenter está Inoperable (Fuego/Inundación):** Declarar "Desastre" y activar el **Failover al sitio de DR (Datacenter Secundario)** |
| * **Si fue Falla de Hardware:** Levantar servicios en el hardware reparado o en //spare// (ej. vMotion de VMs a hosts sanos) |
| - **Verificación y Pruebas Funcionales:** |
| * El servicio **no está "resuelto" solo porque pinguea.** |
| * El equipo técnico (Sysadmin, Red) valida la conectividad y el estado del SO |
| * Se contacta a los **"Dueños del Negocio" (Business Owners)** o usuarios clave para que realicen pruebas funcionales (ej. "Intenta generar una factura", "Consulta el stock") |
|
* **Prioridad 0 (Core):** Identidad (Active Directory, DNS, DHCP), Red Core, Firewalls. |
* **Prioridad 1 (Críticos):** ERP, Bases de Datos principales, Aplicaciones de cara al cliente. |
* **Prioridad 2 (Soporte):** Correo interno, BI, sistemas secundarios. |
* **Prioridad 3 (No urgentes):** Servidores de Dev/Test, archivos históricos. |
|
<HTML><ol start="2"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Restauración (El "cómo"):**<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* **Si es por Ciberataque/Corrupción:** **Restaurar desde backups limpios y verificados.** Este es el paso más común. Asumir que el entorno actual está contaminado. |
* **Si el Datacenter está Inoperable (Fuego/Inundación):** Declarar "Desastre" y activar el **Failover al sitio de DR (Datacenter Secundario)**. |
* **Si fue Falla de Hardware:** Levantar servicios en el hardware reparado o en //spare// (ej. vMotion de VMs a hosts sanos). |
|
<HTML><ol start="3"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Verificación y Pruebas Funcionales:**<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* El servicio **no está "resuelto" solo porque pinguea.** |
* El equipo técnico (Sysadmin, Red) valida la conectividad y el estado del SO. |
* Se contacta a los **"Dueños del Negocio" (Business Owners)** o usuarios clave para que realicen pruebas funcionales (ej. "Intenta generar una factura", "Consulta el stock"). |
|
===== Fase 5: Cierre del Incidente incidente y Monitoreo monitoreo ===== |
|
| El objetivo es confirmar la estabilidad y volver a la operación normal. |
|
| - **Monitoreo Intensivo (Modo "Paranoico"):** |
| * Tras la restauración, el ERT permanece en la "Sala de Guerra" monitoreando activamente el rendimiento, los logs y las alertas de seguridad durante un período de gracia (ej. 2 a 4 horas) |
| * Se busca cualquier reincidencia del problema (ej. el atacante intenta volver a entrar, el hardware vuelve a fallar) |
| - **Declaración de "Todo Resuelto" (All-Clear):** |
| * Solo cuando el IC, basado en el monitoreo y la validación de negocio, confirma que el entorno está estable, se declara el fin de la emergencia |
| - **Comunicación Final:** El Encargado de Comunicaciones envía el informe final a todos los //stakeholders// indicando que el incidente ha concluido y los servicios están operativos |
| - **Cierre de la Sala de Guerra:** Se cierra el //bridge// de conferencia |
|
* Tras la restauración, el ERT permanece en la "Sala de Guerra" monitoreando activamente el rendimiento, los logs y las alertas de seguridad durante un período de gracia (ej. 2 a 4 horas). |
* Se busca cualquier reincidencia del problema (ej. el atacante intenta volver a entrar, el hardware vuelve a fallar). |
|
<HTML><ol start="2"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Declaración de "Todo Resuelto" (All-Clear):**<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
* Solo cuando el IC, basado en el monitoreo y la validación de negocio, confirma que el entorno está estable, se declara el fin de la emergencia. |
|
<HTML><ol start="3"></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Comunicación Final:** El Encargado de Comunicaciones envía el informe final a todos los //stakeholders// indicando que el incidente ha concluido y los servicios están operativos.<HTML></p></HTML><HTML></li></HTML> |
<HTML><li></HTML><HTML><p></HTML>**Cierre de la Sala de Guerra:** Se cierra el //bridge// de conferencia.<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> |
|
===== Fase 6: Post -Mortem mortem (Lecciones Aprendidasaprendidas) ===== |
|
| Esta es la fase más importante para el futuro. Se realiza //dentro de los 5 días hábiles// posteriores al incidente, **sin culpar a nadie (blameless post-mortem)**. |
|
- **Agendar la Reunión Post-Mortem:** Invitar al ERT y a los //stakeholders// clave. |
- **Revisar la Documentación:** Se analiza la línea de tiempo del incidente (que se debió documentar durante la Fase 2). |
| - **Análisis (Las 5 Preguntas):** |
| * **¿Qué pasó?** (Resumen fáctico del incidente) |
| * **¿Cuál fue el impacto?** (Horas de inactividad, costo, datos perdidos) |
| * **¿Qué salió bien?** (Ej: "La segmentación de red detuvo al ransomware", "El backup funcionó perfecto") |
| * **¿Qué salió mal?** (Ej: "Tardamos 45 minutos en activar al ERT", "El Comandante del Incidente no estaba claro al inicio", "El sensor de agua falló") |
| * **¿Qué haremos para evitar que se repita?** (Acciones concretas, con un responsable y una fecha de entrega. Ej: "Comprar PDU con monitoreo", "Implementar 2FA en la VPN", "Mejorar el sistema de alertas") |
| - **Actualizar la documentación:** Los aprendizajes se usan para mejorar //este mismo procedimiento// |
|
* **¿Qué pasó?** (Resumen fáctico del incidente). |
* **¿Cuál fue el impacto?** (Horas de inactividad, costo, datos perdidos). |
* **¿Qué salió bien?** (Ej: "La segmentación de red detuvo al ransomware", "El backup funcionó perfecto"). |
* **¿Qué salió mal?** (Ej: "Tardamos 45 minutos en activar al ERT", "El Comandante del Incidente no estaba claro al inicio", "El sensor de agua falló"). |
* **¿Qué haremos ===== Puntos Clave para evitar que se repita?** (Acciones concretas, con un responsable y una fecha de entrega. Ej: "Comprar PDU con monitoreo", "Implementar 2FA en la VPN", "Mejorar el sistema de alertas").Sysadmin/Infosec ===== |
|
<HTML><ol start="4">< * **Linux:** En un ataque, no olvides revisar crontab, /HTML> |
<HTML><li><tmp, ~/HTML><HTML><p><.ssh/HTML>authorized_keys y las conexiones de red (netstat -antp) para contención y erradicación |
* *Actualizar la Documentación*Windows:** Los aprendizajes se usan Revisa Tareas Programadas, Servicios, logs de Event ID 4624 (Logon) y 4625 (Failed Logon), y usa herramientas de Sysinternals (especialmente TCPView y Autoruns) para mejorar la erradicación |
| * **Segmentación:** Tu mejor arma de contención es una red bien segmentada (VLANs, ACLs, microsegmentación). Si todo está en la misma red "plana", estás perdido |
* **Backups:** Sigue la regla **3-2-1-1-0**: 3 copias, 2 medios distintos, 1 //este mismo procedimiento//.<HTML><offline/p></ HTML><HTML><(o /li></HTML><HTML><air-gapped/ol></HTML>), 1 inmutable, y 0 errores de verificación |
|
====🔑 Puntos Clave para el Sysadmin/Infosec = Otras ideas ===== |
|
* **Linux:** En - Desconectar la corriente de los switches/gateways/routers en vez de cables de red de servidores |
- Realizar un ataqueinventario preliminar de los servidores y servicios comprometidos, no olvides revisar crontabpara informar y tomar acciones |
- Considerar que el acceso a los backups esté restringido, /tmpya sea mediante el acceso a un puerto con credenciales, ~/.ssh/authorized_keys y las conexiones o bien en modo sólo lectura si es necesario accederlos mediantes CIFS |
| - Realizar backups remotos, nunca en el propio equipo |
- Realizar backups remotos geográficamente alejados, especialmente de red (netstat datos críticos para la operación de la empresa |
- antp) Servidores de backup sin acceso desde los servidores de origen |
- Identificar los servidores afectados por ejemplo con una simple etiqueta "Infectado", tratando de evitar apagarlos para contención intentar preservar evidencia del ataque que pueda llevar a obtener información forense relevante |
- Documentar el caso lo mejor posible, indicando qué ocurrió y erradicación.qué se hizo, y mejorarlo poco a poco con el tiempo, con nuevos incidentes o simplemente revisando y registrando nuevas ideas |
* **Windows- En general se recomienda: |
* * Revisa Tareas Programadasevitar pagar, Servicios, logs ya que nada asegura que se obtenga la clave de Event ID 4624 (Logon) y 4625 (Failed Logon)descifrado, se financia a los desarrolladores del ransomware, e incluso si se obtiene la clave, el trabajo para descifrar todos los archivos es una tarea titánica, y usa herramientas además agrega a la empresa al listado de Sysinternals (especialmente TCPView "dispuestos a pagar" con lo cual se garantiza nuevos intentos de ataque; |
* evitar tomarse demasiado tiempo para identificar y Autoruns) buscar la cepa del ransomware pues es sumamente raro que exista una clave de descifrado preexistente; |
| * tomar capturas e información de los mensajes, para documentar, denunciar, o aportar a investigadores, y si es posible del ejecutable o código que se encuentre, teniendo las precauciones del caso; |
| * evitar intentar limpiar un servidor infectado, se debe blanquear los discos, y reinstalar de cero |
- Cambiar la contraseña de todos los administradores antes de comenzar la erradicaciónreinstalación. Considerar la necesidad de forzar cambio de contraseña/desactivar todos los usuarios si es necesario |
* **Segmentación- En dominios Windows: |
| * asumir que todas las contraseñas del dominio están comprometidas; |
* Tu mejor arma forzar un reseteo de contención contraseña para todas las cuentas de usuario; |
| * resetear todas las cuentas de servicio y de administrador; |
| * si el Domain Controller quedó operativo, resetear el token KRBTGT dos veces para invalidar todos los tickets Kerberos existentes que los atacantes puedan haber robado |
- Identificar si es una red bien segmentada (VLANsposible, ACLsy erradicar, microsegmentación). Si todo está en el vector de ingreso |
- Considerar la misma red posibilidad de que el atacante aún tenga acceso, y tomar todas las precauciones necesarias |
- El acceso al dominio, y los usuarios administrador deben ser extremadamente limitados, preferentemente configurarles acceso exclusivo desde algunas IPs consideradas "planaseguras", estás perdido.y dejar registrado en una knowledge base (KB) cualquier cambio (altas, bajas y modificaciones) para referencia posterior |
* **Backups- Dejar registrada alta/baja/modificaciones de usuarios en una KB |
| - Servidores Windows que no necesiten estar en el dominio, dejarlos fuera de él, por ejemplo réplicas de DBs, backups, etc |
| - Los servidores Linux, aunque sean internos sin acceso desde afuera, deberían tener: |
| * root con diferentes contraseñas (evaluar si es suficiente crear una regla mnemotécnica para simplificar las diferencias entre ellas, y si algunos pueden tener contraseñas de root totalmente diferentes); |
* Sigue fail2ban configurado y activado |
- El servicio SSH en los servidores Linux debería estar configurado para permitir el acceso exclusivo de los usuarios especificados, con la regla **3AllowUser, lo cual evita que se cree algún usuario de prueba (como he visto en algunos servidores) y ese usuario ya por defecto tenga acceso por SSH |
- 2Identificar servidores críticos (para operación de la empresa, por los datos almacenados, o los servicios prestados) y considerar endurecer las políticas de acceso a los mismos |
- 1-1Básicamente, considerar que si algo es "demasiado fácil", quizá sea inseguro |
- 0**: 3 copiasEl concepto de seguridad es dinámico, 2 medios distintosy las políticas de seguridad deben ser integrales, 1 //offline// (revisadas periódicamente como un todo, evitando nichos y "corralitos" de poder o //airprejuicios |
- gappedRealizar periódicamente auditorías de seguridad |
| - Considerar el acceso por VPN como un potencial vector de acceso muy agresivo. Usuarios y accesos deben ser registrados, y revisados los accesos periódicamente, dando de baja aquellos que sean necesarios. Es recomendable tener una política de vencimiento de los certificados, para obligar a todos los que necesiten acceder a que tengan que renovarlos |
- El acceso desde afuera a puertos internos debe ser registrado y evaluado en cada caso, para lo cual se debe identificar un responsable del//)los firewalls, 1 inmutablequien llevará a cambio los cambios, documentando y 0 errores realizando el correspondiente backup previo y posterior |
- Educar al personal técnico y no técnico sobre mejores prácticas tanto de verificaciónseguridad como de trabajo. Y hacerlo periódicamente, repasando conocimientos y mejorando cada vez, agregando aquellas nuevas consideraciones que sean necesarias |
| - Documentar todo lo posible y mejorar la documentación de manera permanente, educando y obligando a los responsables a hacerlo, y mantenerlo actualizado |
| - Educar y estimular a los equipos que funcionen como uno solo, colaborando entre sí, y/o cambiando roles para evitar dependencias críticas de alguno de ellos |
|
