Poniéndose en la piel de un hacker: por qué el mainframe necesita pruebas de penetración

A veces, ponerse en la piel de un hacker es la única manera de protegerse realmente de él. Por eso, muchas organizaciones incluyen pruebas de penetración en su estrategia de ciberseguridad, y el 85 % de los profesionales de ciberseguridad afirman realizar pruebas de penetración al menos una vez al año.

Si bien las pruebas de penetración son una práctica común para los equipos de redes, no siempre se emplean en todos los sistemas, especialmente en el mainframe. De hecho, cuando Chad Rikansrud, actualmente Director de Prácticas en NetSPI, comenzó a trabajar con mainframes a principios de la década del 2000, muy pocas organizaciones se especializaban en probar tácticas adversas contra este sistema. Charlamos con Rikansrud sobre qué impedía, y sigue impidiendo, a las organizaciones invertir adecuadamente en la seguridad del mainframe, qué lo llevó a impulsar las pruebas de penetración en el mainframe y cómo es el proceso hoy en día.

Introducción de pruebas de penetración en el mainframe

Sabemos que el mainframe solo representa el 6% del gasto en TI, a pesar de que gestiona alrededor del 68% de la producción mundial para cargas de trabajo críticas. ¿Qué impide que las organizaciones inviertan en el mainframe?

Chad Rikansrud (CR): El mainframe es una plataforma enorme, costosa y potente que existe desde hace más de 50 años. Debido a su tamaño, costo y potencia, el objetivo de la mayoría de los equipos de TI es operar el sistema regularmente al 90-100% de su capacidad.

Desafortunadamente, la seguridad puede verse como la antítesis de la utilización. Como resultado, la seguridad se ve comprometida, ya que los parches no se implementan completamente por temor a causar interrupciones o a no poder iniciar la carga inicial del sistema (IPL). Además, el mito persistente de la seguridad inherente al mainframe, que tantos cuentan, disipa cualquier temor persistente de que algún día pueda verse comprometida y causar una ralentización aún mayor.

Avalar el aumento de las medidas de seguridad del mainframe puede requerir mucha concienciación. Las pruebas de penetración suelen ser lo único que despierta a la gente. Presentar a los líderes de TI y de negocios un informe de todas las formas en que usted, como hacker, podría haberlos dejado fuera de servicio es una buena manera de dar la voz de alarma antes de que sea demasiado tarde.

¿Cómo llegaste a ser pentester de mainframe?

CR: Parte de mis 20 años de carrera en una importante institución financiera incluyó la gestión de la infraestructura de mainframes. El malware y el ransomware irrumpieron en escena durante esta época. Al principio, el malware era muy rentable, pero a la vez muy complejo: encontrar una casa, entrar a robar, conseguir lo que se buscaba y salir con él antes de ser detectado o bloqueado. El ransomware eliminó muchas de esas complicaciones, facilitando más que nunca la obtención de beneficios para los delincuentes: entrar a robar, cerrar todos los armarios para que nadie pueda acceder a sus pertenencias y luego cobrar por desbloquearlas.

Tras experimentar múltiples interrupciones del mainframe no relacionadas con hackeos, me pregunté cómo sería si un ransomware lo atacara. Descubrí que el mainframe de mi organización carecía de cualidades mágicas que lo protegieran de los atacantes. Hasta entonces, habíamos tenido suerte.

Busqué a alguien que pudiera evaluar la inseguridad de nuestro mainframe, pero descubrí que pocas empresas se especializaban en tácticas adversas para mainframes. Aunque tenía amplios conocimientos de seguridad, aprender a proteger el mainframe se convirtió en mi principal prioridad. Esto me llevó a trabajar con los pocos expertos en seguridad de mainframes del sector (en aquel momento solo unos seis en todo el mundo) para desarrollar un proceso de pruebas de penetración en mainframes.

¿Cómo es una prueba de penetración típica?

CR: En resumen, las pruebas de penetración verifican la configuración actual de una organización: cómo han configurado el sistema y qué controles de seguridad están implementados.

En cuanto a la interacción con los clientes, solemos trabajar en proyectos con plazos definidos, que para un solo sistema tomarían unas dos semanas. Iniciamos una combinación de pruebas de caja negra y blanca: en la negra, el pentester actúa como un auténtico hacker externo con poco o ningún conocimiento del entorno informático; en la blanca, el pentester actúa como un desarrollador interno con pleno conocimiento del entorno.

Normalmente, empezamos con las credenciales de identidad de alguien en la red, que la mayoría de los hackers pueden obtener fácilmente. Tras obtener acceso remoto, realizamos el siguiente proceso en cada sistema:

Investigar: Investigar las cuentas conjuntas durante la mayor parte de la primera semana. Durante este tiempo, vigilamos discretamente el sistema, buscando vulnerabilidades de seguridad para explotarlas posteriormente.

• Plan: Desarrollar un plan de ataque basado en los hallazgos.
• Ataque: Esto podría incluir diversas tácticas, pero el objetivo final es aumentar los privilegios. Cuanto más alto lleguemos, mayor será nuestra capacidad de modificar el sistema, lo que tiene un impacto mayor que el simple robo de datos.
• Informe: Recopilamos nuestra lista de hallazgos, clasificamos su gravedad, los compartimos con los clientes y asesoramos sobre cómo remediarlos.
• Reevaluación: Una vez implementados los cambios, realizamos nuevas pruebas para asegurarnos de que se hayan solucionado las deficiencias existentes. Dado que el sistema cambia constantemente, recomendamos a nuestros clientes que realicen nuevas pruebas anualmente o incluso semestralmente.

Pero las pruebas de penetración por sí solas no son suficientes

Las pruebas de penetración son excelentes para cuestionar la forma en que la organización ha configurado su panorama de TI y los controles establecidos para mantener a raya a los malos, pero no cubren el código a nivel de sistema operativo en el mainframe.

Desafortunadamente, la velocidad y la innovación tienden a priorizarse sobre la seguridad, por lo que los proveedores con frecuencia introducen código que podría ser fácilmente explotado para obtener el control del mainframe. Cada vez que se introduce código nuevo en el sistema, ya sea que la organización se comunique con un nuevo proveedor o se produzca una actualización rutinaria, existe la posibilidad de que el código contenga vulnerabilidades. Al implementar análisis de vulnerabilidades automáticos y regulares, las organizaciones pueden analizar a fondo el código activo a nivel del sistema operativo para detectar si los proveedores han abierto inadvertidamente amenazas a través de vulnerabilidades de integridad. Juntos, las pruebas de penetración y el análisis de vulnerabilidades conforman una estrategia integral de seguridad para mainframes.