Critical Security Update
To help protect your systems, customers using NI driver software 2026 Q2 or earlier should visit ni.com/ni-pal-update and follow the recommended actions.
La seguridad en una aplicación de software requiere una metodología formal para incorporar una mentalidad segura a lo largo del ciclo de vida del desarrollo. Este ciclo de vida del desarrollo de software (SDLC) comienza antes de que comience el desarrollo con la preparación del equipo, la configuración de protecciones para el desarrollo del software, el seguimiento de las mejores prácticas de seguridad en el diseño del software y el soporte del software después del lanzamiento. Este documento proporciona recomendaciones para que los equipos de NI LabVIEW adopten un SDLC formal que incluya un marco de desarrollo de software seguro en sus proyectos.
Un ciclo de vida de desarrollo de software (SDLC) es una metodología formal o informal para diseñar, crear y mantener software (incluido el código integrado en hardware).
Cada equipo de software ya tiene un proceso de desarrollo, ya esté o no formalmente documentado. El desarrollo seguro intencional añade actividades a lo largo de ese proceso para reducir vulnerabilidades, mejorar la mantenibilidad y reducir el costo de solucionar problemas de seguridad. Las vulnerabilidades incluyen no solo errores causados por fallos de codificación, sino también debilidades causadas por configuraciones de seguridad incorrectas, suposiciones de confianza erróneas y análisis de riesgos desactualizados.
Cuanto antes se aborde la seguridad en el SDLC, menos esfuerzo y costo se requiere en última instancia para lograr el mismo nivel de seguridad. Este principio, conocido como "shifting left" (desplazamiento a la izquierda), es fundamental independientemente del modelo SDLC. El principio de desplazamiento a la izquierda es cierto para cualquier entorno de programación, incluido LabVIEW, un entorno de programación seguro que se puede utilizar para desarrollar aplicaciones seguras. Gran parte de la seguridad de la aplicación completada depende del SDLC adoptado por el equipo de desarrollo.
Una nota importante sobre el SDLC y el cumplimiento: La mayoría de los programas regulatorios, como la Ley Europea de Resiliencia Cibernética (CRA), la Certificación del Modelo de Madurez de Ciberseguridad de EE. UU. (CMMC), la Certificación de Ciberseguridad de Defensa del Reino Unido (DCC) y otros, requieren evidencia de que un sistema fue diseñado siguiendo prácticas seguras como las de este SDLC, pero estos programas requieren mucho más que solo un SDLC. Para más detalles, consulte la documentación de esos programas.
Esta guía se basa principalmente en los principios y prácticas definidos en NIST Special Publication 800-218, Secure Software Development Framework (SSDF), que proporciona un marco agnóstico a la tecnología para desarrollar software seguro y es ampliamente reconocido por apoyar los requisitos de seguridad de software del gobierno de EE. UU. Cada práctica de SSDF ha sido interpretada y aplicada específicamente a las necesidades de los equipos de desarrollo de LabVIEW, con énfasis en la implementación práctica en entornos de prueba, medición, automatización e ingeniería.
Las recomendaciones presentadas en este documento también se compararon con otros marcos de desarrollo seguro establecidos y mejores prácticas de la industria, incluyendo la JKI Security Suite y el Ciclo de Vida de Desarrollo de Seguridad de Microsoft (SDL), para garantizar la coherencia con enfoques probados de seguridad de software, gestión de riesgos y protección de la cadena de suministro de software. El objetivo es proporcionar a las organizaciones de LabVIEW una hoja de ruta práctica para integrar la ciberseguridad en sus procesos de desarrollo, generando la evidencia y trazabilidad cada vez más requeridas por clientes, reguladores y programas de adquisición gubernamentales.
El proceso descrito en NIST 800-218 cubre estas cuatro áreas del desarrollo de software:
En este artículo, utilizamos estos temas para guiar el desarrollo de un SSDF de LabVIEW.
Antes de comenzar el desarrollo, es importante tomar medidas para ayudar a su equipo a adoptar principios de desarrollo seguro, completar la capacitación necesaria y establecer los procesos y herramientas que respaldarán el desarrollo seguro. Esta fase incluye tomarse el tiempo para lograr los siguientes objetivos:
Estos requisitos son genéricos para cualquier equipo de desarrollo de software, pero hay algunos pasos a seguir para adaptarlos a los equipos de pruebas y a los equipos de LabVIEW.
Muchos equipos de prueba están aislados del equipo de seguridad de su empresa. Coordínese con ellos para construir una relación de confianza, de modo que sepan que su equipo se toma la seguridad en serio. Reúnase con su equipo de seguridad para comprender los requisitos para el código desarrollado. Muéstreles sus proyectos y sus áreas de prueba, y guíelos a través de sus procesos. Es útil que entiendan cómo opera un laboratorio de pruebas y sepan qué limitaciones enfrenta. Sus desafíos serán diferentes de los de otros sistemas de TI, y ayuda que el equipo de seguridad entienda esas diferencias.
También es importante que entienda las preocupaciones del equipo de seguridad. Al comprender qué programas deben cumplir, podrá rastrear los mandatos de seguridad hasta los requisitos y podrá cumplir mejor la intención del programa original.
El seguimiento de requisitos es una parte importante de preparar a su equipo para entregar código seguro. Más que solo almacenar requisitos, un buen proceso de seguimiento proporciona trazabilidad de esos requisitos. Su equipo debería poder rastrear un requisito a lo largo del ciclo de vida:
Definición de requisitos → Diseño → Implementación → Prueba → Remediación de defectos → Lanzamiento
Esta trazabilidad se convierte en evidencia durante auditorías de clientes, declaraciones de seguridad (como CRA), evaluaciones (como CMMC) o revisiones de seguridad de proveedores.
GitHub Issues + Projects + Milestones es el enfoque de seguimiento de requisitos más común para la mayoría de los equipos más pequeños. Otras opciones de seguimiento incluyen GitLab (con niveles gratuitos y de pago), Azure DevOps, JIRA y otras herramientas profesionales de desarrollo de software. Estas herramientas le permiten crear incidencias y hacer un seguimiento de ellas hasta su resolución.
Dentro de su herramienta elegida, rastree sistemáticamente los requisitos de seguridad. Cada requisito debe cumplir con los siguientes criterios:
Después de identificar una herramienta de seguimiento de requisitos, documente su proceso para incluir el uso de estas herramientas en su desarrollo. Utilice el proceso de seguimiento de requisitos y seguimiento de incidencias a lo largo del ciclo de vida del sistema. Su proceso puede incluir los siguientes pasos:
Planifique modularizar el código. Este paso es especialmente útil en LabVIEW, ya que puede probar módulos individuales. Mientras planifica su arquitectura modular, planee desarrollar pruebas unitarias también. Estas mejoran la calidad de su código y proporcionan una forma más rápida de validar el código después de realizar actualizaciones, incluso después de que el sistema haya sido implementado.
Obtenga más información sobre el uso del NI Unit Test Framework
Las herramientas de prueba de terceros proporcionan valor adicional; por ejemplo, los productos Caraya y LUnit de JKI amplían las pruebas de software para los equipos de LabVIEW.
Definir un proceso para verificar y aprobar trabajos subcontratados, software de terceros y componentes de código abierto. Su proceso debe incluir la verificación de bases de datos públicas como Common Vulnerabilities and Exposures (CVE) para identificar vulnerabilidades conocidas en los componentes que utiliza.
Si utiliza componentes de código abierto, es responsable de escanear vulnerabilidades antes de usar el código en su aplicación.
Definir roles específicos en su equipo, incluidos los roles específicos de seguridad. Identificar las responsabilidades y el acceso de cada uno de estos roles. Como mínimo, defina roles con acceso privilegiado (administradores) separados de los roles de usuario (desarrolladores y operadores).
Crear capacitación de seguridad aplicable a esos roles. Asignar la capacitación a los miembros del equipo y rastrear la finalización de la capacitación. Esos registros se utilizarán como evidencia en una revisión de certificación.
Considerar utilizar la capacitación de seguridad de NI disponible en línea: Curso de consideraciones de seguridad para integraciones de sistemas de pruebas.
Los programas de certificación de la industria como ISC2 proporcionan certificaciones de nivel introductorio de bajo costo. El valor de estos programas para un equipo de pruebas es proporcionar un lenguaje común para comunicarse con los equipos de seguridad.
Después de definir su Ciclo de Vida de Desarrollo de Software (SDLC), preséntelo a la dirección de la empresa y obtenga su apoyo formal. Debería ser aprobado por al menos el nivel que aprueba el presupuesto de seguridad, para mostrar su compromiso con el programa.
Como organización, identifique los tipos de datos que puede encontrar y cree un sistema de etiquetado. Debería considerar los siguientes tipos de datos:
Tener un sistema claro de gestión y etiquetado de datos le permitirá proteger los datos de manera adecuada, aplicando las restricciones correctas a cada clasificación de datos. Definir esto como una organización antes de comenzar el desarrollo de su sistema ahorrará tiempo al aplicar los controles correctos a las áreas de riesgo adecuadas. Mapear a los sistemas de etiquetado corporativos y de TI existentes simplificará cómo los sistemas comparten datos entre sí.
Identifique las versiones y configuraciones de software y controladores que estandarizará para fines de seguridad. Para LabVIEW, identifique la versión que utilizará para el desarrollo. Establezca una configuración segura para sus instalaciones. Puede seguir la Guía de configuración segura de LabVIEW. Puede encontrar otras guías de configuración segura en ni.com/security.
Para la auditabilidad y para configurar rápidamente nuevos sistemas, automatice cómo se configuran las máquinas de desarrollo y de compilación. Establezca una instalación base y cree una imagen de dicha instalación.
Establezca herramientas para usar en las comprobaciones de seguridad durante su desarrollo. Necesitará una herramienta de análisis de seguridad de aplicaciones estáticas (SAST) para analizar su código fuente sin ejecutar el programa y encontrar posibles vulnerabilidades de seguridad. Para el código gráfico de LabVIEW, recomendamos la JKI Security Suite, diseñada específicamente para proporcionar análisis estático del código de LabVIEW. Alternativamente, puede realizar un análisis estático de código manual buscando problemas de seguridad.
Las herramientas SAST son una herramienta de seguridad importante para analizar código en busca de vulnerabilidades. Las herramientas de pruebas de seguridad de aplicaciones dinámicas (DAST) también son importantes y se utilizan para escanear el código en ejecución durante las pruebas. El análisis de composición de software (SCA) identifica el uso de bibliotecas de código abierto, paquetes de terceros y componentes de software y escanea en busca de vulnerabilidades conocidas y problemas de licencia con esos componentes.
Hay muchos otros tipos de herramientas utilizadas para escanear código en busca de problemas de seguridad. La herramienta adecuada para su proyecto depende de su conjunto de herramientas, la naturaleza de su proyecto y los tipos de código que utiliza. Durante esta fase del ciclo de vida de desarrollo seguro, es importante investigar e identificar las herramientas que utilizará su equipo.
El desarrollo seguro requiere que el código fuente se almacene, con múltiples versiones para que los equipos puedan volver a versiones anteriores en caso de que algo falle en el código. Como parte de la preparación de la organización para realizar desarrollo seguro, establezca un repositorio de código que almacene código, extraiga código para el desarrollo y mantenga el control de versiones del código fuente.
La ramificación en el repositorio de código facilita el desarrollo paralelo y las versiones estables. Defina los tipos de rama que utilizará en su organización. Estos tipos de rama son estándar, pero pueden adaptarse a sus necesidades:
Utilice un repositorio que proporcione controles de seguridad adecuados. Asegúrese de que el repositorio mantenga un historial completo de archivos de commit y cambios para la trazabilidad.
Asegúrese de que las computadoras utilizadas para desarrollar código sigan las políticas básicas de ciberseguridad. Estos controles básicos incluyen protección con contraseña, protección contra código malicioso y otra higiene cibernética básica. Como ejemplo de estos controles básicos, consulte https://www.acquisition.gov/far/52.204-21.
Para la trazabilidad, capture la configuración de la computadora utilizada para desarrollar el sistema. Los ajustes de configuración para capturar incluyen los siguientes ejemplos:
La mayoría de los programas de seguridad requerirán evidencia de que su equipo siguió las prácticas establecidas como parte del SSDF. Establezca un repositorio para rastrear la evidencia y manténgalo actualizado durante el desarrollo y la implementación del sistema. El sistema debe rastrear los siguientes elementos:
Muchos equipos realizan estas actividades de seguridad pero no pueden demostrar que las hicieron. Los equipos de cumplimiento querrán ver ambas cosas: que su equipo tiene procesos establecidos y que los sigue. Tener estos documentos en un solo lugar simplificará enormemente las auditorías y las revisiones de cumplimiento.
Cuando la organización ha estado preparada para desarrollar código de forma segura, la siguiente tarea es proteger el software. Este paso asegura que el equipo mantenga el código seguro durante el desarrollo y el lanzamiento.
Proteger el software durante el proceso de desarrollo es fundamental para cualquier software, independientemente del lenguaje de programación utilizado. A medida que los equipos de LabVIEW adoptan herramientas de flujo de trabajo profesionales para el desarrollo de software, esos equipos también deben adoptar procesos y herramientas de desarrollo seguros.
Utilice los repositorios de código seguros identificados en la fase anterior para almacenar y gestionar su código. Un buen repositorio hace más que gestionar el código fuente. También contiene los requisitos, la documentación, los scripts de compilación, los artefactos de prueba y los historiales de lanzamiento. Debido a que el repositorio contiene tanto código y soporte, es importante usar un repositorio seguro; si el repositorio se ve comprometido, su software se ve comprometido.
Dentro del repositorio, su rama principal es un activo crítico que debe estar protegido. Su equipo debe definir y seguir políticas para proteger el código. Estas políticas pueden incluir los siguientes ejemplos:
El repositorio también debe proporcionar trazabilidad desde la generación de un requisito, a través del desarrollo y hasta la publicación del producto. Algunos repositorios permiten la firma de commits (por ejemplo, en Git).
El repositorio debe proporcionar un rastro de auditoría manteniendo un registro de los cambios de software. ¿Qué cambió, quién lo cambió, por qué se cambió, quién lo aprobó y cuándo se lanzó? Además, las imágenes de lanzamiento deben guardarse en un archivo seguro, para que el código pueda recuperarse incluso si el repositorio se ve comprometido.
Un SBOM proporciona una lista de software y componentes utilizados en el desarrollo del código. Generar un SBOM como parte del proceso de compilación asegura que tiene un registro de qué componentes se utilizan en el código, agilizando el proceso para identificar y solucionar vulnerabilidades.
A partir de LabVIEW 2026 Q3, puede generar SBOM como parte del proceso de compilación de la aplicación. Para más información, consulte Generación de una lista de materiales de software para una aplicación independiente.
La firma de código proporciona un mecanismo para que los usuarios verifiquen que el software fue producido por una organización conocida, no ha sido modificado desde su lanzamiento y fue aprobado para su distribución. En una aplicación de LabVIEW, la firma de código debe aplicarse a ejecutables, instaladores, paquetes de implementación, DLL, controladores y paquetes de actualización.
Puede firmar su aplicación durante el proceso de compilación siguiendo estas instrucciones. También puede firmar software usando SignTool.exe de Microsoft, que es lo mismo que firmar cualquier aplicación o archivo.
Las aplicaciones frecuentemente requieren secretos como contraseñas, claves API, certificados, tokens, claves de cifrado, credenciales de base de datos y credenciales de cuenta de servicio. Estos secretos proporcionan acceso a sistemas y datos y deben protegerse durante todo el ciclo de vida del software.
Nunca incluya contraseñas, claves API, certificados o claves de cifrado directamente en el código fuente, archivos de configuración, scripts de compilación o utilidades de prueba. Los secretos codificados en duro son difíciles de rotar, pueden copiarse en repositorios y pueden exponerse a través de revisiones de código fuente, copias de seguridad o ingeniería inversa de aplicaciones implementadas.
Almacene secretos utilizando un sistema operativo seguro o almacenamiento protegido por hardware siempre que sea posible. Los ejemplos de almacenamiento seguro o protegido incluyen las siguientes opciones:
Aplique el principio de mínimo privilegio al otorgar acceso a secretos. Solo los usuarios, sistemas y servicios que requieran acceso a un secreto deben poder recuperarlo. Las credenciales administrativas deben separarse de las credenciales de usuario, y se deben evitar las cuentas compartidas siempre que sea posible.
Las contraseñas, certificados, claves de API y claves de cifrado deben reemplazarse periódicamente de acuerdo con la política de la organización. Establezca un proceso que defina cómo se generan los secretos, dónde se almacenan, quién puede acceder a los secretos y cómo se revocan los secretos comprometidos.
Los sistemas de prueba utilizan frecuentemente conexiones de red reales, bases de datos, servicios en la nube e instrumentos. Los equipos de prueba necesitan acceso a estos sistemas durante las pruebas. Utilice credenciales de prueba dedicadas en lugar de credenciales de producción siempre que sea posible. Los entornos de prueba separados reducen el riesgo de exponer los sistemas de producción durante las actividades de desarrollo y validación.
Esta fase se centra en diseñar, implementar, probar y validar el software de forma segura. Para realizar esta tarea de manera efectiva, un equipo debe evaluar los riesgos y los requisitos del uso previsto del software y diseñar para esos riesgos. Las mejores prácticas incluyen la reutilización de componentes seguros conocidos cuando sea posible, las pruebas durante el desarrollo y el escaneo del código de desarrollo en busca de vulnerabilidades. Los equipos planifican el uso seguro, incluido el uso de configuraciones seguras de forma predeterminada.
Las aplicaciones de prueba y medición enfrentan desafíos de seguridad diferentes a las de las aplicaciones de software generales. Los equipos de LabVIEW están posicionados para comprender esos desafíos y desarrollar software que protegerá contra ataques centrados en sus aplicaciones. LabVIEW proporciona una serie de protecciones de seguridad inherentes, pero los equipos deben considerar los posibles ataques y preparar una defensa contra ellos.
OWASP (Open Worldwide Application Security Project) es una fundación sin fines de lucro que proporciona herramientas, guías y estándares gratuitos para ayudar a las personas a construir software seguro. OWASP proporciona una guía impulsada por la comunidad para el modelado de amenazas; su modelo proporciona una serie estructurada de pasos para delimitar su trabajo, determinar amenazas, determinar contramedidas y mitigación, y evaluar su trabajo.
Para los equipos de prueba, esto comienza con una conversación para comprender el uso previsto y las amenazas del sistema que se está desarrollando. La conversación debe incluir al desarrollador principal, arquitecto de pruebas, ingeniero de sistemas, propietario de producto, representante de ciberseguridad y personal de operaciones.
El enfoque de OWASP incluye una lista de amenazas que incluye suplantación, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios (STRIDE). Las categorías de amenazas STRIDE ayudan a guiar a un equipo a considerar todos los tipos de amenazas.
Los equipos de prueba deben basarse en su experiencia en sesiones de lluvia de ideas para examinar específicamente cómo las amenazas impactarán sus sistemas en un entorno de prueba:
Añadir estos riesgos específicos de la prueba a amenazas cibernéticas más tradicionales ayudará a identificar estrategias de defensa apropiadas para el sistema de prueba. El resultado del modelado de amenazas debe ser un conjunto de riesgos priorizados y los requisitos de seguridad necesarios para mitigar esos riesgos. Estos requisitos se convierten en entradas para las actividades de diseño y desarrollo del sistema descritas en la siguiente sección. Las revisiones periódicas de amenazas pueden ayudar a los equipos a identificar nuevas amenazas emergentes con el tiempo y pueden incluir una revisión de problemas que las amenazas anteriores no capturaron.
El modelado de amenazas identifica riesgos para el sistema. El siguiente paso es convertir esos riesgos en requisitos de seguridad medibles que puedan implementarse, probarse y rastrearse a lo largo del ciclo de vida. Los requisitos de seguridad deben tratarse con el mismo nivel de rigor que los requisitos funcionales.
Un requisito de seguridad define un control o comportamiento de seguridad que el sistema debe proporcionar. Los buenos requisitos de seguridad son específicos, medibles, comprobables y rastreables. La siguiente tabla muestra algunos ejemplos.
Los requisitos de seguridad deben asignarse identificadores únicos y rastrearse a través de las mismas herramientas de gestión de requisitos utilizadas para los requisitos funcionales.
Un requisito de seguridad bien definido debe ser rastreable a través de todo el ciclo de vida del desarrollo. La trazabilidad demuestra que los riesgos identificados fueron abordados y proporciona evidencia valiosa durante las auditorías de clientes, las evaluaciones de seguridad de proveedores y las revisiones regulatorias.
Los sistemas de prueba y medición tienen requisitos de seguridad que a menudo se pasan por alto en los proyectos de software empresarial. Al desarrollar requisitos de seguridad, utilice categorías de seguridad estándar, pero también considere los siguientes datos:
Debido a que las mediciones inexactas y los resultados de las pruebas corruptos pueden tener consecuencias comerciales significativas, los requisitos de seguridad para la integridad son a menudo tan importantes como los requisitos de confidencialidad.
El código modular limita el impacto de los defectos y vulnerabilidades al aislar la funcionalidad en componentes bien definidos con interfaces controladas. En un buen diseño modular, cada módulo expone solo las funciones que otros módulos necesitan. Esto proporciona menos puntos de entrada y reduce las oportunidades de uso indebido. El código modular también tiene la ventaja de que es más fácil de probar, por lo que es más fácil aplicar y validar actualizaciones al código.
Al construir código modular, considere el principio de mínimo privilegio. Un módulo solo debe tener los permisos necesarios para realizar su función. Por ejemplo, una función de comunicación de instrumentos no necesita acceso a una base de datos, ya que esto lo maneja un módulo diferente. Evite pasar el manejador de la base de datos al módulo de comunicación del instrumento.
A medida que los datos se pasan entre módulos, evalúe la confianza de la comunicación. Cuando sea aplicable, valide la fuente antes de aceptar datos de otro componente.
El código modular debería facilitar las revisiones de seguridad. Cada módulo puede ser revisado, en lugar de revisar todo el conjunto de código con cada revisión. El revisor de código no necesita entender el conjunto completo de código para contribuir a la seguridad de un solo componente.
Los módulos de código también simplifican la reutilización de código. Un módulo que ha sido desarrollado de forma segura y probado puede reutilizarse en otras aplicaciones con la confianza de que funciona como se pretende.
Establezca un conjunto de mejores prácticas y siga esas prácticas. Sus revisiones de código deben verificar el cumplimiento de estas prácticas. Si bien una revisión completa de las mejores prácticas está fuera del alcance de este documento, estas deben incluir como mínimo estas áreas:
Utilice un marco de pruebas unitarias reconocido de LabVIEW (NI Unit Test Framework, JKI Caraya o LUnit). Estas herramientas permiten a los desarrolladores definir entradas y salidas y validar que el código funciona correctamente. Esto se puede hacer sin ejecutar la aplicación completa, simplificando la validación del código.
Las pruebas unitarias protegen funciones sensibles, como el control de equipos costosos, porque los módulos se pueden probar de forma aislada. Las pruebas unitarias deben diseñarse para una ejecución repetible y se integran idealmente en un sistema de integración continua (CI) para asegurar que se ejecuten automáticamente con los cambios de código.
Las revisiones de seguridad frecuentes son una parte importante para establecer una cultura de desarrollo con mentalidad de seguridad. Las revisiones proporcionan una forma para que los equipos establezcan prácticas seguras, aprendan unos de otros y refuercen los procesos seguros. Las revisiones de seguridad comienzan antes del desarrollo, revisando la arquitectura y los métodos planificados. Las revisiones deben continuar entonces a lo largo de todo el proceso de desarrollo para asegurar que el código se desarrolle de forma segura. La frecuencia debe basarse en el tamaño del desarrollo; las revisiones deben ocurrir con suficiente frecuencia para que los problemas puedan corregirse antes de que haya ocurrido un desarrollo posterior significativo. Las revisiones deben ocurrir en cada solicitud de fusión, solicitud de extracción u otro evento significativo de integración de código. Pueden ser apropiadas revisiones programadas adicionales para proyectos grandes.
Las revisiones de seguridad se mejoran enormemente cuando un equipo trabaja a través de la revisión a partir de una lista de verificación. Estas listas de verificación deben ser establecidas por la organización y personalizadas al comienzo de cada proyecto basándose en el análisis de amenazas y riesgos.
Además de las revisiones de código manuales, realice revisiones de código automatizadas. Si utiliza un proceso de integración continua y entrega/implementación continuo (CI/CD), añada escaneo de seguridad a su proceso de admisión para que el código sea escaneado con cada registro de código. Configure herramientas de escaneo adicionales para ejecutar diariamente o semanalmente para detectar cualquier vulnerabilidad de seguridad introducida recientemente antes de que se convierta en una parte permanente del código. Utilice análisis estático, pruebas unitarias y otras herramientas de escaneo de seguridad para incluir una variedad de tipos de revisión.
Siempre que sea posible, utilice la última versión de los controladores del software de desarrollo. Se identifican nuevas amenazas de seguridad casi a diario, y los desarrolladores incorporan correcciones de seguridad en parches y nuevas versiones de software. Si no puede usar la última versión, use software que siga recibiendo actualizaciones de seguridad del proveedor y que las reciba durante toda la vida útil del sistema.
Configure sus herramientas para seguridad utilizando las guías de configuración proporcionadas por el proveedor.
Ver la lista de versiones de software compatibles para productos NI
Encontrar guías para productos NI
Antes de lanzar el producto, aplique pruebas basadas en las amenazas y riesgos identificados al comienzo del proyecto. Esta lista puede incluir las siguientes pruebas:
Debido a que LabVIEW es un lenguaje de programación gráfico, algunas herramientas de seguridad tradicionales no pueden probar el código de LabVIEW. Herramientas como JKI Security Suite proporcionan capacidades de análisis estático centradas en la seguridad diseñadas para desarrolladores de LabVIEW, capaces de escanear código LabVIEW y ajustadas a las preocupaciones de seguridad específicas de un lenguaje de programación gráfico.
Aprenda más sobre JKI Security Suite
Una versión no debe ser aprobada a menos que el equipo de desarrollo pueda demostrar que se revisó el modelo de amenazas, se resolvieron las vulnerabilidades críticas, se aplicaron y aprobaron las pruebas unitarias, se realizó un análisis estático, se generó un SBOM, se llevaron a cabo revisiones de código y se firmó el paquete de la versión. Imponer un proceso formal de puerta de lanzamiento da a la gerencia un punto de referencia para revisar que los procesos se siguieron y que el software es seguro.
Desarrollar software seguro es solo una parte del proceso. Una aplicación segura puede volverse vulnerable si se implementa incorrectamente o si se eliminan los controles de seguridad durante la instalación y configuración. Por lo tanto, el proceso de implementación debe tratarse como parte del ciclo de vida de desarrollo de software seguro, con procedimientos definidos, revisiones y actividades de validación antes de que el software se lance a los usuarios.
Configuración predeterminada segura
Las aplicaciones deben implementarse utilizando configuraciones seguras por defecto. Los usuarios asumen frecuentemente que la configuración predeterminada representa la configuración recomendada. Cualquier opción sensible a la seguridad que esté deshabilitada por defecto puede permanecer deshabilitada durante toda la vida del sistema.
Los valores predeterminados seguros pueden incluir los siguientes ejemplos:
Se debe exigir a los usuarios que debiliten conscientemente la configuración de seguridad en lugar de habilitar manualmente las protecciones de seguridad.
Endurecimiento de producción
Antes del lanzamiento, elimine los artefactos y características de desarrollo que son útiles durante el desarrollo pero que crean un riesgo innecesario en los entornos de producción. Revisar la aplicación según los siguientes criterios:
Los sistemas de producción deben exponer solo la funcionalidad necesaria para operar el sistema.
Gestión de cuentas y permisos
Revisar los permisos requeridos por el sistema y asignarlos a los roles apropiados. Los sistemas no deben otorgar privilegios de administrador a menos que exista una necesidad operativa documentada. Las cuentas de servicio deben configurarse con solo los permisos necesarios para realizar su función prevista. Al considerar los permisos basados en roles, considere:
Si el sistema almacena información sensible, verifique que los controles de acceso protejan esa información de manera adecuada.
Configuración de seguridad de red
Documente todas las comunicaciones de red requeridas antes de la implementación. Para cada conexión realizada por el sistema, considere:
Cuando los datos cruzan límites de red, los datos deben estar protegidos. Para cada transmisión de datos, tome las siguientes precauciones:
Los sistemas de prueba a menudo se conectan simultáneamente a redes empresariales, redes de fabricación, servicios en la nube e instrumentos. Comprender y documentar estos límites de confianza es una actividad de implementación importante.
Gestión de secretos y credenciales
Las aplicaciones a menudo requieren contraseñas, claves API, certificados, tokens o claves de cifrado. Al manejar estos tokens secretos, tenga cuidado de no:
En su lugar, use una de las siguientes herramientas o tecnologías:
Documente cómo se crean, almacenan, rotan, respaldan y revocan los secretos. Siga este proceso.
Registro y auditoría
Las aplicaciones deben registrar eventos operativos y de seguridad importantes. Los eventos a registrar incluyen los siguientes ejemplos:
Verifique que el registro no incluya ningún secreto, como contraseñas e información personal o confidencial, ya que los registros pueden ser visibles para audiencias no destinadas a esa información.
Los registros ayudan a solucionar fallos, investigar incidentes y demostrar el cumplimiento de los requisitos del cliente y normativos.
Siempre que sea posible, integre los registros de la aplicación con los mecanismos de registro de la plataforma, como el Visor de Eventos de Windows o Syslog de Linux, para simplificar la monitorización, la investigación de incidentes y la presentación de informes de cumplimiento. Evalúe si enviar registros a un servidor seguro ayudará con la protección y la accesibilidad.
Proteja los registros de auditoría contra accesos y modificaciones no autorizados y defina durante cuánto tiempo se conservarán los registros.
Aprobación de lanzamiento
Antes de lanzar el software, realice una revisión de seguridad final para verificar que la aplicación cumple con los requisitos de lanzamiento del equipo. Como parte de esta revisión final, incluir:
El proceso de lanzamiento debe producir evidencia que muestre que estas actividades se completaron. Estos registros de evidencia deben protegerse contra manipulaciones después de la liberación para mantener la integridad.
Firma de código e integridad del paquete
Los usuarios deben poder verificar que el software lanzado se originó en la organización esperada y no ha sido modificado desde el lanzamiento.
La firma de código debe aplicarse a todos los siguientes tipos de software:
La firma de código no evita la modificación del software, pero proporciona una fuerte detección de modificaciones no autorizadas y la garantía de que el software proviene del editor esperado.
Validación de implementación
Después de la instalación, verifique que el sistema implementado opere de forma segura en su entorno previsto. Las actividades de validación deben confirmar la siguiente funcionalidad:
La validación de seguridad debe realizarse cada vez que se realicen cambios de configuración significativos.
Evidencia de implementación
Mantenga registros que demuestren que la implementación se realizó de acuerdo con el proceso definido. Estos registros incluyen los siguientes ejemplos:
Estos registros proporcionan una trazabilidad valiosa durante las auditorías de clientes, las evaluaciones de proveedores, las revisiones regulatorias y las investigaciones internas de seguridad.
Una vulnerabilidad de software es una debilidad, fallo o defecto en el diseño, implementación, configuración o procesos operativos de un software que podría ser explotado para comprometer la confidencialidad, integridad o disponibilidad de un sistema o sus datos. Se puede identificar una vulnerabilidad en el código desarrollado por el equipo o en uno de los componentes utilizados en el software. Debido a que las vulnerabilidades proporcionan a los actores maliciosos una forma de dañar un sistema, es importante que estas vulnerabilidades se remedien y se implementen en los sistemas afectados.
La industria de las pruebas enfrenta un desafío histórico al responder a las vulnerabilidades. Muchos proyectos de prueba se financian a través de un único modelo de financiación inicial, sin financiación para el mantenimiento continuo de los sistemas. Esto significa que los equipos de prueba no tienen los recursos para actualizar los sistemas, ni siquiera para proporcionar actualizaciones de seguridad. Esto presenta un conflicto directo con los requisitos de seguridad para mantener actualizados los sistemas.
Un desafío significativo es la cantidad de validación requerida para hacer actualizaciones. Incluso si las herramientas de software y hardware no tienen costo, una actualización puede resultar muy costosa, ya que se debe validar que el sistema funciona como se pretende después de la actualización.
A medida que la industria de la seguridad cambia, la industria de las pruebas también debe comenzar a cambiar para planificar y financiar mejor los sistemas de prueba a lo largo de su ciclo de vida. Hay algunos pasos que los equipos de prueba pueden tomar para pasar a un enfoque de gestión de ciclo de vida completo, que incluyen:
Anunciamos vulnerabilidades en productos de NI, incluyendo LabVIEW, controladores y otro software, en ni.com/security. Los parches también se informan a través del sistema Common Vulnerabilities and Exposures (CVE). Estos parches pueden solucionar vulnerabilidades en el código del software desarrollado por ingenieros de NI o en los componentes que usamos. Puede registrarse para recibir notificaciones de nuevos parches en ni.com/security.
Un SBOM también se puede utilizar para automatizar escaneos del software. Si genera un SBOM de su aplicación LabVIEW, puede configurar software de escaneo para verificar la base de datos CVE en busca de problemas reportados y notificarle. Hay una variedad de herramientas de análisis de composición de software (SCA) que escanean los SBOM y los comparan con la base de datos CVE.
Si su usuario final identifica una vulnerabilidad, puede reportarla directamente a usted. Si el problema está dentro del software de NI, puede reportarlo en ni.com/security.
Es importante tomar en serio los informes de vulnerabilidad. Si un usuario reporta un problema, o si se reporta una vulnerabilidad en su pila de software, analice la vulnerabilidad para determinar el impacto y la probabilidad de que sea explotada. Estos problemas están impactados por la naturaleza de la vulnerabilidad y por la forma en que ha utilizado el componente de software afectado. Si determina que la amenaza de explotación es significativa, debe actualizar su software y emitir un parche a su usuario final.
Algunas regulaciones, como la Ley de Resiliencia Cibernética Europea (CRA), exigen que proporcione parches de seguridad durante cinco años o más. Algunos contratos pueden especificar compromisos de soporte más largos o más cortos. Planifique este nivel de soporte en su propuesta de proyecto inicial para evitar sorpresas después de entregar el proyecto.
Como parte de su proceso de remediación de vulnerabilidades, realice un Root Cause Analysis de la vulnerabilidad para mejorar su proceso de desarrollo y eliminar problemas similares en futuros proyectos.
El desarrollo de software seguro no es una actividad separada realizada al final de un proyecto. Es un conjunto de prácticas integradas a lo largo del ciclo de vida de un sistema. Al adoptar los principios descritos en esta guía, los equipos de LabVIEW pueden reducir vulnerabilidades, mejorar la mantenibilidad, simplificar los esfuerzos de cumplimiento y proteger mejor los sistemas y datos que se les confían. La seguridad es un proceso y su equipo madurará con el tiempo. Comience ahora a establecer un proceso repetible y sostenible que mejore continuamente la seguridad a lo largo de la vida del producto.
| Amenaza | Requisito de seguridad |
|---|---|
| Modificación no autorizada de resultados de prueba | Solo se permitirá a los usuarios autenticados con el rol apropiado modificar los resultados de prueba almacenados. |
| Intercepción de tráfico de red | Todas las comunicaciones entre la aplicación y los sistemas externos utilizarán protocolos cifrados. |
| Corrupción de datos de calibración | Los datos de calibración deben protegerse de modificaciones no autorizadas, y todos los cambios deben registrarse. |
| Control de equipo no autorizado | Las operaciones de equipos administrativos o peligrosos requerirán usuarios autenticados y autorizados. |