¿Por qué el cumplimiento y la ciberseguridad son una responsabilidad compartida?

 

En el panorama empresarial actual, el cumplimiento normativo y la ciberseguridad no son sólo preocupaciones técnicas, sino responsabilidades que abarcan a toda la organización, sus socios y usuarios. 

Cuando hablamos de proveedores de nube, por ejemplo, la responsabilidad no sólo recae en los proveedores, sino también en sus socios y clientes.

 Según un informe de la consultora Gartner, en 2025 el 99% de las brechas de seguridad seránresponsabilidad del propio cliente.

La evolución del cumplimiento y la ciberseguridad

En los últimos años, ha habido un aumento significativo de la regulación relacionada con la privacidad y la protección de datos, como el Reglamento General de Protección de Datos (GDPR) en la Unión Europea y la Ley General de Protección de Datos (LGPD) en Brasil. Estas regulaciones reforzaron la importancia de proteger la información personal de las personas y establecieron pautas estrictas para el manejo adecuado de estos datos.

Además, el creciente número de amenazas cibernéticas, como ataques de ransomware y fugas de datos, han puesto de relieve la necesidad de implementar medidas sólidas de ciberseguridad para proteger las operaciones comerciales y la confianza de los clientes.

Responsabilidad compartida

El Cumplimiento y la Ciberseguridad no pueden verse como tareas exclusivas del equipo Legal y de TI. Cada miembro de la organización, incluidos los socios y proveedores de servicios, desempeña un papel en el mantenimiento de un entorno seguro. 

A continuación se presentan algunas razones por las que el cumplimiento y la ciberseguridad son una responsabilidad compartida:

Protección de datos del cliente 

El cumplimiento de normativas de privacidad como GDPR y LGPD tiene como objetivo proteger los datos personales de los clientes. Todos los departamentos que manejan datos deben conocer las prácticas adecuadas de procesamiento de datos para evitar infracciones.

Creando una cultura de seguridad

La concienciación y la educación son clave. La capacitación periódica sobre prácticas seguras de TI y ciberseguridad puede ayudar a los empleados a identificar amenazas y actuar de manera proactiva para prevenirlas.

Gestión de riesgos

El equipo de liderazgo debe reconocer y evaluar los riesgos asociados con el cumplimiento y la ciberseguridad. Esto implica implementar políticas, procedimientos y tecnologías apropiadas para mitigar estos riesgos.

Asociación con proveedores de TI y ciberseguridad

Las empresas que brindan soluciones de TI y ciberseguridad desempeñan un papel crucial en la protección de los activos digitales de las organizaciones. Seleccionar socios confiables y colaborar para implementar soluciones efectivas son esenciales para el éxito. 

Respuesta al incidente

Todos los empleados deben estar preparados para actuar en caso de incidentes de seguridad, como fugas de datos o ciberataques. Una respuesta rápida y coordinada es esencial para minimizar los daños.

 

Cómo las empresas pueden adaptarse al modelo de seguridad

El cumplimiento y la ciberseguridad son más que simples aspectos técnicos del funcionamiento de una empresa. Estos son pilares que respaldan la confianza del cliente, la reputación de la marca y la integridad de los datos. 

 

La responsabilidad compartida en toda la organización, junto con asociaciones con proveedores especializados de TI y ciberseguridad, crea un entorno resiliente protegido contra amenazas cada vez más sofisticadas. 

 

Recuerde, al tratar el cumplimiento y la ciberseguridad como una responsabilidad compartida, su empresa estará mejor posicionada para abordar de manera efectiva los desafíos digitales y proteger su futuro.

Software Defined Perimeter (SDP), o tambien conocida como la "Black Cloud,"

Quien actúa ya hace algunos años con IT o Seguridad debe recordar del famoso y tan nombrado perímetro de seguridad y de las herramientas de protección perimetral. Básicamente, el perímetro era responsable de aislar nuestro entorno, creando una barrera que sólo los usuarios autorizados y confiables pudieran acceder a las aplicaciones, información, sistemas, etc..  Estaba claro el límite entre el entorno externo e interno, acceso público y restringido, red interna y dmz, etc…

Históricamente, cada vez que hablamos de proteger nuestro entorno e infraestructura, pensamos establecer un perímetro de seguridad, fortalecer las soluciones de seguridad de frontera y segregar la infraestructura, buscando proteger el entorno de las amenazas externas que puedan comprometer nuestros sistemas. Sin embargo, el perímetro de la forma que conocemos se ha vuelto obsoleto rápidamente por un número de razones, entre ellas:

