Aseguramiento de la seguridad en el SDLC para la internet de las cosas

Durante el Internet of Things (IoT) Village celebrado en la conferencia de seguridad DEF CON en agosto de 2016, 47 nuevas vulnerabilidades que afectaron a 23 dispositivos IoT de 21 fabricantes fueron revelados.¹ Entre estas 47 vulnerabilidades se encontraban vulnerabilidades relacionadas con software, por ejemplo, fallas de diseño, contraseñas codificadas, secretos de configuración, problemas criptográficos y Defectos de codificación comunes, tales como desbordamientos de búfer, entradas invalidadas e inyección de comandos.

El software que se ejecuta en los dispositivos, los pórticos, las aplicaciones móviles y de centro de datos y las interfaces de programa de aplicación (API) de interfaz desde las que se consumen los servicios deben estar sujetos a una garantía para garantizar que estén libres de defectos de seguridad. En este artículo se describen las técnicas y procesos de aseguramiento involucrados para asegurar dichas aplicaciones y proporcionar orientación sobre la implementación en todo el entorno de IoT.

Componentes de software IoT

Cada componente IoT tiene su propio software. ¿Cómo se puede asegurar que, mientras se ejecuta en un entorno real, el componente no está permitiendo a las personas malintencionadas hackear el software y tener acceso a los datos e información recopilados por los dispositivos? El ciclo de vida de desarrollo de software seguro (S-SDLC) es la respuesta a la seguridad de software. La Figura 1 representa los componentes IoT típicos.

La seguridad debe estar integrada en el ciclo de desarrollo de los componentes IoT, ya sean el firmware del dispositivo, el código fuente del pórtico de enlace, el código fuente de la aplicación o el código fuente de la API.

Las aplicaciones en un entorno IoT típico pueden caer en una de las siguientes categorías:

1. Aplicaciones de dispositivos que residen en los nodos y pórticos, por ejemplo, una aplicación basada en node.js o Python que se ejecuta en un medidor de energía inteligente
2. Controlar aplicaciones que controlan y regulan el entorno IoT, por ejemplo, aplicaciones basadas en web o no basadas en web, creadas en Java, Dot Net, Perl o PHP, que habitualmente residen en el centro de datos o en el sistema operativo de aplicaciones móviles, desde donde los dispositivos pueden ser controlado
3. Consumir aplicaciones que reciben datos de los dispositivos para procesamiento adicional, por ejemplo, aplicaciones web o no basadas en web, que habitualmente residen en el centro de datos, que realizan análisis sobre los datos recibidos
4. Servicios de retransmisión que formatean y transfieren datos entre diferentes componentes, por ejemplo, API, servicios web que transportan los datos a través de dispositivos, aplicaciones y otros componentes IoT

Hay dos categorías de vulnerabilidades relacionadas con el software. Esos son:

1. Una interfaz web insegura, que podría permitir que se produzcan algunos de los siguientes ataques comunes:
   • Ataque de inyección—Ejecución maliciosa de scripts, consultas de bases de datos, comandos de nivel de sistema inyectados a las aplicaciones
   • Secretos no protegidos—Secretos de configuración de texto claro/no encriptado, llaves y contraseñas
   • Escalamiento de privilegios—Elevación de privilegios de usuario y suplantación de usuarios
2. Software/firmware inseguro que permite a los usuarios malintencionados cambiar el software o comprometer el dispositivo, que puede usarse como un dispositivo BOT (robot de software):
   • Corrupción de firmware—Envío de firmware malintencionado que podría formatear incorrectamente la Lógica del dispositivo o instalar una puerta trasera
   • Firmware no firmado—Obligar a los dispositivos a descargar firmware de fuentes no autorizadas sin validación

Seguir un enfoque seguro de SDLC mitigaría las fallas comunes de codificación y las vulnerabilidades de software relacionadas con los componentes de IoT.

Pasos seguros para solucionar defectos de codificación comunes y vulnerabilidades de software

