Impacto de la seguridad en los sistemas de pruebas automatizadas

Imagínese en este escenario tan familiar para aquellos en la industria de fabricación. Su teléfono suena a las 2:15 a.m., y lo despierta con sobresalto. En la conversación recibe noticias de un evento que requiere su atención urgente.

La línea de producción C se detuvo en medio de una ejecución debido a la falla de dos controladores lógicos programables (PLC) utilizados en el sistema de pruebas de producción de fin de línea para garantizar la calidad del producto. El centro de control de fabricación perdió la comunicación con los PLCs hace 30 minutos y no puede determinar si ahora están en un estado confiable para volver a ponerlos en línea. Tres de estos incidentes ya han ocurrido este mes, ¿y ahora un cuarto? Esta vez, sin embargo, su equipo de fabricación estaba preparado y está trasladando la producción a una instalación contigua con capacidad suficiente. Con esperanza, esto ayudará a reducir las pérdidas netas de producción.

Días después se descubrió, estas fallas fueron el resultado de un incidente de ciberseguridad. Pero más que un ataque externo, fue un caso de fuego amigo. El departamento de TI implementó recientemente escaneos nocturnos en todos los dispositivos en red para evaluar su seguridad; los equipos de prueba solían estar exentos de la mayoría del protocolo de TI, pero los lideres ejecutivos cambiaron esta política porque ya no podían tolerar los riesgos de ciberseguridad de los dispositivos de red no monitoreados. Debido a los algoritmos de software rudimentarios en el PLC que probablemente fueron desarrollados décadas antes de que existiera el software de seguridad, los escaneos de seguridad nocturnos abrumaron a los dos PLCs con más paquetes de red de los que podían manejar y desencadenaron una respuesta de falla: apagado.

Los problemas clave

La tendencia de aplicar prácticas de seguridad de TI a los sistemas de pruebas tiene sentido por varias razones, más notablemente el aumento de incidentes de ciberseguridad que explotan dispositivos de red no monitoreados. Ningún CEO quiere estar en la posición del CEO de Target, cuyos sistemas de punto de venta se vieron comprometidos por un ataque que se originó a través de los controladores del sistema de calefacción y ventilación. De manera similar, ningún ejecutivo puede soportar el impacto económico de grandes pérdidas de producción en caso de que los equipos de pruebas sean atacados a través de los sistemas de TI corporativos.

Otra razón por la que esta tendencia tiene sentido es que las prácticas de seguridad y la tecnología para sistemas de TI de uso general son más maduras. Para proteger los sistemas y detectar las amenazas, el personal de seguridad de TI tiene una variedad de opciones, desde escáneres de descubrimiento de red y tecnología de detección de intrusos hasta antivirus de escritorio y agentes de monitoreo. La respuesta natural es extender la cobertura de estas prácticas recomendadas y tecnologías de seguridad a sistemas y dispositivos de pruebas para fines especiales, sobretodo cuando esas prácticas se utilizan para cumplir con un estándar regulado como NIST SP 800-171.

Sin embargo, esta tendencia no tiene sentido categóricamente por al menos dos razones. Principalmente, los sistemas de pruebas habilitados por TI son menos tolerantes incluso con pequeños cambios de configuración. Los usuarios de sistemas de TI pueden tolerar el tiempo de inactividad y es posible que ni siquiera perciban las diferencias en el rendimiento de la aplicación, pero los sistemas de pruebas para fines especiales (especialmente los que se utilizan en producción) muchas veces no pueden tolerarlos. Incluso los pequeños cambios en las características de rendimiento debido a un parche de seguridad o una nueva característica de seguridad pueden afectar negativamente los resultados de las pruebas o incluso la calidad de los datos recopilados de las pruebas. De manera similar, incluso pequeñas cantidades de tiempo de inactividad en los sistemas de pruebas de producción pueden tener un impacto financiero significativo en las ganancias de una organización.