• Internet tiene muchas falencias cuando hablamos de seguridad, pero eso es parte de su mismo ADN. Y si las cosas se quedan como son, esas falencias sólo empeoraran.

• los atacantes pueden fácilmente acceder a los dispositivos dentro del perímetro y atacar la infraestructura de un punto interno

• Conceptos como BYOD aumentan las posibilidades de tener un dispositivo comprometido dentro del perímetro de seguridad establecido

• la infraestructura tradicional (interno y centros de datos) se migran a la nube, haciendo que los sistemas y aplicaciones a migrar estén fuera del perímetro

• El gran movimiento de aparatos, dentro y fuera del perímetro y la migración de sistemas y aplicaciones fuera del ambiente controlado, convierten el perímetro cada vez menos eficiente.

• Si estamos cambiando la forma en que consumimos tecnología, también hay que cambiar cómo la protegemos. 

Software define perímetro

SDP (Software define perímetro) es un nuevo concepto de perímetro definido de software, que permite al propietario de la aplicación proteger su infraestructura, independiente del entorno.

Mientras que el perímetro de seguridad tradicional busca establece un perímetro alrededor de las aplicaciones y sistemas, el enfoque SDP es establecer un perímetro alrededor del usuario. De esta manera, tenemos un perímetro dinámico, que refleja el tipo de entorno cambiante utilizado actualmente y capaz de proteger a los usuarios y aplicaciones mientras se mueven.

El concepto de SDP, entre otros:

• autenticación y validación de dispositivos

• acceso basado en identidad

• aprovisionamiento dinámico de conexiones para ocultar aplicaciones de usuarios no autorizados

Introducción al SDP

Ahora que somos conscientes del cambio de perímetro (y los principales motivadores del cambio), podemos entender por qué las herramientas y los enfoques tradicionales a la seguridad de la red no son eficientes para la protección de este nuevo entorno. Las herramientas ampliamente conocidas y usadas para la protección del perímetro tradicional, dejan las aplicaciones y la infraestructura expuesta en internet, garantizando acceso excesivo a usuario no autorizados, o poco fiables. Generando así brechas de seguridad graves y exponen nuestra infraestructura a una serie de ataques de red.

SDP (Software define perímetro) es un nuevo concepto de perímetro definido de software, que permite al propietario de la aplicación proteger su infraestructura, independiente del entorno. La iniciativa de investigar el concepto de perímetro definido de Software fue lanzada en 2013, por CSA Cloud Security Alliance, con el objetivo de encontrar una manera eficaz bloquear los ataques de red a la infraestructura de aplicaciones. El modelo SDP utiliza como base el concepto originario en la Defense Information Systems Agency (DISA), donde se hacen las conexiones de red y acceso usando el principio de “need-to-know”, La CSA define el SDP como “on-demand, dynamically-provisioned, air gapped networks”.

Los componentes utilizados en el SDP son viejos conocidos, la gran innovación es como se han integrado y desplegado. Hasta hoy, el acceso a un medio entorno fue: conectar -> identificar -> autorizar. Con la implementación de la SDP es ahora: identificar >> autorizar >> conectar. El modelo SDP esconde la infraestructura, dejando las aplicaciones invisibles para todos los usuarios. Después de que el usuario está autenticado, o dispositivo validado, y ambos autorizados se crea un túnel dinámico entre el usuario y la aplicación.

A lo largo de la investigación y el desarrollo de un prototipo para validar el concepto, el modelo SDP demostró ser eficaz para detener todas las formas de ataque de red, incluyendo DDoS, Man in the Middle, Sever Query y Advanced Persistent Threat (APT).

El concepto de SDP está tomando una envergadura cada vez mayor y llamando mucho la atención en los últimos meses, siendo citado por Gartner:

"Hasta el final de 2017, por lo menos el 10% de organizaciones empresariales (hasta de menos de 1% hoy) aprovechará la tecnología del perímetro definido por software (SDP) para aislar ambientes sensibles."

También podemos el mismo en la última presentación de Kirk House: Global Director, Enterprise Architecture - The Coca Cola Company llamada “Re-Think Security”

Los 100 riesgos en la gestión de proyectos

Riesgos en la gestión de proyectos

Este es uno de los temas muy interesantes donde todos los profesionales opinan sobre el mismo.

Pregúntele a los ejecutivos, gerentes funcionales, gerentes de proyecto e ingenieros el riesgo del proyecto. Usted encontrará varias preguntas y quejas.

La falta de compromiso de los actores está generalmente en la parte superior de la lista.

