Inicio Instrumentación Impacto de las tendencias de seguridad en los equipos de prueba

Impacto de las tendencias de seguridad en los equipos de prueba

Resumen

A medida que las organizaciones buscan apuntalar sus defensas contra amenazas de ciberseguridad, los sistemas de pruebas específicos presentan retos únicos. Un sistema de prueba amenazado puede tener un impacto significativo en los ingresos y en la reputación de una organización, por lo que es razonable tomar medidas para reducir ese riesgo empresarial.

No obstante, el riesgo es representar los modos en que los sistemas de prueba difieren de los sistemas de TI tradicionales. En este documento examina las tendencias de ciberseguridad del sector que están relacionadas con los sistemas de prueba. Vea ejemplos del mundo real que resaltan problemas importantes y aprenda pasos prácticos que puede dar para solucionar esos problemas. Averigüe también cómo NI, proveedor líder de hardware y software de medidas y pruebas, soluciona problemas de seguridad.

Tendencia 1: Aplicación de seguridad de TI a sistemas de prueba

Imagínese en este escenario muy conocido para los del sector de fabricación. Su teléfono suena a las 2:15 a.m. y se despierta de un sobresalto. La siguiente conversación presenta noticias de un evento que requiere atención urgente. La línea de producción C se detuvo en medio de un proceso por el fallo de dos controladores lógicos programables (PLC) utilizados en el sistema de pruebas de producción de final de línea para garantizar la calidad del producto. El centro de control de fabricación perdió la comunicación con los PLC hace 30 minutos y no se puede determinar si ahora se encuentran en un estado fiable para reanudarlos en línea. Tres de estos incidentes ya han sucedido este mes, ¿y ahora un cuarto? Sin embargo, esta vez su equipo de fabricación estaba preparado y está cambiando la producción a una instalación adyacente con capacidad sobrada.

Con suerte esto ayudará a reducir las pérdidas netas de producción. Como se descubrió días después, estos fallos se debieron al resultado de un incidente de ciberseguridad. Pero más que un ataque externo, fue el caso de un fuego amigo. El departamento de TI recientemente implementó inspecciones nocturnas en todos los dispositivos de red para evaluar su seguridad. El equipo de pruebas solía estar exento de la mayoría de los protocolos de TI, pero el gerente cambió esta política, porque ya no podían tolerar más los riesgos de ciberseguridad de dispositivos de red sin controlar. Debido a los algoritmos de software rudimentario del PLC que seguramente se crearon décadas antes de que existiera el software de seguridad, las inspecciones nocturnas de seguridad cargaron a los dos PLC con más paquetes de red de los que podían gestionar y provocaron una respuesta de fallo: parada.

Las cuestiones clave

La tendencia de aplicar prácticas de seguridad de TI a los sistemas de prueba tiene sentido por varios motivos, especialmente el aumento de incidentes de ciberseguridad que afectan a dispositivos de red sin controlar. Ningún director general desea estar en el lugar del director general en cuestión, cuyos sistemas se vieron afectados por un ataque que se originó por los controladores del sistema de ventilación y calefacción. Igualmente, ningún ejecutivo puede asimilar el impacto económico de grandes pérdidas de producción si el equipo de pruebas recibe el ataque mediante sistemas de TI corporativos. La segunda razón por la que esta tendencia tiene sentido es que la tecnología y las prácticas de seguridad para sistemas de TI generales son más maduras. Para proteger los sistemas y detectar peligro, el personal de seguridad de TI dispone de varias opciones, desde los exploradores de descubrimiento de red y tecnología de detección de intrusiones hasta los agentes de monitorización y antivirus de sobremesa. La respuesta natural es ampliar la cobertura de estas tecnologías y prácticas recomendadas de seguridad para dispositivos y sistema de pruebas especiales, en concreto cuando dichas prácticas se utilizan para cumplir una norma regulada como NIST SP 800-171. Sin embargo, esta tendencia no tiene ningún sentido por al menos dos motivos.