En segundo lugar, los sistemas de pruebas a menudo tienen necesidades de seguridad que son únicas. Por lo general, ejecutan software de pruebas especializado que no se usa en otras PCs de la organización, y están equipados con periféricos de propósito especial no abordados por tecnologías de seguridad de TI estándares. Por ejemplo, los periféricos de pruebas que requieren calibración para proporcionar medidas precisas pueden degradar o incluso deteriorar la calidad de las pruebas si sus datos de calibración se alteran de manera maliciosa o inadvertida. Aplicar a ciegas las prácticas de seguridad de TI a estos sistemas de pruebas puede resultar en una falsa sensación de seguridad simplemente porque no abordan los riesgos únicos de ciberseguridad de estos sistemas de pruebas.

Qué puede hacer 

El enfoque preferido para los equipos de pruebas de seguridad implica dos componentes clave. Primero, utilice los datos para informar qué medidas de seguridad de TI adopta para su sistema de pruebas y cuán extensivamente las aplica. Esto lo equipa con la información necesaria para involucrar al personal de seguridad de TI para evaluar y administrar el riesgo. En segundo lugar, complemente esas medidas de seguridad de TI con características de seguridad específicas del sistema de pruebas para que pueda abordar riesgos únicos. Esto llena los vacíos restantes que las prácticas de seguridad de TI estándares no pueden resolver.

Puede consultar el informe anual Verizon Data Breach Investigations Report (DBIR) como fuente de datos. En este informe, Verizon analiza los datos recopilados sobre las violaciones de ciberseguridad divulgadas durante el año calendario anterior. Una parte del DBIR de Verizon 2016 contiene un análisis de los ciberataques activos que aprovecharon las vulnerabilidades parcheadas por los principales proveedores de software. Los hackers utilizan una técnica que aprovecha el tiempo de desfase entre la publicación de un parche por parte de un proveedor y la instalación del parche en una PC. Al compilar de forma inversa el parche del proveedor para descubrir dónde está la vulnerabilidad en el software sin parche, el hacker utiliza un exploit para aprovechar esa vulnerabilidad. Los hackers comienzan la explotación de forma activa en un plazo de dos a siete días calendario después de la publicación de un parche, enfocándose en gran medida en los principales proveedores de software.

Usted puede utilizar estos datos para tomar decisiones de riesgo más precisas sobre la aplicación de parches a sus sistemas de pruebas. Para reducir su riesgo, primero instale los parches de seguridad dentro de los siete días posteriores a su publicación. Esto significa que usted debe monitorear las notificaciones de los proveedores 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 pruebas. El tiempo inicial invertido en hacerlo se compensará rápidamente en menores costos de parches y recalificación. Estos pasos son especialmente importantes para los sistemas de pruebas de mayor riesgo, como aquellos utilizados en fabricación o producción.

El segundo componente clave implica el uso de funciones de seguridad específicas del proveedor. Por ejemplo, dado lo cruciales que son los datos de calibración, los parámetros y las secuencias de las pruebas para mantener la calidad de las pruebas, usted puede utilizar tecnologías como el monitoreo de la integridad de archivos y la integridad de la calibración, configuradas específicamente para su sistema de pruebas y sus componentes. De manera similar, usted puede consultar la documentación de seguridad de los proveedores de su sistema de pruebas para encaminar sus decisiones de compra, diseño e implementación de su sistema de pruebas hacia opciones que brinden una mejor seguridad.

Preguntas que debe hacerle a su proveedor de sistemas de pruebas

Qué tan compatible es su software con las características de seguridad del sistema operativo Windows?

NI prueba la compatibilidad de su software con características de seguridad de Windows para que pueda habilitarlas según sea necesario en su entorno. Puede ejecutar todo el software de aplicación de NI con privilegios de usuario estándares.

¿Puedo eliminar con seguridad el componente de software "X" para reducir mi riesgo de seguridad?

Con los instaladores de software de NI, usted puede personalizar la instalación para que pueda instalar solo los productos que necesita y asegurarse de que tiene todas las dependencias necesarias. Además, las aplicaciones de NI le brindan la habilidad de crear sus propios instaladores personalizados para que pueda implementar su aplicación con el entorno de ejecución y las dependencias mínimas.

¿Qué otras medidas de seguridad puedo usar para proteger el software de pruebas y mis aplicaciones de pruebas?

Puede encontrar herramientas de monitoreo de integridad de archivos en el mercado. Actualmente, NI está evaluando este tipo de herramientas para determinar cómo deben configurarse para funcionar con el software de NI. Contacte a NI para detalles.