Viene a menudo seguido por mala toma de requerimientos, requisitos cambiantes, gerentes ineficientes y recursos inadecuados del proyecto. En otras palabras, identificación de riesgos tiende a traer una abundancia de emociones negativas y sugerir "culpables".

Todo esto te hace perder el valor real de la gestión del riesgo del proyecto. Cualquier buen proyecto tiene mucho riesgo. Después de todo, la naturaleza de los negocios es tomar riesgos.

Gestión de riesgos se basa en cómo maximizar sus posibilidades de tener éxito en el proyecto, identificación de riesgos en el proyecto y planificando cómo gestionarlos a través del proyecto. Los ejemplos a seguir les ayudarán a empezar en el camino a la identificación de estos riesgos.

Ahora, vamos a ver los ejemplos de los 100 riesgo en la gestión de proyectos:

Apoyo Ejecutivo

1. los directivos no apoyan el proyecto. El equipo del proyecto puede no tener la autoridad para lograr los objetivos del proyecto. En tales casos, el apoyo ejecutivo es fundamental para el éxito del proyecto.

2. Los ejecutivos pierden el interés en el proyecto y así comienzan a ignorar las comunicaciones del proyecto y reuniones.

3. conflictos entre los actores del proyecto perturba a los miembros de la Junta Directiva o hay un desacuerdo sobre los problemas del proyecto a nivel ejecutivo.

4. Un ejecutivo clave abandona la empresa, esa desvinculación se convierte en un gran problema para el proyecto.

Alcance

5. El scope de aplicación no está bien definido. En general, el riesgo proviene de un error u omisión en el momento de la definición del alcance.

6. Los cambios no son controlados y el alcance está en continuo crecimiento.

7. El equipo del proyecto añade sus propias características al producto y estas características no son requerimientos o solicitudes de cambio.

8. Estimaciones inexactas es un riesgo común en realidad el proyecto.

9. Puede afectar drásticamente la programación del proyecto y también los costes.

10. faltan actividades necesarias en la definición del alcance.

Gestión de costos

11. Las estimaciones y pronósticos de costo son inexactos.

12. variaciones en el tipo de cambio pueden tener un impacto importante en el proyecto.

Gestión del cambio

13. Un gran número de solicitudes de cambio dramáticamente aumenta la complejidad del proyecto y distrae las características clave.

14. El cambio puede ser el origen del conflicto de las partes interesadas.

15. Debido a un gran número de solicitudes de cambio como de prioridades, tenemos la percepción de que el proyecto fracasó. Cuando el calendario y el presupuesto se cambian continuamente - las partes interesadas pueden sentir que el proyecto ha perdido sus objetivos originales.

16. La falta de identificación de cualquier cambio puede convertirse en un riesgo crítico.

17. La gestión del cambio a nivel de organización o departamental es fundamental para el éxito del proyecto. De lo contrario, el proyecto tendrá una visibilidad limitada en los cambios que afectan al proyecto.

18. El Control de cambio es esencial para la gestión del cambio para grandes proyectos.

19. Dónde se priorizan los cambios no esenciales, también tendremos un impacto en la ejecución de proyectos.

20. Las solicitudes de cambios que son de baja calidad (por ejemplo, ambiguas).

21. Las solicitudes de cambio que no tienen sentido en el contexto de los requisitos.

Partes interesadas

22. Cuando las partes interesadas ignoran las comunicaciones del proyecto.

23. Las partes interesadas desarrollan expectativas inexactas (creer que el proyecto va a lograr algo que no está en los requisitos, planes, etc.).

24. El volumen de negocios de las partes interesadas puede dar lugar a interrupciones del proyecto.

25. Cuando las partes interesadas tienen una actitud negativa hacia el proyecto y les gustaría ver fracasar.

26. El desacuerdo entre los interesados sobre los problemas del proyecto.

27. Las contribuciones de las partes son de baja calidad o irrelevante.

Comunicación

28. Cuando los requisitos son mal interpretados por el equipo del proyecto se producirá un desfase entre las expectativas, demandas y el trabajo en su conjunto.

29. Cuando los recursos clave del proyecto pueden gastar un alto porcentaje de su tiempo.

30. La comunicación es un desafío que no se debe subestimar. Es posible que necesite comunicar la misma idea muchas veces en diferentes formas para que la gente recuerde.

31. Los usuarios tienen expectativas inexactas.

32. Las personas afectadas no son informadas.

Equipo

33. Las debilidades de los miembros del equipo.