En primer lugar, los sistemas de prueba con TI son menos tolerantes a cambios de configuración incluso mínimos. Los usuarios de sistemas de TI pueden tolerar el tiempo de inactividad y quizá ni perciban diferencias de rendimiento en la aplicación, pero los sistemas de prueba especiales (concretamente los que se utilizan en la producción) no suelen tolerarlos. Incluso los pequeños cambios en las características del rendimiento por un parche de seguridad o una nueva función de seguridad pueden afectar negativamente a los resultados de las pruebas o incluso a la calidad de los datos de prueba recopilados. Del mismo modo, incluso los pequeños tiempos de inactividad en los sistemas de prueba de producción pueden tener un impacto financiero significativo en los ingresos de una organización. En segundo lugar, los sistemas suelen tener necesidades de seguri dad únicas. Normalmente ejecutan software de prueba especializado que no se utiliza en otros ordenadores de organizaciones y están equipados con periféricos generales no reconocidos por tecnologías de seguridad de TI estándar. Por ejemplo, los periféricos de pruebas que requieren calibración para proporcionar medidas precisas pueden degradarse o incluso minar la calidad de la prueba si se alteran sus datos de calibración por malicia o por accidente. Aplicar a ciegas prácticas de seguridad de TI a estos sistemas de prueba puede producir una falsa sensación de seguridad, simplemente porque no solucionan los riesgos únicos de ciberseguridad de estos sistemas de prueba.

Lo que puede hacer

La técnica preferida para los equipos de pruebas de seguridad conlleva dos componentes importantes. En primer lugar, datos para informar de qué medidas de seguridad de TI adopta para su sistema de pruebas y cómo aplicarlas de forma extensiva. Esto le brinda la información necesaria para contratar a personal de seguridad de TI que evalúe y gestione el riesgo. En segundo lugar, complemente esas medidas de seguridad de TI con funciones de seguridad específicas del sistema de pruebas para poder solucionar riesgos únicos. Así se rellenan los huecos restantes que las prácticas estándar de seguridad de TI no pueden abordar. Puede hacer referencia al Informe anual de investigación de filtración de datos (DBIR) de Verizon como fuente de datos. Verizon analiza en este informe los datos recopilados sobre las violaciones de ciberseguridad reveladas el año natural anterior.

Una parte del DBIR de Verizon de 2016 contiene un análisis de los ciberataques activos que se cebaron con las vulnerabilidades parcheadas por los principales proveedores de software. Los piratas informáticos utilizan una técnica que aprovecha el tiempo que transcurre entre la comercialización del parche de un proveedor y la instalación del parche en un ordenador. Al realizar la compilación inversa del parche del proveedor para descubrir dónde se encuentra la vulnerabilidad en el software sin parchear, el pirata convierte en un arma una proeza para jugar con esa vulnerabilidad. Los piratas empiezan de forma activa la explotación de dos a siete días naturales antes de la comercialización del parche, centrándose sobre todo en los principales proveedores de software. Puede utilizar estos datos para tomar decisiones de riesgos más precisas sobre la instalación de parches en sus sistemas de pruebas. Para reducir su riesgo, primero instale parches de seguridad en menos de siete días de su comercialización. Esto significa que debe controlar las notificaciones del proveedor de software, evaluar la aplicabilidad del parche y recalificar rápidamente los sistemas afectados.

En segundo lugar, minimice el software instalado en sus sistemas de prueba. El tiempo de preparación que le dedique compensará rápidamente al disminuir los costes de recalificación y de parches. Estos pasos son especialmente importantes para sistemas de prueba con mayor riesgo como los que se utilizan para fabricación o producción. El segundo componente clave es utilizar funciones de seguridad específicas del proveedor. Por ejemplo, visto lo cruciales que son los datos de calibración, parámetros de pruebas y secuencias de prue bas para mantener la calidad de la prueba, puede utilizar tecnologías como control de integridad de archivos y funciones de integridad de calibración que están configuradas específicamente para su sistema de prueba y sus componentes. Del mismo modo, puede hacer referencia a documentación de seguridad de sus proveedores de sistemas de prueba para guiar sus decisiones de compra, diseño y despliegue de sistemas de pruebas hacia opciones que ofrezcan más seguridad.


Tendencia 2: Peligro en la cadena de suministro

A todos nos sorpendieron las noticias de software malicioso (malware) que atacó sistemas de control industrial en 2014. Esto no fue obra de piratas que penetraban de forma remota las defensas de una fábrica concreta ni operativos encubiertos que instalaban malware en una refinería. Más bien era malware instalado a través del software del proveedor que contenía un troyano. La campaña se denominó originalmente “Energetic Bear” porque atacaba centrales eléctricas y se pensó que se originó en Rusia. Un aspecto de la campaña afectaba a la cadena de suministro. Atacaban a tres proveedores de software cuyos sitios web tenían su software del sistema de control industrial disponible para que lo descargara el cliente. Cuando los piratas habían accedido a los archivos del sitio web, alteraban el instalador de software del proveedor legítimo insertando un malware y después guardaban el archivo en su lugar original del sitio web.

