NOTA: Este artículo no es sólo para las organizaciones que ya han sido hackeadas... La IEC 62443 es una norma genérica reconocida como aplicable en sectores críticos como la fabricación, la energía, el transporte, la sanidad y muchos otros.

 

 

Este artículo es el cuarto episodio de una serie de 8, que cubre algunas de las mejores prácticas que debe implementar cualquier organización que pretenda cumplir con el Estado del Arte en Ciberseguridad para los sistemas de control industrial y de automatización. Basado en un enfoque pragmático, este artículo se centra en las conocidas actividades de ciberseguridad que se denominan pruebas de penetración. Este método de prueba es requerido por el ciclo de vida de desarrollo seguro, tal como se describe en la norma IEC 62443-4-1).

 

 

Los requisitos de verificación y validación de la seguridad a través de la norma IEC 62443-4-1 (sección 9 / SVV-X) describen cuatro tipos principales de pruebas:

 

  • SVV-1 - Pruebas de requisitos de seguridad: Las palabras clave son pruebas funcionales, rendimiento y escalabilidad, condiciones límite, tensiones, inyecciones...
  • SVV-2 - Pruebas de mitigación de amenazas: Las palabras clave son eficacia de las medidas de mitigación, cobertura del modelo de amenazas, ...
  • SVV-3 - Pruebas de vulnerabilidad: Las palabras clave son base de datos pública de vulnerabilidades, fuzzing, vulnerabilidades conocidas, violaciones de reglas de seguridad...
  • SVV-4- Pruebas de penetración: Mientras que las actividades de pruebas precedentes permiten identificar y caracterizar las vulnerabilidades conocidas y las limitaciones del sistema, las pruebas de penetración se realizan para explotar las vulnerabilidades de seguridad conocidas y desconocidas utilizando herramientas y técnicas de explotación. Las pruebas de penetración pueden utilizarse para validar las vulnerabilidades y probar la eficacia de las contramedidas. La mayor diferencia de esta actividad es la cobertura de los aspectos de viabilidad mediante la explotación de vulnerabilidades reales.

 

Este último tipo de prueba es el tema principal de este artículo y se describe con más detalle a continuación.

 

 

Pruebas de penetración - Proceso típico(basado en NIST SP 800-115)

 

Las pruebas de penetración se conocen y se realizan en casi todos los campos de aplicación. La terminología y los procesos difieren un poco de un sector a otro, pero el enfoque básico sigue siendo el mismo y puede describirse brevemente como un proceso de 4 pasos, como se indica a continuación:

 

  1. Planificación - En esta primera fase se identifican las reglas, se finaliza y documenta la aprobación de la dirección y se establecen los objetivos de las pruebas. La fase de planificación sienta las bases para una prueba de penetración exitosa. En esta fase no se realiza ninguna prueba real.
  2. Descubrimiento - En esta segunda fase se describen dos subactividades:
    • La primera parte es el inicio de las pruebas reales, y abarca la recopilación de información y el escaneo. Se lleva a cabo la identificación de puertos y servicios de la red, así como otras técnicas para identificar posibles objetivos
    • La segunda parte de la fase de descubrimiento es el análisis de vulnerabilidad, que implica la comparación de los servicios, aplicaciones y sistemas operativos de los hosts escaneados con las bases de datos de vulnerabilidad (un proceso que es automático para los escáneres de vulnerabilidad) y el propio conocimiento de los probadores sobre las vulnerabilidades.
  3. Ataque - Mientras que la fase de descubrimiento tiene como objetivo comprobar únicamente la posible existencia de una vulnerabilidad, la fase de ataque de una prueba de penetración explota la vulnerabilidad para confirmar su existencia. Existen diferentes definiciones de esta fase en la literatura, pero podemos identificar cuatro subactividades principales:
    • Obtención de acceso - Basándose en los datos que se han recopilado en la fase de descubrimiento, el probador intenta acceder al objetivo
    • Escalada de privilegios : si en el último paso sólo se ha obtenido acceso a nivel de usuario, la persona que realiza la prueba tratará ahora de obtener el control total del sistema mediante la elevación a nivel de administrador/raíz
    • Navegación por el sistema : el proceso de recopilación de información comienza de nuevo para identificar los mecanismos de acceso a otros sistemas
    • Instalar herramientas adicionales - Se despliegan materiales adicionales en el objetivo para ampliar el acceso y la perspectiva de "infectar" el entorno objetivo
  4. Presentación de informes - Esta fase se produce, por lo general, simultáneamente con las otras tres fases de la prueba de penetración. En la fase de planificación, se desarrolla el plan de la prueba. En las fases de descubrimiento y ataque, se suelen llevar registros escritos y se elaboran informes periódicos para los administradores del sistema y/o la dirección. Al final de la prueba, generalmente se elabora un informe para describir las vulnerabilidades identificadas, presentar una calificación de riesgo y dar orientación sobre cómo mitigar las debilidades descubiertas.

 