34. Cuando su equipo de proyecto necesita adquirir nuevas habilidades para el proyecto, existe el riesgo de que la productividad disminuya.

35. Capacitación de calidad no disponible.

36. La formación es inadecuada o no basada en experiencia profesional.

37. Los miembros del equipo que son nuevos en el mercado o en la profesión tienden a cometer más errores y ser menos productivos.

38. Problemas de rendimiento del equipo del proyecto.

39. Miembros del equipo con actitudes negativas hacia el proyecto o pasivamente sabotean cualquier esfuerzo.

40. Rotación conduce a retrasos y aumento de los costos.

41. El equipo carece de motivación. Este es un riesgo particularmente común en proyectos de larga duración.

42. Falta de compromiso de los gerentes funcionales.

Arquitectura

43. La arquitectura no pasa los procesos de gobierno.

44. La arquitectura carece de flexibilidad.

45. La arquitectura es de baja calidad.

46. La arquitectura es inviable, la arquitectura es imposible de implementar o no es compatible con los requisitos.

Proyecto

47. El proyecto no es viable. el diseño no es posible o no es compatible con los requisitos.

48. El proyecto carece de flexibilidad.

49. El diseño es de baja calidad.

50. El proyecto falla. Es una buena idea tener colegas o expertos arquitectónicos para validar sus proyectos.

Técnico

51. Los componentes técnicos no son adecuados.

52. Los componentes técnicos no son escalables.

53. Los componentes técnicos no tienen interfaces estándar.

54. Los componentes técnicos no son compatibles con las normas y violan las mejores prácticas.

55. Los componentes técnicos tienen vulnerabilidades de seguridad.

56. Los componentes técnicos está lleno de diseño y características innecesarias.

57. Los componentes técnicos no tienen estabilidad.

58. Componentes técnicos no extensible, es decir, son difíciles de ampliar con nuevas funcionalidades.

59. Los componentes técnicos no fiables, es decir que falla después de un corto período de tiempo.

60. El riesgo de incidente de seguridad durante el proyecto (por ejemplo, la información es divulgada).

61. Interrupciones del sistema de sistemas críticos, como sus entornos de prueba.

62. Componentes heredados no tienen documentación.

63. Componentes heredados están fuera de apoyo.

64. Componentes o productos no son sostenibles.

65. Componentes o productos no pueden ser operados.

66. Los problemas con las herramientas de gestión y temas de problemas técnicos con sus propias herramientas de gestión del proyecto.

Integración

67. Los retrasos en infraestructura, tales como hardware o software.

68. La imposibilidad de integrar con procesos de negocio.

69. La imposibilidad de integrar con los sistemas.

70. Los entornos de prueba e integración no están disponibles.

71. La falta de integración con la organización.

72. Incapacidad para integrar componentes.

73. El proyecto interrumpe las operaciones.

74. El proyecto interrumpe la venta.

75. El proyecto detiene procesos de cumplimiento, tales como auditorías e informes.

Requisitos

76. El no alinear los requisitos de conflicto con la estrategia de la empresa.

77. El no alinear los procesos de negocio.

78. Los requisitos no pueden alinearse con otros sistemas.

79. Los requisitos tienen problemas de cumplimiento.

80. Los requisitos son ambiguos.

81. Los requisitos no son aptos para el propósito.

82. Los requisitos son incompletos.

Decisiones y solución de problemas

83. Los proyectos en retrasos generan impacto al establecer directrices para toma de decisión.

84. Las partes interesadas pueden tener una tendencia a tomar decisiones que son intencionalmente ambigua.

85. Las decisiones no son las adecuadas para el propósito del proyecto.

86. Las decisiones incompletas crean más problemas.

Adquisición

87. No hay respuesta al RFP.

88. Respuestas al RFP que son inutilizables.

89. La falta de negociación de un precio razonable para los contratos.

90. Incapacidad para negociar condiciones contractuales aceptables.

91. Conflictos con el proveedor trae problemas al proyecto.

92. Conflicto entre proveedores conduce a una ruptura de cooperación.

93. Los vendedores tienen demoras.

94. Cuando el proveedor no es consciente de los requisitos o proporciona componentes que están completamente fuera de la marca.

95. Los componentes del proveedor son de baja calidad.

96. La infraestructura es de baja calidad.

97. La calidad del servicio es baja.

98. Componentes del proveedor introducen términos de responsabilidad civil (por ejemplo, violan patentes).

99. Pérdida de la propiedad intelectual.

Autoridad

100. La falta de autoridad en el equipo para completar el trabajo y lograr los objetivos.

Espero que les sirva como guía.