Solo era cuestión de tiempo que los clientes descargaran el software con el troyano y lo instalaran. Se desconoce el impacto económico para los proveedores de software y sus clientes. En un caso más sofisticado, Kaspersky Labs descubrió un acuerdo de cadena de suministro de discos duros comerciales de varios proveedores en 2010 que se remontaba ya a 2005. Lo que encontraron era firmware embebido en los controladores del disco duro que parecía operar el disco duro con normalidad. Sin embargo, guardaba secretamente una copia de lo que se consideró información sensible en zonas sin usar de la memoria no volátil que contenía el firmware. Como el firmware alterado no tenía capacidad de comunicación externa, podía concluir que un operativo recogería el disco duro una vez decomisado para recuperar la información sensible. Tenga en cuenta que la información sensible se podría recuperar, aunque el contenido del disco duro se hubiera saneado antes de eliminarlo.

Las cuestiones clave

El compromiso del sitio web de la campaña “Energetic Bear” indica que la integridad de un sistema de pruebas (o de cualquier sistema) depende de la integridad de sus componentes en todo su ciclo de vida. Todo lugar donde los componentes cambian de mano y toda ubicación donde los componentes permanecen paralizados durante un periodo de tiempo amplio representa un riesgo. Establecer una cadena de custodia clara es vital, así como las salvaguardas para proteger y detectar un componente en peligro en cada etapa. El descubrimiento del peligro en el disco duro de Kaspersky indica que los piratas sofisticados del mundo desean llegar al proceso de desarrollo de un proveedor para acceder al código fuente sin publicar del proveedor. En este caso, el código fuente robado del proveedor se utilizó para crear variantes totalmente inestables y funcionales que se instalaron en los discos duros en cuestión mucho después de que estos se hubieran comprado y puesto en servicio. Ningún aspecto de un producto es inmune a un peligro en la cadena de suministro.

Cualquier instalador, incluso para complementos aparentemente insignificantes, podría haber estado en peligro por la campaña Oso energético. Lo mismo se aplicaba para el firmware aparentemente insignificante de los controladores del disco duro que permitían actualizaciones de campo sin rigurosas comprobaciones de seguridad. Debe comprender las compensaciones entre la diversidad de proveedores y la estandarización al abordar el riesgo de ciberseguridad. La diversificación tiene la ventaja de reducir el riesgo en todo el sistema por el peligro de un componente del proveedor, pero esta ventaja suele pesar menos que los costes de sostenibilidad para formar a personal en varios tipos de equipos y gestionar todas las relaciones de proveedores. La estandarización reduce estos costes de sostenibilidad, pero conlleva más riesgo en todo un sistema.

Lo que puede hacer

La estandarización tiene tantos beneficios económicos que resulta difícil justificar la diversidad de proveedores excepto en casos de gran riesgo. La técnica más factible conlleva la estandarización del proveedor donde la evaluación de la seguridad de la cadena de suministros del proveedor es una parte significativa de los criterios de decisión. La mayoría ya tiene proveedores sobre los que han estandarizado. En este caso, usted y el proveedor tienen un interés particular en mantener la relación. Lo más importante que puede hacer para abordar la seguridad de la cadena de suministro es hablar con sus proveedores.

Pregúnteles por su cadena de suministros y lo que pueden hacer para proteger la integridad de sus productos durante todo su desarrollo, fabricación y procesos de consecución de pedidos. Su conocimiento de las vulnerabilidades en sus procesos puede ayudar a reducir su riesgo de peligro en la cadena de suministro y a sus proveedores a apuntalar su seguridad. Sin ese diálogo, ambas partes están sujetas a tomar decisiones no informadas. Además de la prevención, asegúrese de que el diálogo con sus proveedores incluya formas de detectar cuándo ha ocurrido un riesgo. Cualquier sistema de seguridad puede estar en peligro con suficiente motivación y recursos. Procure establecer comprobaciones suficientes en el sistema para detectar cuándo existe un peligro y que haya instrucciones claras acerca de cómo responder.

En un caso como el peligro del sitio web “Energetic Bear”, el último mecanismo de detección podría ser una comprobación de firma digital del instalador, pero ese mecanismo de detección debe complementarse con formación y procedimientos adecuados que aborten la instalación y generen una petición de atención al cliente. En un caso como el peligro del firmware del disco duro, una investigación del diseño de actualización del firmware del proveedor reveló un fallo de protección sin forma de comprobar la integridad del firmware instalado.


