Tres formas prácticas de preparar sus dispositivos de IoT para el futuro

A pesar del potencial de los dispositivos integrados en el contexto de IoT, actualmente no se requiere que muchos dispositivos cumplan con los estándares de seguridad. Pero en el mundo ágil del desarrollo de IoT, los requisitos de cumplimiento pueden llegar mucho más tarde, después de que el código ya se haya escrito y probado. Entonces, ¿cómo puede prepararse para el futuro de sus dispositivos IoT integrados?

El término Internet de las cosas (IoT) se refiere a un sistema de dispositivos, componentes o servicios habilitados para red que publican y/o consumen datos. Aplicaciones de IoT se están convirtiendo en una parte integral de nuestra vida: desde robots industriales e instrumentos quirúrgicos hasta automóviles autónomos y drones que vuelan de forma autónoma. Muchos de estos dispositivos hoy en día ya pueden afectar la seguridad, la privacidad y la protección de sus usuarios. En algunos casos, el coste de una avería es mortal, por lo que es fundamental fabricar estos dispositivos según los estándares vigentes.

Si bien es mejor comenzar a incorporar las actividades de cumplimiento en el diseño de software desde el principio, es un hecho bien conocido que los procesos de desarrollo estrictos (especialmente sin la ayuda de la automatización) pueden afectar el tiempo de comercialización. No muchos desarrolladores disfrutan de realizar pruebas adicionales y documentar la trazabilidad fuera del horario laboral normal, por lo que los equipos pragmáticos, ágiles y de ritmo rápido a menudo no pueden darse el lujo de perder impulso al incorporar el cumplimiento en el cronograma con la premisa de que "podrían necesitarlo" en el futuro. En cambio, muchos equipos optan por "cruzar ese puente cuando llegan a él".

Desafortunadamente, no existe una varita mágica o una fórmula mágica que "haga" retroactivamente el código compatible. Lo que estas organizaciones están aprendiendo de la manera difícil es que el costo de agregar cumplimiento al final del proyecto es órdenes de magnitud más alto que el costo de desarrollar el producto de trabajo inicial.

Entonces, ¿cuáles son algunas de las acciones de bajo impacto que puede tomar hoy para prepararse para satisfacer los estrictos requisitos de cumplimiento del mañana?

Acción 1: Obtenga visibilidad de su deuda técnica

Es importante comprender dónde se encuentra su proyecto en el momento. monto de la deuda técnica es el costo del retrabajo potencial debido a la complejidad del código combinado con cualquier estándar de codificación restante y violaciones de seguridad que existen actualmente en el código. Esta deuda se debe a la posterior limpieza, corrección y prueba del código. Una de las formas de obtener un buen control sobre dónde se encuentra un proyecto hoy en día es utilizar el análisis de código estático automatizado. El análisis estático proporciona información sobre la calidad y la seguridad de una base de código y enumera las infracciones de los estándares de codificación, según corresponda.

Desafortunadamente, muchos equipos que desarrollan aplicaciones integradas en C y C ++ todavía dependen de su compilador o revisiones de código manuales para detectar problemas, en lugar de adoptar un análisis estático. Algunos equipos tienen dificultades para adoptar herramientas de análisis estático por una variedad de razones, como encontrarlas ruidosas y difíciles de usar (no debería ser un problema si aprender a empezar correctamente), o no trabajarlo en el proceso de desarrollo diario debido a asuntos urgentes del día a día. Una (mala) percepción común es que el tiempo dedicado a determinar qué infracciones vale la pena corregir es mayor que el valor de la solución real.

Pero encontramos que los equipos que adoptaron un pequeño conjunto de reglas críticas y obligatorias dedicaron mucho menos tiempo a reelaborar el código cuando se enfrentaron a auditorías de seguridad funcional más adelante en el proyecto. Es mucho más fácil construir sistemas seguros y protegidos desde cero mediante Building Security In mediante la implementación, por ejemplo, de las Pautas de codificación segura CERT C. Puedes empezar con algo pequeño. CERT tiene un sofisticado sistema de priorización (que utiliza la gravedad, la probabilidad y el costo de remediación, cada uno en 3 grados, 27 niveles en total), y si usa las herramientas de Parasoft, puede ver el estado de cumplimiento fácilmente en un tablero preconfigurado.

El análisis estático también ayuda a las organizaciones a comprender su deuda técnica mediante la recopilación de puntos de datos que ayudan a la administración con el cumplimiento de la seguridad y la protección. Los gerentes pueden evaluar fácilmente preguntas importantes, como:

• ¿Cuál es mi línea de base? ¿Cuántas violaciones estándar de codificación no críticas existen en mi base de código?
• Datos de tendencias: ¿Se informan infracciones nuevas y corregidas con cada compilación? ¿Estamos mejorando o empeorando?
• ¿Cuál es la complejidad de mi código hoy? Esta creciendo?

Algunos estándares requieren medir la complejidad ciclomática, para mantenerla por debajo de cierto umbral. Las métricas de complejidad también se pueden usar para estimar un esfuerzo de prueba; por ejemplo, la cantidad de casos de prueba que necesita para demostrar una cobertura de nivel de rama del 100% para cumplir con IEC 61508 SIL 2 será proporcional a la Complejidad Ciclomática de McCabe de una función.

A continuación se muestra un ejemplo de un panel que muestra el cumplimiento de MISRA de un proyecto dentro de Parasoft DTP, el centro de informes y análisis de Parasoft:

Y aquí es lo mismo para CERT C:

El valor de ver las métricas del código puede ayudar a exponer áreas más complejas para una revisión adicional del código y monitorear qué tan bien esas áreas están cubiertas por las pruebas. A continuación, se muestra un ejemplo de panel de métricas:

Entonces puedes comenzar con lo básico. Una vez que el equipo se sienta cómodo con la gestión de los errores más críticos, puede aumentar la amplitud de las violaciones de los estándares. No todas las reglas están "grabadas en piedra", por lo que es importante decidir qué reglas están dentro o fuera del estándar de codificación del proyecto. Como mínimo, la adopción del conjunto de reglas obligatorias en un par de estándares de codificación clave (por ejemplo, MISRA obligatorio o reglas CERT C) facilita la argumentación futura de seguridad para un dispositivo conectado.

Acción 2: configurar un marco de prueba unitario calificable y medir la cobertura del código

La mayoría de los ingenieros pragmáticos tienden a estar de acuerdo en que la creación ciega de pruebas unitarias para todas sus funciones no proporciona un buen retorno de la inversión. Sin embargo, si su equipo tiene acceso a un marco de pruebas unitarias como parte del entorno limitado del proyecto, es una inversión valiosa. Las pruebas unitarias se pueden usar de manera inteligente cuando los ingenieros sienten que necesitan probar ciertos algoritmos complejos o manipulaciones de datos de forma aislada. También hay un valor significativo en el proceso de desarrollo de pruebas unitarias; lo que hemos visto en las organizaciones es que la práctica de simplemente escribir y ejecutar una prueba unitaria hace que el código sea más robusto y mejor diseñado.

Cuando surgen requisitos de seguridad o cumplimiento de seguridad, una organización puede acelerar rápidamente el esfuerzo de prueba de la unidad agregando miembros del personal temporalmente. Pero para escalar rápidamente ese esfuerzo, el marco y el proceso de pruebas unitarias ya deben entenderse y documentarse durante el transcurso del proyecto. Las características comunes de un marco de prueba unitario escalable con el cumplimiento futuro en mente son:

• Calificado para el uso previsto para un estándar de seguridad determinado (por ejemplo, mediante certificado TÜV)
• Integrado en un sistema de construcción automatizado
• Informa la métrica de cobertura de código requerida (p. Ej.MC / DC)
• Registre los resultados y la cobertura de las pruebas ejecutadas por compilación y a lo largo del tiempo
• Vendible para múltiples proyectos y equipos

La conclusión clave es implementar todas las técnicas de prueba que requiere un futuro estándar de seguridad, pero en una escala mínima. Es más fácil para esto escalar cuando y si aparece una necesidad de certificación en lugar de comenzar desde cero.

Acción 3: aislar la funcionalidad crítica

La arquitectura de sistemas embebidos requiere considerar muchas “ilidades”: simplicidad, portabilidad, mantenibilidad, escalabilidad y confiabilidad mientras se resuelven las compensaciones entre latencia, rendimiento, consumo de energía y restricciones de tamaño. Al diseñar un sistema que potencialmente se conectará a un gran ecosistema de IoT, muchos equipos no están priorizando la seguridad y EN LINEA sobre algunos de estos otros factores de calidad.

Para facilitar el cumplimiento de las normas de seguridad en el futuro (y seguir las buenas prácticas arquitectónicas), puede separar los componentes en el tiempo y en el espacio. Por ejemplo, puede diseñar un sistema en el que todas las operaciones críticas se ejecuten en una CPU dedicada separada, mientras que todas las operaciones no críticas se ejecutan en otra, lo que proporciona una separación física. Otra opción es emplear un hipervisor de núcleo de separación y conceptos de microkernel. Hay otras opciones disponibles, pero la clave es adoptar enfoques arquitectónicos clave de separación de intereses, defensa en profundidad, y separación por criticidad mixta tan pronto como sea posible. Estos enfoques no solo reducen la cantidad de trabajo requerido para cumplir con los estándares de seguridad y protección, sino que también mejoran la calidad y la resistencia de la aplicación. Por ejemplo, aquí hay algunas formas de aislar el código crítico:

• Dominio espacial:
  • archivos
  • Módulos
  • Directorio
  • Bibliotecas
• Dominio de ejecución:
  • Hilos, tareas RTOS, hipervisores
  • Núcleos de CPU, CPU separada

Separar las funciones críticas de las no críticas reduce el alcance del esfuerzo de verificación futuro para demostrar el cumplimiento.

Resumen

Muchos dispositivos de borde en el ecosistema de IoT brindan servicios críticos que pueden estar sujetos a futuros estándares de seguridad y protección. Por supuesto, tratar de cumplir con los requisitos de los estándares, sin saber si es necesario o no, no es una estrategia rentable. Para prepararse para el futuro, las organizaciones pueden adoptar técnicas de diseño clave, enfoques de pruebas unitarias y herramientas de análisis estático, y recopilar métricas para respaldar las necesidades futuras. Los equipos de software pueden adoptar estos enfoques sin problemas en sus procesos existentes si se inician con suficiente antelación. Comenzar temprano con el enfoque correcto que se puede escalar más adelante para evitar la necesidad de un esfuerzo casi hercúleo para lograr que el código de software cumpla con las normas cuando se ha desarrollado, probado e implementado.

“MISRA”, “MISRA C” y el logotipo del triángulo son marcas comerciales registradas de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Todos los derechos reservados.