El costo de corregir un error de seguridad varía dependiendo de dónde se descubre. Si se descubre en el entorno de producción, el costo de su corregirlo incluiría los costos tangibles del esfuerzo del desarrollador, el esfuerzo del probador, el esfuerzo de prueba de aceptación del usuario y el esfuerzo de despliegue, y el costo intangible de la reputación y la confianza del cliente. Si se descubre durante la fase de diseño, entonces es muy fácil corregir la falla de diseño e introducir una medida de seguridad durante la fase de desarrollo. El costo de corregir un defecto postproducción es aproximadamente cuatro veces más que corregirlo en la etapa de desarrollo.²

La seguridad del software IoT es el nivel de confianza de que el software está libre de vulnerabilidades (ya sea intencionalmente diseñadas dentro del software o insertadas accidentalmente en cualquier momento durante su ciclo de vida) y el software funciona de la manera prevista. El aseguramiento de la seguridad de las aplicaciones de IoT puede lograrse mejor mediante la adopción de una estrategia de defensa en profundidad que, a su vez, garantiza tener una práctica segura de SDLC (figura 2). La intención principal es construir la seguridad dentro del ciclo de vida de estas aplicaciones desde el punto cero que potencialmente y gradualmente reduce las fallas en seguridad, diseño, Implementación y despliegue. El cumplimiento adecuado de estas mejores prácticas de aseguramiento dará lugar a aplicaciones carentes de vulnerabilidades que pudieran haber sido introducidas accidental o intencionalmente en cualquier punto de tiempo en su ciclo de vida.

Comienzo y requisitos

La gestión eficaz de la seguridad de los componentes involucrados es un área de enfoque crítico porque un entorno IoT típico se difunde ampliamente, tanto físicamente (con numerosos dispositivos) como lógicamente (con múltiples tecnologías y aplicaciones). Esta gestión eficaz sólo puede lograrse con un inventario adecuado de lo que se va a gestionar, como es:

• Categoría por tipo de desarrollo—La categoría por tipo de desarrollo depende de dónde se desarrolló el software/API, por ejemplo, desarrollo interno, desarrollo de proveedores/socios, comercial/comercial empaquetado o de código abierto. Esto también es vital para derivar la gobernanza de la seguridad y las políticas con las que se adhieren para cada uno de estos tipos.
• Categoría por tipo de aplicación—La categoría según el tipo de aplicación depende de dónde resida el software o la API, por ejemplo, dispositivo (nodos o pórticos), servidores de la nube/data center, móviles o equipos de escritorio. Esto dictaría las guías de codificación seguras, listas de comprobación, configuración de seguridad aplicable a cada uno de los tipos de aplicación en consonancia con las políticas de seguridad.

Las puertas de control S-SDLC, como la revisión de diseño/modelado de amenazas en la fase de diseño o las pruebas de seguridad de aplicaciones estáticas en la fase de desarrollo, tienen que ser obligatorias. Todo el ciclo SDLC tiene que ser monitoreado y administrado para una mejora continua en la entrega de software rápido pero seguro a la producción. Estas soluciones administradas son vitales para facilitar el proceso de seguridad y son altamente recomendables.

Dependiendo de los niveles de riesgo percibidos para las aplicaciones, las puertas de control pueden ser derivadas. Las implementaciones incrementales y rápidos requieren supervisión a lo largo del ciclo de vida del desarrollo hasta su funcionamiento, especialmente en el caso de mejorar mediante DevOps, junto con un criterio de aceptación bien definido desde el punto de vista de la seguridad.

Las sesiones de concientización sobre la seguridad de las aplicaciones, las amenazas y las brechas recientes deben realizarse temprano en el ciclo de vida y en forma regular para impartir la necesidad de hacer cumplir la seguridad en las aplicaciones en todas las etapas del ciclo de vida.

Fase de diseño

Durante la fase de diseño, la arquitectura y el diseño de la solución IoT se revisarán utilizando técnicas de modelado de amenazas. Los actores de amenaza y los posibles escenarios de amenaza deben ser enumerados para cada uno de los componentes de IoT. Por ejemplo, un escenario de amenaza podría ser un posible problema de integridad de datos debido a la falta de controles de autenticación en el dispositivo. Después de la enumeración de las amenazas, las contramedidas pueden ser clasificadas y recomendadas.

El enfoque estándar para el modelado de amenazas utilizando los modelos STRIDE y DREAD es el siguiente:

• STRIDE—Categorización de amenazas considerando spoofing, adulteración, repudio, revelación de información, denegación de servicio y elevación de privilegios
• DREAD—Atributos de clasificación de amenaza considerando la posibilidad de descubrir, reproducir, explotar, usuarios afectados y potencial de dañol

Este método será suficiente para revisar la arquitectura IoT, con una amenaza adicional centrada en la seguridad física de los dispositivos. Las amenazas comunes aplicables a la seguridad física son el robo de dispositivos, la clonación de dispositivos y el acceso físico no autorizado. La principal diferencia en el análisis del modelo de amenaza estándar y revisiones de diseño es la aplicación del conocimiento de las amenazas específicas de la industria. La Figura 3 muestra algunas de estas amenazas únicas de la industria.

Los controles que se deben incorporar en las aplicaciones IoT y las API son:

• Validación de entrada—Manejo de datos de entrada de usuarios, aplicaciones y servicios
• Autenticación—Identificación y verificación de usuarios y tráfico
• Autorización—Reforzar el control de acceso para todas las solicitudes a la aplicación
• Gestión de la configuración—Protección de datos de configuración y metadatos, acceso a la consola
• Seguridad de datos y privacidad—Seguridad de datos sensibles y confidenciales, como información de salud protegida u otra información de identificación personal
• Gestión de sesiones—Iniciar, gestionar y finalizar las sesiones de una aplicación con seguridad
• Criptografía—Uso de algoritmos de encriptación, hash y de intercambio de claves fuertes, certificados digitales y firmas
• Gestión de excepciones—Manejo seguro de excepciones de las aplicaciones
• Auditoría y registro —Registro de todos los eventos con los atributos necesarios para la rendición de cuentas
• Seguridad de la comunicación—Seguridad del tráfico hacia y desde la aplicación
• Disponibilidad—Manejo seguro de cargas en las aplicaciones

Los resultados de la revisión de diseño y las actividades de modelado de amenazas deben hacer cumplir la incorporación de estándares y marcos autorizados, módulos, API y especificaciones de diseño, por ejemplo, Spring Security para control de acceso o AES 256 o superior para el cifrado. Esto asegura una línea de base segura en el diseño, que fluirá a través del SDLC, lo que reduce considerablemente el número de defectos de seguridad en fases posteriores. Los marcos o APIs no autorizados o no verificados que se extraen de los repositorios públicos deben ser evitados. En caso de que exista una necesidad comercial para el uso de dichos módulos, se deben realizar los siguientes pasos:

• Enumerar si existen vulnerabilidades y explotaciones conocidas asociadas con la base de código.
• Asegúrese de que sólo se utiliza la versión actualizada.
• Analizar minuciosamente el código y corregir las vulnerabilidades (fase de desarrollo).

Las soluciones de diseño de seguridad para las amenazas percibidas y estándar tienen que ser cuidadosamente pesadas y proporcionadas basadas en múltiples factores, por ejemplo, casos de uso involucrados, entrada y salida, tipo de aplicación y tecnología, y especificaciones del dispositivo. Educar a los arquitectos y desarrolladores de aplicaciones en las directrices de diseño seguro e incorporar estas directrices en el diseño también mejorará en gran medida la línea base de seguridad.

Fase de desarrollo

Durante la fase de desarrollo, ya se trate de un desarrollo ágil o de cascada, se debe impartir formación sobre codificación segura basada en el proyecto de seguridad Open Web Application (OWASP) Top 10³ o Top 9,⁴ SANS Top 25,⁵ o CERT⁶ a todos los desarrolladores y tiene que ser obligado a intervalos regulares para mantenerse al tanto de los últimos avances contra nuevos ataques y amenazas. Los desarrolladores también deben ser entrenados en la programación de sistemas embebidos, o los programadores de sistemas integrados se utilizan para diseñar las aplicaciones que están integradas específicamente en los dispositivos/hardware. Tales aplicaciones pueden ser completas o mejoras a las aplicaciones existentes.