Tendencia 3: Atención creciente a la amenaza interna

La filtración de Edward Snowden de volúmenes de datos de vigilancia clasificados de la Agencia de Seguridad Nacional es la causa más probable de que aumente la atención en las amenazas internas. Sus acciones han provocado aproximadamente de 22 a 35 mil millones de $ en pérdidas económicas al sector tecnológico estadounidense por la desconfianza resultante en la tecnología estadounidense. Sin embargo, no se trata del primer caso de amenaza interna.

Timothy Lloyd de Omega Engineering se hizo tristemente célebre por su actividad de infiltrado en 1996. La tecnología del momento era Microsoft Windows 95 y los medios principales apenas discutían la ciberseguridad, si es que se discutía. Lo que Timothy Lloyd logró como infiltrado privilegiado fue impactante para esa época. Trabajaba en la fábrica como administrador de sistemas. Cuando supo que le iban a despedir, instaló una bomba de relojería de software que eliminaba sistemáticamente todo el software de fabricación de los sistemas bajo su control.

La bomba de relojería se activó cuando el primer administrador inició la sesión en la red el día después del despido de Lloyd. El impacto económico de este evento para Omega Engineering ascendió a varios millones de dólares y la pérdida de 80 puestos de trabajo. Casi hizo quebrar a la empresa.

Las cuestiones clave

Las cuestiones principales de esta área presentan varios aspectos y aún son un tema de investigación significativo. Las cuestiones incluyen atención a cualquiera que tenga acceso a sistemas de prueba críticos, independientemente de su estado como empleados o contratistas. Implican una identificación clara de los aspectos más críticos del negocio y de la gente que tiene una función en dichos aspectos del negocio y cómo se distribuye la autoridad entre ellos.

Las soluciones suelen conllevar un grado significativo de control de comportamiento, que puede afectar negativamente a la confianza interpersonal necesaria para la eficacia operativa. Las amenazas de infiltrados son poco probables pero causan gran impacto, una afirmación que avala el DBIR de 2016 de Verizon.

De los más de 64.000 incidentes de ciberseguridad en 2015, solo 172 supusieron un uso indebido de privilegios por parte de un infiltrado. Más del 75 por ciento de las incidencias de amenazas de infiltrados se realizaron en solitario sin ninguna ayuda externa ni conspiración interna con otro infiltrado.

Lo que puede hacer

Excepto para sistemas de gran importancia, es mejor abordar la amenaza del infiltrado una vez haya solucionado los aspectos básicos descritos en las tendencias anteriores. Esas otras tendencias hablan de las formas más probables en que pueden estar en peligro sus sistemas de prueba. Sin embargo, para sistemas de gran importancia, aborde la amenaza del infiltrado lo antes posible en el proceso de diseño. Una vez que haya identificado los aspectos más sensibles o importantes del sistema, cree un sistema de privilegios de al menos dos usuarios que no pueda ostentar un único individuo para prevenir ataques internos. Esto mejoraría sus probabilidades en un 77% según los datos de Verizon DBIR.


A dónde ir desde aquí

Resulta complejo abordar las necesidades de ciberseguridad de un sistema de pruebas. Puede enredarse en un número infinito de posibles riesgos de seguridad o no iniciarse nunca porque parece abrumador. En realidad, la seguridad perfecta no se puede alcanzar porque cada solución puede en teoría estar en peligro con suficientes recursos y tiempo. En lugar de cualquiera de los extremos, empiece por dar prioridad a los problemas basados en casos realistas y solucione las cuestiones más importantes primero, aplicando siempre el sentido común. Empiece por crear un consenso entre los implicados (por ejemplo, su gestión, equipo, personal de seguridad de TI y proveedores) de que abordar las amenazas de seguridad es importante para todos. Este punto de partida también tiene la ventaja de concienciar a todo el personal en cuestión de la naturaleza de las amenazas de ciberseguridad y el posible impacto negativo de incidencias de seguridad para su éxito mutuo. A continuación, asigne tiempo y dinero concretamente para tecnología, formación y proyectos de ciberseguridad. Dado que las amenazas de ciberseguridad para los sistemas de pruebas son reales y plantean un riesgo financiero para su organización, debe dedicarse una partida de los recursos de la organización a evaluar y satisfacer necesidades de ciberseguridad. Después de una evaluación realista de cómo pueden afectar las amenazas de ciberseguridad a sus operaciones, asigne una cantidad proporcional de sus recursos a satisfacer esas necesidades.