¿Dónde puedo encontrar información de seguridad para software y hardware?

NI proporciona documentación sobre puertos y protocolos de red, servicios de Windows, limpieza de memoria y actualizaciones críticas de seguridad.

Las noticias de software malicioso (malware) dirigido a los sistemas de control industrial llegaron con una sorpresa en 2014. Este no fue el trabajo de los hackers que penetraron remotamente las defensas de una fábrica en particular o de operativos encubiertos que instalan malware en una refinería. En cambio, el malware se había instalado a través del software del proveedor que contenía un troyano.

La campaña se denominó originalmente "Energetic Bear" porque estaba dirigida a plantas de energía eléctrica y se pensaba que se había originado en Rusia. Un aspecto de la campaña involucró a la cadena de suministro. Atacaron a tres proveedores de software diferentes cuyos sitios web tenían su software del sistema de control industrial disponible para descarga del cliente. Cuando los hackers tuvieron acceso a los archivos en el sitio web, alteraron el instalador de software legítimo del proveedor, insertando una pieza de malware en él y luego guardaron el archivo en su ubicación original en el sitio web. Era solo cuestión de tiempo antes de que los clientes descargaran el software troyano y lo instalaran. El impacto económico tanto en los proveedores de software como en sus clientes es desconocido.

En un caso más sofisticado, Kaspersky Labs descubrió una amenaza en la cadena de suministro de los discos duros comerciales de varios proveedores en 2010 que se remontaba al 2005. Lo que encontraron fue un firmware embebido en los controladores del disco duro que parecía operar el disco duro con normalidad. Sin embargo, almacenó en secreto una copia de lo que consideraba información confidencial en áreas no utilizadas de la memoria no volátil que contiene el firmware. Debido a que el firmware alterado no tenía capacidad de comunicación externa, usted podría concluir que un operativo recolectaría el disco duro después de haber sido dado de baja para recuperar la información confidencial. Tenga en cuenta que la información confidencial se podría recuperar incluso si el contenido del disco duro se fuera desinfectado antes de desecharlo.

Los problemas clave

La amenaza del sitio web de la campaña Energetic Bear indica que la integridad de un sistema de pruebas (o cualquier sistema) se basa en la integridad de sus componentes a lo largo de su ciclo de vida. Cada lugar donde los componentes cambian de mano y cada lugar donde los componentes están estancados durante un período prolongado de tiempo representa una oportunidad de riesgo. Establecer una cadena de custodia clara es vital, e igualmente vitales son las medidas de seguridad para proteger y detectar un componente comprometido en cada etapa.

El descubrimiento del disco duro de Kaspersky comprometido indica que los sofisticados hackers de todo el mundo están dispuestos a entrar en el proceso de desarrollo de un proveedor para acceder al código fuente no publicado del proveedor. En este caso, el código fuente del proveedor robado se utilizó para crear variantes completamente instalables y funcionales que se instalaron en los discos duros comprometidos mucho después de que los discos duros se hubieran comprado y puesto en servicio.

Ningún aspecto de un producto es inmune a un riesgo en la cadena de suministro. Cualquier instalador, incluso para plugins o add-ons aparentemente insignificantes, podría haberse visto comprometido por la campaña Energetic Bear. Lo mismo era cierto para el firmware aparentemente insignificante en los controladores del disco duro que permitían actualizaciones en campo sin fuertes controles de seguridad.

Usted debe comprender las limitantes 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 de comprometer todo el sistema debido a un componente comprometido de un proveedor, pero por lo general, esta ventaja se ve superada por los costos de sustentabilidad para capacitar al personal en múltiples tipos de equipos y administrar todas las relaciones con los proveedores. La estandarización reduce estos costos de sustentabilidad pero conlleva un mayor riesgo de una amenaza en todo el sistema.

Qué puede hacer 

La estandarización tiene tantos beneficios en los costos que es difícil justificar la diversidad de proveedores, excepto en escenarios de alto riesgo. El enfoque más factible implica la estandarización del proveedor, donde una evaluación de la seguridad de la cadena de suministro del proveedor es una parte importante de los criterios en la toma de decisiones.