Además de las vulnerabilidades estándar y prácticas de codificación inseguras en los lenguajes de programación comunes (por ejemplo, Java, J2EE, PHP, .NET), las especificaciones específicas de código de hardware y código que rigen los sistemas embebidos (Embedded C/C ++) deben ser inspeccionados sobre la base de las normas de codificación segura mencionadas anteriormente. Las firmas de vulnerabilidad personalizadas y los casos de prueba también pueden desarrollarse dependiendo de la naturaleza de la lógica implementada, las API y las librerías que se encuentran en los dispositivos que gobiernan el hardware subyacente, el almacenamiento persistente y no persistente, el ciclo de vida del firmware, las técnicas de codificación y los defectos que residen en fuentes abiertas.

La concientización también debe ser impartida a los desarrolladores en el ataque de IoT y las superficies de amenaza, porque el software que se espera ellos desarrollen se supone que interactúan con los objetos del mundo real. Los entornos de desarrollo integrados de software (IDE) deben estar habilitados con plugins de revisión de código seguro para realizar comprobaciones de seguridad durante el tiempo de check-out. Un analista de seguridad independiente podría revisar el código estable para cualquiera de las fallas de seguridad mencionadas anteriormente, acceso no autorizado a secretos y problemas de sesión de clave secreta.

Para los despliegues rápidos e incrementales, el ejercicio de puertas de control formales (como en los modelos de cascada tradicionales) podría no ser prácticamente factible. La integración continua de mejores prácticas de seguridad, herramientas y evaluaciones para ayudar en la entrega continua debe ser practicada e implementada con la automatización. En otras palabras, el desarrollo continuo es y siempre debe ir acompañado de evaluaciones automatizadas continuas para asegurar que todos los cambios de software y API sean sometidos a un control de seguridad y solo una construcción autorizada se implemente en la siguiente fase. Las construcciones erróneas se deben devolver automáticamente para solucionar las vulnerabilidades.

Evaluar un software o una API puede lograrse más eficazmente cuando el código fuente está disponible, ya que puede ser inspeccionado directamente en busca de vulnerabilidades. Cuando se utilizan productos de blackbox, cuyo diseño y código fuente no están disponibles, sólo se puede realizar una evaluación de vulnerabilidad estándar en las aplicaciones o API en la fase de prueba. Debe prestarse la debida atención al software de código abierto no estándar y las API que se aprovechan de los repositorios públicos, como se especifica en la fase de diseño. Dado que tal software y API no pueden haber sido sometidos a un desarrollo seguro, deben ser examinados a fondo por vulnerabilidades conocidas y personalizadas. Este examen debe utilizar herramientas que están especializados en la identificación de vulnerabilidades en software de código abierto.

Mientras que los requisitos sirven como historias de usuarios (en los modos Agile), los desarrolladores pueden aprovechar los complementos y las herramientas que se integran con los servidores de compilación (por ejemplo, Jenkins, Bamboo) y realizar evaluaciones sobre la marcha basadas en registros. Los casos de prueba y la lista de vulnerabilidades deben ser revisados continuamente y devueltos al ciclo, y el ciclo debe pasar a las siguientes fases basándose en los criterios de aceptación. El mismo modo de suministro continúo potenciado mediante evaluaciones continuas puede aprovecharse también para la fase de prueba.

Fase de prueba

Dependiendo del tipo de aplicación de IoT y de las API en vigor, la necesidad y el tipo de evaluaciones de seguridad que se realizarán se pueden decidir como corresponde. Algunas evaluaciones típicas que tienen que ser realizadas incluyen.

• Evaluación de la vulnerabilidad o prueba dinámica de seguridad de aplicaciones (DAST)—Asegurar la entrada y el tráfico de/a la aplicación se prueben a fondo para enumerar las vulnerabilidades que prevalecen según lo dictado por estándares tales como OWASP (Web Top 10,⁷ IoT Top 10,⁸ Móvil Top 10,⁹ grueso cliente), Web Application Security Consorcio (WASC)¹⁰ y SANS Top 25.¹¹ Estos deben realizarse en todas las aplicaciones siguientes utilizadas en el entorno IoT:
  • Aplicaciones web
  • Aplicaciones móviles
  • Aplicaciones de dispositivo
  • Thick Clients
  • Servicios Web y API (sencillos y transferencia de estado representacional)