La segunda y tercera fase de este proceso son comparables a las actividades típicas realizadas por atacantes/hackers reales. La mentalidad y las habilidades técnicas ofensivas son clave para realizar una prueba de penetración eficiente.

 

 

Independencia de los probadores

 

Y por último, pero no menos importante, la independencia de los probadores es un tema clave en la norma ISA 62443-4-1, cristalizado a través de un requisito estandarizado que define el siguiente nivel de independencia por actividades de prueba:

 

 

Dónde

 

  • Persona independiente: el probador no debe ser uno de los desarrolladores del producto.
  • Departamento independiente: el probador no debe depender del mismo jefe de primera línea que los desarrolladores del producto. También podría ser miembro de un departamento de garantía de calidad (QA).
  • Organización independiente: el probador no debe formar parte de la misma organización que los desarrolladores del producto. Una organización puede ser una entidad jurídica independiente, una división de una empresa o un departamento de una empresa que depende de un ejecutivo diferente, como un vicepresidente o un nivel similar.

 

La razón por la que se ha definido este requisito relacionado con la independencia es que un probador independiente a menudo puede descubrir más defectos, otros y diferentes, que un probador que trabaja dentro de un equipo de programación, o un probador que es de profesión programador. Un probador de este tipo aporta un conjunto diferente de supuestos a las pruebas y a las revisiones, lo que a menudo ayuda a exponer los defectos y problemas ocultos, con total transparencia y honestidad.

 

 

Conclusión:

Lamentablemente, la mayoría de las veces la ciberseguridad no está integrada "por diseño", lo que probablemente implica que hay múltiples debilidades y vulnerabilidades presentes en el entorno de un producto/sistema. En ese contexto, muchas organizaciones piensan que la realización de una prueba de penetración permitiría identificar todas las brechas de seguridad para ser simplemente mitigadas después y... eso es todo. Lamentablemente, las pruebas de penetración no deben considerarse como soluciones a prueba de balas.

Por supuesto, las pruebas de penetración son siempre consideradas como buenas prácticas, e incluso un requisito de la norma IEC 62443, para evaluar la viabilidad de las posibles amenazas contra un sistema, pero definitivamente no debe considerarse como la única solución para la identificación y caracterización de la vulnerabilidad. Sea proactivo en lugar de reactivo con respecto a sus ciberamenazas.

 

Incluso si el cumplimiento de la norma 62443 no es un objetivo final, las pruebas de seguridad deben ser consideradas como una de las principales actividades que deben ser implementadas y manejadas por la organización para garantizar una cierta confianza en un determinado ciclo de vida de desarrollo.

 

Si tiene alguna pregunta sobre las pruebas de seguridad, verificación y validación y/o cualquier otro criterio de certificación, no dude en ponerse en contacto con nuestro especialista en ciberseguridad: Kilian Marty