La mayoría ya tiene proveedores en los que se han estandarizado. En este caso, tanto usted como el proveedor tienen un interés personal en mantener la relación. Lo más importante que usted puede hacer para abordar la seguridad de la cadena de suministro es hablar con sus proveedores. Pregúnteles acerca de sus cadenas de suministro y qué hacen para proteger la integridad de sus productos a lo largo de sus procesos de desarrollo, fabricación y cumplimiento de pedidos. Tener información sobre cualquier debilidad en sus procesos puede ayudar a reducir su riesgo de amenaza en la cadena de suministro y ayudar a sus proveedores a reforzar su seguridad. Sin ese diálogo, ambas partes están sujetas a tomar decisiones desinformadas.

Además de la prevención, asegúrese de que el diálogo con sus proveedores incluya maneras de detectar cuándo se ha producido una amenaza. Cualquier sistema de seguridad puede verse comprometido si hay suficiente motivación y recursos. Asegúrese de que haya suficientes comprobaciones en el sistema para detectar cuándo se ha producido una amenaza y que haya instrucciones claras sobre cómo responder. En un caso como la amenaza del sitio web de Energetic Bear, el mecanismo de detección de la "última etapa" podría ser una verificación de la firma digital del instalador, pero ese mecanismo de detección debe combinarse con los procedimientos y la capacitación adecuados que den como resultado una instalación abortada y una mesa de ayuda billete. En un caso como el del firmware del disco duro comprometido, una consulta sobre el diseño de actualización del firmware del proveedor revelaría una brecha de protección sin manera de verificar la integridad del firmware instalado.

Preguntas que debe hacerle a su proveedor de sistemas de pruebas

¿Cómo puedo verificar que el software que recibo es legítimo?

NI firma digitalmente todos sus instaladores de software de Windows para que usted (y Windows) pueda verificar que es de NI y que no está alterado. Además, NI ofrece una solución de entrega segura de software que agrega seguridad física a la entrega del software. La entrega segura del software proporciona un paquete a prueba de alteraciones y un envío rastreable del software de NI en discos ópticos, además de un disco de validación enviado de forma independiente para verificar la integridad del archivo del software en el otro paquete.

¿Cómo protege su cadena de suministro de piezas falsificadas y componentes alterados?

NI sigue prácticas rigurosas de calidad con respecto a dónde obtiene las piezas y cómo ensambla el producto final. NI realiza verificaciones de antecedentes del personal involucrado en la fabricación y las pruebas, y tiene numerosos controles para garantizar que reciba un producto de alta calidad. Contacte a NI para más detalles.

¿Cómo puedo verificar que nadie haya alterado los datos de calibración de mi hardware?

Los módulos de hardware de NI requieren una contraseña para realizar cambios en los datos de calibración a largo plazo. Administre esta contraseña con la misma diligencia que aplica a su contraseña de Windows. NI está desarrollando actualmente una característica de integridad de calibración para determinados módulos de hardware. Esta característica le daría a usted la capacidad de verificar que los datos de calibración a largo plazo no hayan cambiado desde su calibración certificada.

¿Cómo soportan sus productos la diversificación del proveedor?

NI cumple con los estándares de la industria siempre que sea posible para proporcionar la más amplia interoperabilidad con productos de otros proveedores. Por ejemplo, los productos de NI cumplen con los estándares de comunicación PCI, PXI, IEEE, IETF e ISO/IEC y utilizan tecnologías estándares en la industria como IVI y OPC-UA. NI también participa en muchos de estos comités de estándares.

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 una mayor atención a la amenaza interna. Sus acciones han resultado en pérdidas económicas estimadas entre $ 22 y $ 35 mil millones para la industria de la tecnología de EE. UU. debido a la desconfianza resultante en la tecnología de EE. UU. Pero no es el primer caso de amenaza interna.

Timothy Lloyd de Omega Engineering obtuvo muy mala fama por el mal uso de información confidencial en 1996. El estado de la tecnología era Microsoft Windows 95, y la ciberseguridad rara vez (si es que alguna vez) se discutía en los medios de comunicación tradicionales. Lo que Timothy Lloyd pudo lograr como informante privilegiado fue asombroso para esa época. Trabajó en el sitio de fabricación como administrador de sistemas. Cuando se enteró de que lo despedirían, instaló una bomba de tiempo de software que eliminó sistemáticamente todo el software de fabricación de los sistemas bajo su control. La bomba de tiempo se activó cuando el primer administrador se conectó a 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 llevó a la compañía a la bancarrota.