• Ingeniería inversa y depuración—Invierte las aplicaciones desde sus binarios; Interpretar cualquier lógica oculta, controles y secretos; y volver a su estado original después de pasar por alto y alterar la lógica oculta. Esto será más aplicable a las aplicaciones móviles y las aplicaciones de dispositivos, donde se alojan gran parte de la lógica y los controles de la aplicación.

Como con cada fase SDLC, la fase de prueba asociada con las aplicaciones debe consistir en las actividades de evaluación relacionadas con los puntos finales físicos (por ejemplo, sensores y nodos). El riesgo físico puede variar entre cualquier extremo dependiendo de los casos de uso involucrados. Algunos ejemplos de casos de abuso son:

• Anulación de la inscripción y registro de dispositivos
• Clonación y robo de dispositivos
• Simulación de movimientos físicos para evadir Sensores y actuadores
• Abuso de protocolos, por ejemplo, ZigBee, Z-wave, 6LoWPAN

Dependiendo de los casos de uso o de los flujos funcionales percibidos para cada dispositivo y aplicación, los casos de prueba de vulnerabilidad deben diseñarse según corresponda. La metodología de la prueba debe considerar todos los casos de uso pertenecientes al IoT, y cada caso de uso debe tener uno o más casos de uso indebido (caso de prueba de seguridad) asociados con él. Siempre que sea posible, los casos de pruebas de vulnerabilidad y los scripts de prueba deben iniciarse a través de la automatización, a medida que las aplicaciones se desactiven mediante la funcionalidad y las pruebas de rendimiento. Casos de uso más lógicos y de negocios deben ser apuntados manualmente en paralelo. El enfoque estándar para las pruebas de seguridad se detalla en la figura 4.

El entorno de prueba debe ser lo suficientemente escalable como para tener en cuenta la generación de datos y la agregación que se alimentará y consumirá por estas aplicaciones para imitar el mundo real. El entorno en el que se desplegarán las aplicaciones y los dispositivos se extenderá y recibirá datos de muchos puntos finales.

Vale la pena señalar que las pruebas de seguridad para un entorno de IoT no se detienen sólo con las aplicaciones. El alcance es tan amplio como el número de componentes implicados, por ejemplo, sensores, actuadores, pórticos y la infraestructura subyacente. Las principales áreas de interés deben incluir:

• Dispositivos inteligentes—Desmontaje y revisión de dispositivos, extracción de memoria, ataques a buses y fuzzing a través de puertos físicos
• Firmware—Análisis estático y dinámico, reversión, inyección de firmware malicioso y firma
• Comunicación—Análisis de tráfico, decodificación y fuzzing de protocolos, repeticiones de paquetes y ataques criptográficos
• Infraestructura (fase de despliegue)—Evaluación de la vulnerabilidad, pruebas de penetración y endurecimiento

Fase de implementación

Mientras que la mayoría de las aplicaciones fuera del dispositivo se adhieren a las directrices comunes de endurecimiento del entorno y se someten a pruebas de penetración, las aplicaciones en dispositivos requieren consideraciones especiales para una implementación segura.

Los fabricantes de dispositivos deben cumplir con las directrices de seguridad establecidas por los respectivos grupos de consorcios industriales (por ejemplo, el Instituto de Ingenieros Eléctricos y Electrónicos [IEEE] para la energía, la Administración de Alimentos y Medicamentos de los Estados Unidos [FDA] la Sociedad de Ingenieros Automotrices [SAE] para dispositivos de automoción, la Asociación de Electrónica de Consumo [CEA] para dispositivos electrónicos de consumo). Los dispositivos comunes que prevalecen en las industrias son:

• Energía—Red inteligente, medidores inteligentes, relés, controladores lógicos programables (PLCs)
• Dispositivos médicos—Marcapasos inteligentes, desfibriladores
• Vehículos automotores—Inteligentes o sin conductor
• Electrónica de consumo—Electrodomésticos inteligentes

Así como las API y las aplicaciones se someten a un SDLC seguro, los fabricantes deben asegurarse de que estos dispositivos se someten a un ciclo de vida de desarrollo seguro, desde el diseño del circuito del dispositivo, el montaje y la configuración hasta el lanzamiento a clientes.

