Protección y seguridad son conceptos distintos, pero existen varias maneras de lograr ambas en aplicaciones de alta integridad, como explica Richard Bellairs, de PRQA
El mundo está cada vez más conectado y los sistemas son vulnerables a ataques maliciosos a través de estas conexiones. Ya ha habido varios ejemplos muy relevantes que han sacudido del sector cualquier complacencia que pudiera haber existido. La protección de sistemas de alta integridad viene siendo prioritaria desde hace mucho tiempo, pero la seguridad no ha recibido la misma atención, Protección y seguridad tienen que cumplir diferentes reglas y protocolos. Sin embargo, aunque sean intrínsecamente distintas, comparten algunos aspectos y por esa misma razón, al evaluar su programación, es posible aplicar un enfoque integral. La necesidad de atender estas preocupaciones está presente en cada aplicación, especialmente en sistemas cuya protección es crítica. Dicho esto, puede resultar difícil ofrecer una definición formal de lo que es seguro y lo que es protegido por lo que se refiere al desarrollo de software.
Existen estándares de protección funcional como IEC61508 o ISO26262, pero al comparar estos requisitos en estándares de programación reconocidos en el sector para sistemas de alta integridad con los estándares de programación para software de seguridad crítica se tienden a ampliar sus coincidencias. El debate sobre la protección y la seguridad de un lenguaje como C o C++ se ve limitado por la naturaleza del propio lenguaje; de ahí que surjan técnicas y metodologías que tienen como objetivo cuidar de la protección y la seguridad en la aplicación de uno o más estándares de programación.
Internet de las Cosas (in)seguras
El crecimiento del número de dispositivos interconectados y capaces de proporcionar servicios avanzados, denominados en general Internet de las Cosas (Internet of Things, IoT) crecerá exponencialmente según las previsiones a lo largo de los próximos años. Si bien resulta atractiva la promesa de eficiencia y reducción de costes que ofrece esta evolución, también conlleva una fuerte preocupación por la seguridad. El reciente ataque informático que permitió a dos investigadores tomar el control remoto de un vehículo se difundió por todo el mundo como una llamada de atención a fabricantes y clientes: si un sistema tecnológicamente avanzado como un moderno coche de gama alta puede verse sometido a este tipo de ataques, ¿qué ocurrirá con los equipos interconectados más corrientes y de bajo presupuesto, que representan la mayor parte de los muchos miles de millones de sistemas que constituirán IoT? Aunque la amenaza es bien conocida, está por llegar la integración de la seguridad como elemento nativo que impulse el desarrollo y los procesos de negocio de forma similar a la protección funcional. Esto no es tranquilizador ni mucho menos, dado el número y el nivel de riesgos que presentan las vulnerabilidades de seguridad.
Nivel de proceso
Para que se consolide una cultura en la que coexistan eficientemente procesos que cuiden la seguridad y la protección hacen falta tiempo y esfuerzo. El enfoque aplicable es integral por naturaleza y no se puede limitar a determinados apartados o etapas de desarrollo. Por ejemplo, el ataque al vehículo aprovechó los puntos débiles y las vulnerabilidades a muchos niveles diferentes: arquitectura, permiso de servicio, algoritmos de generación de contraseñas, y así sucesivamente. Por tanto, un proceso sólido de desarrollo del producto debería integrar accio senes que fortalezcan la seguridad a todos los niveles, y que permitan su coexistencia eficiente con los requisitos de protección funcional ya de por sí exigentes. ¿Pero qué sucede si toda la atención se concentra únicamente en el desarrollo de software? En concreto, ¿cuáles son las opciones disponibles para un desarrollador encargado de programar una aplicación cuya protección es crítica y también se le exige que la aplicación sea segura? Suponiendo que se hayan aplicado unas medidas sólidas a los requisitos y las etapas de diseño, ha llegado el momento de escoger cómo traducirlas en un software eficiente, seguir y de alta integridad.
Enfoque hacia una protección crítica
La protección funcional tiene dos familias principales de estándares de referencia relacionados con la organización de la vida operativa del software: IEC61508 y sus estándares derivados; y DO178B/C junto con sus documentos relacionados, como DO330. IEC61508 se refiere a la protección funcional de sistemas relacionados con sistemas de protección eléctrica, electrónica y electrónica programable (EEPE). Cubre amenazas provocadas por el fallo de las funciones de protección. Dado que se puede aplicar a prácticamente cualquier sistema de protección que contenga un dispositivo EEPE, cubre un ámbito bastante amplio. Casi todos los principales estándares relacionados con la protección, excepto los de aviación, se derivan de IEC61508. DO178C y sus documentos relacionados DO330, DO331, DO332 y DO333 constituyen los estándares para aplicaciones aéreas. DO178C es obligatorio para cualquier proyecto de aviación que trate de conseguir la certificación FAA. DO178C está más centrado en el software que IEC61508; el nivel de protección del software (item development assurance level, IDAL) se determina tras realizar el análisis de protección y de riesgo y se divide en cinco niveles, de A (catastrófico) a E (sin efectos).
Para aplicaciones de protección crítica, la definición de criticidad del código ha sido ampliamente analizada y existen métodos estandarizados para calificarlo y definir formas adecuadas de manejar el proceso de desarrollo. Los niveles de integridad de protección (safety integrity levels, SIL) en IEC61508, SIL para el automóvil (automotive SIL, ASIL) en ISO26262, SIL para software (software SIL, SSIL) en EN50128 o IDAL en DO178C son ejemplos del mismo concepto: valorar la reducción del riesgo necesaria para una función dependiendo del análisis de riesgo y establecer las acciones a realizar para asegurar que se alcance este nivel. Casi todos los estándares de protección funcional reconocidos en el sector recomiendan la adopción de estándares de diseño y programación, dependiendo del SIL al que se dirijan. Aunque no haya una indicación dominante acerca del estándar de programación adecuado para protección funcional, una de las principales referencias es MISRA C. ISO26262-6 reconoce para el lenguaje C que MISRA C contempla muchos métodos necesarios para el diseño y la implementación del software, y su difusión cubre las principales aplicaciones de protección crítica, como maquinaria, medicina, energía potencial nuclear y ferrocarriles. La situación no es muy distinta para DO178B/C. Estos estándares exigen a una definición exhaustiva y documentar el proceso de desarrollo de software. Entre los requisitos para la documentación y el ciclo operativo se encuentran una planificación sólida y detallada, así como la aplicación del estándar de programación.
Estándares de programación como MISRA definen un subcon junto del lenguaje de destino. Esto evita o limita el uso de funciones y construcciones que pudieran llevar a una respuesta indefinida o indeterminada. En general se desaconsejan prácticas como tolerar código muerto o inalcanzable, que puede provocar problemas desde el punto de vista de la trazabilidad y la verificación. Los estándares de programación para aplicaciones de alta integridad suelen aplicar funciones que generan una respuesta predecible. Por ejemplo, MISRA C: 2012 desaconseja el uso de memoria dinámica ya que el uso indebido de las bibliotecas estándar para gestionar memoria alojada dinámicamente puede conducir a una respuesta indefinida. Si se decide utilizarlas, hay que prestar especial atención para evitar resultados impredecibles.
Seguridad de la aplicación
ISO/IEC27001: 2003 especifica los requisitos para establecer, implementar, mantener y mejorar continuamente un sistema de gestión de seguridad de información. Se basa en el modelo PDCA (plan, do, check, act; es decir, planificar, hacer, verificar, actuar), compartido con los principales estándares de gestión. Se utilizan la evaluación de riesgos y el análisis de impacto en el negocio para identificar y gestionar posibles riesgos para la confidencialidad, integridad y disponibilidad de información. ISO/ IEC27034: 2011 ofrece una visión más detallada de la seguridad de la aplicación ya que ofrece una guía para definir e implementar controles de seguridad de información mediante procesos integrados en el ciclo operativo de desarrollo del sistema.
Por tanto, no se trata de un estándar de desarrollo de aplicaciones de software pero se basa en los estándares existentes. Si pasamos a los estándares de programación orientados a la se guridad, el panorama es variado; se pueden encontrar estándares de programación segura para C y C++, así como para Java, Perl, PL/ SQL y otros. Existe un gran número de técnicas disponibles para evaluar la seguridad de código. Se puede hacer el seguimiento de diferentes elementos mediante análisis estático, dinámico y evaluación del tiempo de ejecución, seguimiento del flujo de datos y el flujo de control, análisis de vulnerabilidades, análisis de ejecutables y análisis heurístico. Estas técnicas pueden ser efectivas y fáciles de implementar dependiendo del soporte existente para el lenguaje seleccionado, basado en funciones, bibliotecas y otros. El principal punto de referencia para los estándares de programación de seguridad es CERT, que durante muchos años ha venido publicando estándares de programación para aplicación de seguridad. Los estándares de programación CERT están conectados directamente con las vulnerabilidades del mundo real propias del campo de la CWE (common weaknesses enumeration), una lista de los puntos débiles más habituales. CWE es un diccionario de tipos de debilidades de software desarrollado por una comunidad. La lista descargable se puede consultar en función de determinados contextos de vínculo. CWE es una recopilación más amplia de vulnerabilidades de seguridad de la información públicamente conocidas, denominada CVE (common vulnerabilities and exposures), es decir, vulnerabilidades y riesgos más habituales, y que actualmente es el estándar para la identificación de vulnerabilidades. Los identificadores CVE, también llamados CVE-ID, ofrecen puntos de referencia para el intercambio de datos dirigidos a productos y servicios de seguridad de la información. Resultan útiles para analizar la cobertura y la efectividad de herramientas y servicios para determinados tipos de vulnerabilidades. La base de datos nacional de vulnerabilidades del NIST, el fondo del gobierno de EE.UU. de datos de gestión de vulnerabilidades basada en estándares, contiene más de 73.000 CVE.
MISRA frente a CERT
MISRA C:2012 y CERT C se pueden considerar los campeones de la protección y la seguridad para el lenguaje C. En la siguiente tabla se presenta una comparación rápida. No existen diferencias notorias entre estándares de programación CERT y MISRA, pero es posible definir una estrategia que dé como resultado la aplicación efectiva de ambos el mismo código base. Herramientas como las de PRQA constituyen la forma más efectiva de implementar tal estrategia. Estas herramientas llevan a cabo un análisis a fondo del código de software para prevenir, detectar y eliminar defectos, y aplicar reglas de programación automáticamente con el fin de asegurar el cumplimiento de los estándares. Ofrecen la ventaja añadida de mejorar la capacidad de mantenimiento del software y por tanto reducir los costes totales de desarrollo.
Resumen
Diseñar una aplicación de protección crítica que también optimice la seguridad puede resultar complicado. Protección y seguridad exigen una serie de estrategias, procesos, herramientas y aptitudes que no pueden solaparse ni entrar en conflicto. Las herramientas de análisis automático de código constituyen una manera efectiva de evitar defectos de programación que puedan conllevar problemas de protección y vulnerabilidades de seguridad dentro de un enfoque integral.