Los problemas clave

Los temas clave en esta área son multifacéticos y siguen siendo un tema importante de investigación. Los problemas incluyen la atención a cualquier persona que tenga acceso a sistemas de pruebas críticos, independientemente de su condición de empleados o contratistas. Implican una clara identificación de los aspectos más críticos del negocio y las personas que tienen un papel en esos aspectos y cómo se distribuye la autoridad entre ellos. Las soluciones generalmente involucran un grado significativo de monitoreo del comportamiento, que puede afectar negativamente la confianza interpersonal necesaria para la eficiencia operativa.

Las amenazas internas son eventos de baja probabilidad pero de alto impacto, una afirmación que soporta el Verizon DBIR 2016. De los más de 64,000 incidentes de ciberseguridad en 2015, únicamente 172 involucraron un mal uso de los privilegios por parte de un miembro interno. Más del 75% de los incidentes de amenaza interna se realizaron solos sin ninguna ayuda externa o confabulación con otra persona interna.

Qué puede hacer

A excepción de los sistemas de altamente críticos, es mejor abordar la amenaza interna después de haber abordado los conceptos básicos descritos en las tendencias anteriores. Esas otras tendencias hablan de las formas más probables en que sus sistemas de pruebas pueden verse comprometidos.

Sin embargo, para sistemas altamente críticos, aborde la amenaza interna lo antes posible en el proceso de diseño. Una vez que haya identificado los aspectos más sensibles o críticos del sistema, diseñe una solución de administración privilegiada que separe las tareas en al menos dos roles que una sola persona no pueda desempeñar y evite cualquier intento de asignar ambos deberes a un solo rol. Eso mueve las probabilidades a su favor del segmento del 77% actuado solo al segmento del ocho% que tuvo que confabular, según los datos de Verizon DBIR.

Preguntas que debe hacerle a su proveedor de sistemas de pruebas 

¿Cómo protege internamente el código fuente de su software?

NI implementa numerosas capas de protección a su código fuente de software: NI requiere nombres de usuario y contraseñas únicos para realizar cambios, limita el acceso de la compañía solo a los grupos de ingeniería involucrados en el desarrollo y revisa periódicamente las listas de control de acceso. Los grupos de ingeniería eligen restringir los cambios de código a los miembros de la lista de control de acceso o permitir que los no miembros envíen cambios de código. Para los grupos que permiten cambios en el código a los no miembros, NI requiere notificaciones de dichos cambios en el código fuente y una revisión del código por parte de un miembro del grupo.

Abordar las necesidades de ciberseguridad de un sistema de pruebas es asunto complejo. Puede estar lleno de una cantidad infinita de potenciales riesgos de seguridad o nunca comenzar porque parece abrumador. Siendo realistas, la seguridad perfecta es inalcanzable porque, en teoría, cada solución puede verse comprometida con suficientes recursos y tiempo. En lugar de cualquiera de los extremos, comience priorizando los problemas basados en escenarios realistas y aborde primero los problemas más importantes, aplicando el sentido común a lo largo del camino.

Comience por construir una opinión entre las personas involucradas (por ejemplo, su gerencia, 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 el beneficio de despertar conciencia en todo el personal relevante sobre la naturaleza de las amenazas de ciberseguridad y el posible impacto negativo de los incidentes de seguridad en su éxito mutuo. Después, asignar tiempo y dinero específicamente para proyectos de ciberseguridad, capacitación y tecnología. Debido a que las amenazas de ciberseguridad a los sistemas de pruebas son reales y representan un riesgo financiero para su organización, una asignación de los recursos de la organización debe dedicarse a evaluar y abordar las necesidades de ciberseguridad. Después de una evaluación realista de cómo las amenazas de ciberseguridad pueden afectar sus operaciones, asigne una cantidad proporcional de sus recursos a cubrir esas necesidades.

• Aprenda más sobre la seguridad de NI 
• Lea más sobre las prácticas recomendadas para crear un sistema de pruebas 
• Configure su sistema de pruebas