Los puertos lógicos y físicos no deseados deben estar desactivados en dichos dispositivos y servidores, y los procedimientos de seguridad física deben emplearse estrictamente para detectar y prevenir ataques como robo de dispositivos/ sensores, manipulación indebida y acceso no autorizado. Todos estos intentos deben ser monitoreados, alertados, registrados y defendidos de manera efectiva.

Para aprovechar los servicios basados en la nube (especialmente en el caso de Software as a Service), donde las aplicaciones se exponen como servicios y API, los clientes deben trabajar con los proveedores de servicios para obtener los resultados de la evaluación y auditoría de las aplicaciones y la infraestructura en la que se confía para proporcionar garantías.

La evaluación de la vulnerabilidad y las pruebas de penetración deben llevarse a cabo en todos los componentes del entorno IoT, especialmente los servidores que alojan las aplicaciones y las API para identificar y mitigar las vulnerabilidades relacionadas con el sistema operativo y la plataforma que podrían dar lugar a un compromiso. Las pruebas de penetración en el mundo real también deben centrarse en servir el tráfico de carga a los dispositivos y las aplicaciones.

Operaciones y estado estable

Al principio de las fases iniciales, es imprescindible una solución centralizada de gestión y monitorización para rastrear el entorno IoT y sus componentes (aplicaciones, dispositivos, sensores). La automatización de la vulnerabilidad, la gestión de parches y de la configuración debe ejercerse. Cada aplicación y cada nodo debe ser sometido a un monitoreo continuo para ayudar en la detección automatizada de amenazas y ataques y respuesta, lo que aumentará la confianza adicional en la seguridad. Además, se deben realizar evaluaciones continuas de la vulnerabilidad, pruebas de penetración y mantenimiento de la seguridad para hacer frente a los ataques y amenazas cada vez mayores y defendido como corresponde.

Caso de uso de negocio
Un sistema típico de estacionamiento de vehículos consistente en dispositivos y aplicaciones ascendentes se sometió a un aseguramiento de seguridad a través de SDLC seguro. La arquitectura de alto nivel de IoT se representa en la figura 5.

Los sensores del dispositivo identifican la disponibilidad de un lugar de estacionamiento detectando el campo electromagnético creado por la presencia o ausencia de un vehículo. Estos dispositivos alimentan los datos de estacionamiento a un pórtico local a través del bus de datos conectado desde ellos y, a continuación, el pórtico se comunica con la aplicación del cliente en la nube. Desde la nube, los usuarios pueden extraer, consultar y reservar el lugar de estacionamiento mediante aplicaciones móviles. Las aplicaciones que fueron sujetas a garantía de seguridad son:

1. Aplicaciones del dispositivo—D1, D2, D3, D4
2. Clientes pesados basado en Node.js—Gestión de los sensores electromagnéticos conectados a ellos
3. Aplicación de Gateway—Lógica de middleware Java
4. Aplicación en la nube—Java/J2EE web y móvil
5. Aplicaciones móviles—Aplicaciones para Android e iOS

Todas las aplicaciones antes mencionadas fueron sometidas a un SDLC seguro, y las vulnerabilidades identificadas en cada etapa del ciclo de vida se abordaron antes de pasar a la siguiente fase. Las aplicaciones móviles también fueron diseñadas de forma inversa para desmontarlas y depurarlas para enumerar las vulnerabilidades relacionadas con la seguridad del almacenamiento de datos, el control de acceso y los secretos confidenciales.

Los servidores de puerta de enlace y de nube que contenían los niveles de aplicación se sometieron a pruebas de penetración de red y el endurecimiento de la configuración se llevó a cabo en los servidores de puerta de enlace y de nube que alojaban los niveles de aplicación para identificar y prevenir las vulnerabilidades en las plataformas y sistemas operativos.

Además, también se realizó la prueba de penetración física, por ejemplo, engañar a los sensores, clonar o suplantar a los sensores, y manipular el hardware. Los casos de abuso fueron diseñados sobre la base de las reglas de negocio establecidas por el cliente y ejecutadas según corresponda en la fase de pruebas.

Los siguientes son el número de defectos de seguridad enumerados en las respectivas etapas SDLC:

• Diseño: 41
• Desarrollo: 26
• Prueba: 17
• Implementación: 11

Los siguientes son datos típicos de los rangos de costo por defecto¹² (en dólares EEUU):

• Requermientos: $250
• Diseño: $500
• Codificación, prueba e implementación: $1,250
• Post-implementación: $5,000

Costo total incurrido en la fijación de defectos: (41 defectos * $ 250) + ([26 defectos + 17 fallas + 11 fallas] * $ 1.250) = $ 77.750.

Si las aplicaciones no hubieran sido sometidas a un SDLC seguro, todos los defectos se habrían propagado a la compilación final y se habrían acumulado en la producción:

• Número total de defectos: 41+26+17+11 = 95
• Costo total que habría sido incurrido para arreglos postproducción: 95 defectos *$5,000 = $475,000

Se han alcanzado los ahorros totales de costos $475,000 – $77,750 = $397,250

En otras palabras, el costo que se habría incurrido para corregir los defectos después de la producción sería aproximadamente cinco veces el costo de la corrección de los defectos en las fases individuales del SDLC. Obsérvese que las cantidades anteriores son un indicador aproximado de los costos involucrados y no de las cifras reales.

Conclusión

El aseguramiento de la seguridad de las aplicaciones IoT y las API debe integrarse en todas las etapas del SDLC y debe ser continuo. Es crítico mantener un inventario y una configuración apropiados de todos los componentes de la aplicación que construyen el ambiente IoT. La supervisión o verificación de la seguridad debe formar parte de la etapa de requisitos. Las medidas proactivas tales como las sesiones de capacitación y el uso de estándares de seguridad, pautas y listas de verificación tienen que ser obligatorias en todas las etapas aplicables, y las medidas de validación se logran realizando revisiones y evaluaciones en todas las etapas.

Las herramientas de evaluación de la seguridad deben integrarse en los ciclos de desarrollo y garantía de la calidad para activar las evaluaciones sobre la marcha y, siempre que sea posible, emplear la automatización. Sólo deben utilizarse marcos, estándares y API autorizados, y se debe ejercer el debido cuidado en los componentes de código abierto. Para contrarrestar las vulnerabilidades y amenazas más recientes, las evaluaciones continuas, el seguimiento de amenazas y el parche de seguridad deben realizarse una vez que los dispositivos IoT, las aplicaciones y las API estén expuestos a la producción. Tener seguridad incorporada en el ciclo de desarrollo de IoT garantiza que los problemas de seguridad conocidos son corregidos y los nuevos se evitan con las medidas más eficaces, proporcionando así seguridad garantizada para los usuarios finales.

Notas Finales

¹ Dark Reading, “IoT Village at DEF CON 24 Uncovers Extensive Security Flaws in Connected Devices,” press release, 16 September 2016, www.darkreading.com/attacks-breaches/iot-village-at-def-con-24-uncovers-extensive-security-flaws-in-connected-devices/d/d-id/1326928
² Jones, C.; Software Quality Metrics: Three Harmful Metrics and Two Helpful Metrics, Project Performance International, 6 June 2012
³ Open Web Application Security Project, Top 10 2013-Top 10, https://www.owasp.org/index.php/Top_10_2013-Top_10
⁴ Open Web Application Security Project, The OWASP Code Review Top 9, https://www.owasp.org/index.php/The_Owasp_Code_Review_Top_9
⁵ Martin, B.; M. Brown; A. Paller; D. Kirby; 2011 CWE/SANS Top 25 Most Dangerous Software Errors, The MITRE Corporation, 13 September 2011, http://cwe.mitre.org/top25/
⁶ Confluence, SEI CERT Coding Standards, Software Engineering Institute at Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards
⁷ Op cit, OWASP Top 10 2013-Top 10
⁸ Open Web Application Security Project, OWASP Internet of Things Project, https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Vulnerabilities
⁹ Open Web Application Security Project, Mobile
Top 10 2016-Top 10, https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
¹⁰ Web Application Security Consortium, “The WASC Threat Classification v2.0,” Threat Classification Wiki, http://projects.webappsec.org/w/page/13246978/Threat%20Classification
¹¹ Op cit, Martin
¹² Op cit, Jones