Inyección de fallas

Probar cómo se comportan los sistemas informáticos bajo tensiones inusuales

En informática , la inyección de fallas es una técnica de prueba para comprender cómo se comportan los sistemas informáticos cuando se estresan de manera inusual. Esto se puede lograr utilizando medios físicos o basados ​​en software, o mediante un enfoque híbrido. ^[1] Las inyecciones de fallas físicas ampliamente estudiadas incluyen la aplicación de altos voltajes, temperaturas extremas y pulsos electromagnéticos en componentes electrónicos, como la memoria de la computadora y las unidades centrales de procesamiento . ^{[2] [3]} Al exponer los componentes a condiciones más allá de sus límites operativos previstos, los sistemas informáticos pueden verse obligados a ejecutar incorrectamente instrucciones y corromper datos críticos.

En las pruebas de software , la inyección de fallas es una técnica para mejorar la cobertura de una prueba mediante la introducción de fallas en las rutas del código de prueba; en particular, rutas de código de manejo de errores , que de otro modo rara vez se seguirían. A menudo se utiliza con pruebas de estrés y se considera ampliamente como una parte importante del desarrollo de software sólido . ^[4] Las pruebas de robustez ^[5] (también conocidas como pruebas de sintaxis, fuzzing o pruebas de fuzz ) son un tipo de inyección de fallas comúnmente utilizada para probar vulnerabilidades en interfaces de comunicación como protocolos, parámetros de línea de comando o API.

La propagación de una falla hasta una falla observable sigue un ciclo bien definido. Cuando se ejecuta, una falla puede causar un error, que es un estado no válido dentro de los límites del sistema. Un error puede causar más errores dentro de los límites del sistema; por lo tanto, cada nuevo error actúa como una falla o puede propagarse hasta los límites del sistema y ser observable. Cuando se observan estados de error en los límites del sistema, se denominan fallas. Este mecanismo se denomina ciclo falla-error-falla ^[6] y es un mecanismo clave en la confiabilidad .

Historia

La técnica de inyección de fallos se remonta a la década de 1970 ^[7], cuando se utilizó por primera vez para inducir fallos a nivel de hardware. Este tipo de inyección de fallas se llama inyección de fallas implementadas por hardware (HWIFI) e intenta simular fallas de hardware dentro de un sistema. Los primeros experimentos con fallos de hardware no implicaron más que cortocircuitar conexiones en placas de circuitos y observar el efecto en el sistema (fallos de puente). Se utilizó principalmente como prueba de la confiabilidad del sistema de hardware. Posteriormente se desarrolló hardware especializado para ampliar esta técnica, como dispositivos para bombardear áreas específicas de una placa de circuito con radiación intensa. Pronto se descubrió que las técnicas de software podían inducir fallos y que algunos aspectos de esta técnica podían ser útiles para evaluar sistemas de software. En conjunto, estas técnicas se conocen como inyección de fallas implementadas por software (SWIFI).

Inyección de fallas implementada por software

Las técnicas SWIFI se pueden clasificar en dos tipos: inyección en tiempo de compilación e inyección en tiempo de ejecución.

La inyección en tiempo de compilación es una técnica de inyección en la que se modifica el código fuente para inyectar fallas simuladas en un sistema. Un método se llama prueba de mutación y cambia las líneas de código existentes para que contengan fallas. Un ejemplo simple de esta técnica podría ser cambiar a = a + 1aa = a – 1

La mutación del código produce fallas que son muy similares a las que los programadores agregan involuntariamente.

Un refinamiento de la mutación de código es la inyección de error de inserción de código , que agrega código, en lugar de modificar el código existente. Esto generalmente se hace mediante el uso de funciones de perturbación, que son funciones simples que toman un valor existente y lo perturban mediante alguna lógica para convertirlo en otro valor, por ejemplo.

 int pFunc ( valor int ) { valor de retorno + 20 ; }         int main ( int argc , char * argv []) { int a = pFunc ( aFunction ( atoi ( argv [ 1 ]))); if ( a > 20 ) { /* hacer algo */ } else { /* hacer algo más */ } }                      

En este caso, pFunc es la función de perturbación y se aplica al valor de retorno de la función que se ha llamado introduciendo una falla en el sistema.

Las técnicas de inyección en tiempo de ejecución utilizan un activador de software para inyectar una falla en un sistema de software en ejecución. Las fallas se pueden inyectar a través de varios métodos físicos y los activadores se pueden implementar de varias maneras, tales como: Activadores basados ​​en tiempo (cuando el temporizador alcanza un tiempo específico, se genera una interrupción y el controlador de interrupciones asociado con el temporizador puede inyectar el falla. ); Activadores basados ​​en interrupciones (las excepciones de hardware y los mecanismos de captura de software se utilizan para generar una interrupción en un lugar específico del código del sistema o en un evento particular dentro del sistema, por ejemplo, el acceso a una ubicación de memoria específica).

Las técnicas de inyección en tiempo de ejecución pueden utilizar varias técnicas diferentes para insertar fallas en un sistema a través de un disparador.

• Corrupción del espacio de memoria: Esta técnica consiste en corromper la RAM, los registros del procesador y el mapa de E/S.
• Técnicas de interposición de llamadas al sistema: se ocupa de la propagación de fallas desde las interfaces del kernel del sistema operativo hasta el software del sistema en ejecución. Esto se hace interceptando llamadas al sistema operativo realizadas por software a nivel de usuario e inyectándoles fallas.
• Inyección de fallas a nivel de red: esta técnica se ocupa de la corrupción, pérdida o reordenación de paquetes de red en la interfaz de red.

Estas técnicas a menudo se basan en las funciones de depuración proporcionadas por las arquitecturas de procesadores de computadoras.

Inyección de fallos de software de protocolo

Los sistemas de software complejos, especialmente los sistemas distribuidos de múltiples proveedores basados ​​en estándares abiertos, realizan operaciones de entrada/salida para intercambiar datos a través de intercambios estructurados y con estado conocidos como " protocolos ". Un tipo de inyección de fallas que es particularmente útil para probar implementaciones de protocolos (un tipo de código de software que tiene la característica inusual de que no puede predecir ni controlar su entrada) es el fuzzing . Fuzzing es una forma especialmente útil de prueba de caja negra, ya que las diversas entradas no válidas que se envían al sistema de software no dependen de los detalles del código que se ejecuta dentro del sistema y no se crean en función del conocimiento de ellos.

Inyección de fallas implementada por hardware

Esta técnica se aplicó sobre un prototipo de hardware. Los probadores inyectan fallas cambiando el voltaje de algunas partes de un circuito, aumentando o disminuyendo la temperatura, bombardeando la placa con radiación de alta energía, etc.

Características de la inyección de fallas.

Las fallas tienen tres parámetros principales. ^[8]

• Tipo: ¿Qué tipo de falla se debe inyectar? Por ejemplo, apegarse al valor, retardo, ignorar algunas funciones, ignorar algunos parámetros/variables, fallas aleatorias, falla de polarización, ruido, etc. La amplitud de cada falla también es importante.
• Hora: ¿Cuándo se debe activar? Por ejemplo, el tiempo de activación de la falla o la condición de activación de la falla.
• Ubicación: ¿Dónde debería estar en el sistema? Por ejemplo, fallo en el enlace/conexión entre sistemas, fallos dentro de sistemas/subsistemas/función, etc.

Estos parámetros crean el ámbito del espacio de fallas. El ámbito del espacio de fallas aumentará exponencialmente al aumentar la complejidad del sistema. Por lo tanto, el método tradicional de inyección de fallas no será aplicable en los sistemas ciberfísicos modernos, porque serán muy lentos y encontrarán una pequeña cantidad de fallas (menos cobertura de fallas). Por lo tanto, los evaluadores necesitan un algoritmo eficiente para elegir fallas críticas que tengan un mayor impacto en el comportamiento del sistema. Por lo tanto, la principal pregunta de investigación es cómo encontrar fallas críticas en el ámbito del espacio de fallas que tengan efectos catastróficos en el comportamiento del sistema. A continuación se presentan algunos métodos que pueden ayudar a la inyección de fallas a explorar eficientemente el espacio de fallas para alcanzar una mayor cobertura de fallas en menos tiempo de simulación.

• Análisis de sensibilidad: ^[9] En este método, se ha utilizado el análisis de sensibilidad para identificar las señales más importantes que tienen un mayor impacto en la especificación del sistema. Al identificar esas señales o parámetros importantes, la herramienta de inyección de fallas se centrará en esas señales efectivas en lugar de centrarse en todas las señales del sistema.
• Aprendizaje por refuerzo: ^[10] En este método, el algoritmo de aprendizaje por refuerzo se ha utilizado para explorar eficientemente el espacio de fallas y encontrar fallas críticas.

Herramientas de inyección de fallos

Aunque este tipo de fallas se pueden inyectar manualmente, la posibilidad de introducir una falla no deseada es alta, por lo que existen herramientas para analizar un programa automáticamente e insertar fallas.

Herramientas de investigación

Se han desarrollado varias herramientas SWIFI y aquí se ofrece una selección de ellas. Seis herramientas de inyección de fallas comúnmente utilizadas son Ferrari, FTAPE, Doctor, Orchestra, Xception y Grid-FIT.

• MODIFI (MODel-Implemented Fault injection) es una herramienta de inyección de fallos para la evaluación de la robustez de los modelos de comportamiento de Simulink. Admite el modelado de fallas en XML para la implementación de modelos de fallas específicos del dominio. ^[11]
• Ferrari (Fault and ERRor Automatic Real-time injection) se basa en trampas de software que inyectan errores en un sistema. Las trampas se activan mediante una llamada a una ubicación de memoria específica o un tiempo de espera. Cuando se llama a una trampa, el controlador inyecta una falla en el sistema. Las fallas pueden ser transitorias o permanentes. Las investigaciones realizadas con Ferrari muestran que la detección de errores depende del tipo de fallo y de dónde se inserta el fallo. ^[12]
• FTAPE (Evaluador de rendimiento y tolerancia a fallos) puede inyectar fallos, no sólo en la memoria y los registros, sino también en los accesos al disco. Esto se logra insertando un controlador de disco especial en el sistema que puede inyectar fallas en los datos enviados y recibidos desde la unidad de disco. FTAPE también tiene una unidad de carga sintética que puede simular cantidades específicas de carga para fines de pruebas de robustez. ^[13]
• DOCTOR (IntegrateD SOftware Fault InjeCTiOn EnviRonment) permite la inyección de memoria y registro de fallos, así como fallos de comunicación en la red. Utiliza una combinación de tiempo de espera, trampa y modificación de código. Los disparadores de tiempo de espera inyectan fallas transitorias de memoria y las trampas inyectan fallas transitorias de hardware emuladas, como corrupción de registros. La modificación del código se utiliza para inyectar fallas permanentes. ^[14]
• Orchestra es un inyector de fallos basado en scripts que se basa en la inyección de fallos a nivel de red. Su uso principal es la evaluación y validación de las características de sincronización y tolerancia a fallas de protocolos distribuidos. Orchestra se desarrolló inicialmente para el sistema operativo Mach y utiliza ciertas características de esta plataforma para compensar las latencias introducidas por el inyector de fallas. También se ha portado con éxito a otros sistemas operativos. ^[15]
• Xception está diseñado para aprovechar las funciones de depuración avanzadas disponibles en muchos procesadores modernos. Está escrito para no requerir ninguna modificación de la fuente del sistema ni la inserción de trampas de software, ya que las capacidades de manejo de excepciones del procesador desencadenan la inyección de fallas. Estos desencadenantes se basan en accesos a ubicaciones de memoria específicas. Dichos accesos podrían ser para obtener datos o instrucciones. Por lo tanto, es posible reproducir con precisión las ejecuciones de prueba porque los activadores se pueden vincular a eventos específicos, en lugar de tiempos de espera. ^[7]
• Grid-FIT (Grid - Tecnología de inyección de fallas) ^[16] es un método y una herramienta de evaluación de confiabilidad para evaluar los servicios de Grid mediante inyección de fallas. Grid-FIT se deriva de un inyector de fallas anterior WS-FIT ^[17] que estaba dirigido a servicios web Java implementados utilizando el transporte Apache Axis. Grid-FIT utiliza un novedoso mecanismo de inyección de fallas que permite utilizar la inyección de fallas a nivel de red para brindar un nivel de control similar a la inyección de fallas de inserción de código, pero al mismo tiempo es menos invasivo. ^[18]
• LFI (Inyector de fallas a nivel de biblioteca) ^[19] es un conjunto de herramientas de prueba automática, que se utiliza para simular en un entorno de prueba controlado situaciones excepcionales que los programas deben manejar en tiempo de ejecución pero que no son fáciles de verificar mediante pruebas de entrada únicamente. LFI identifica automáticamente los errores expuestos por las bibliotecas compartidas, encuentra códigos de recuperación de errores potencialmente defectuosos en los archivos binarios del programa e inyecta las fallas deseadas en el límite entre las bibliotecas compartidas y las aplicaciones.
• FIBlock (Bloque de inyección de fallos), ^[20] un método de inyección de fallos basado en modelos implementado como un bloque Simulink altamente personalizable. Admite la inyección en modelos MATLAB Simulink de fallas típicas de componentes heterogéneos esenciales de sistemas ciberfísicos, como sensores, hardware informático y redes. Las entradas y salidas de disparo adicionales del bloque permiten el modelado de fallas condicionales. Además, dos o más FIBlocks conectados con las señales de activación pueden modelar los llamados errores encadenados.

Herramientas comerciales

• Más allá de la seguridad beSTORM ^[21] es una herramienta comercial de análisis de seguridad de software de caja negra . Los fabricantes de equipos originales lo utilizan a menudo durante el desarrollo, pero también se utiliza para probar productos antes de su implementación, especialmente en el sector aeroespacial, bancario y de defensa. El proceso de prueba de beSTORM comienza con los escenarios de ataque más probables y luego recurre a una fuzzing exhaustiva basada en generación . beSTORM proporciona módulos para protocolos comunes y protocolos nuevos o propietarios de "aprendizaje automático", incluidos los ataques basados ​​en mutaciones. Aspectos destacados: análisis binario y textual, pruebas de protocolos personalizados, depuración y seguimiento de pila, lenguaje de desarrollo independiente, compatible con CVE.
• ExhaustiF es una herramienta de software comercial utilizada para pruebas de caja gris basada en inyección de fallas de software (SWIFI) para mejorar la confiabilidad de sistemas con uso intensivo de software. La herramienta se puede utilizar durante las fases de integración y prueba del sistema de cualquier ciclo de vida de desarrollo de software, complementando también otras herramientas de prueba. ExhaustiF es capaz de inyectar fallas tanto en software como en hardware. Al inyectar fallas simuladas en el software, ExhaustiF ofrece los siguientes tipos de fallas: Corrupción variable y Corrupción de procedimiento. El catálogo de inyecciones de fallas de hardware incluye fallas en Memoria (E/S, RAM) y CPU (Unidad entera, Unidad flotante). Hay diferentes versiones disponibles para RTEMS/ERC32, RTEMS/Pentium, Linux/Pentium y MS-Windows/Pentium. ^[22]
• Holodeck ^[23] es una herramienta de prueba desarrollada por Security Innovation que utiliza la inyección de fallas para simular errores de aplicaciones y sistemas del mundo real para aplicaciones y servicios de Windows. Los clientes de Holodeck incluyen muchas empresas importantes de desarrollo de software comercial, incluidas Microsoft, Symantec, EMC y Adobe. Proporciona un entorno controlado y repetible en el que analizar y depurar código de manejo de errores y superficies de ataque de aplicaciones para pruebas de fragilidad y seguridad. Simula fallos de fuzzing de archivos y redes, así como una amplia gama de otros recursos, fallos del sistema y fallos personalizados. Analiza código y recomienda planes de prueba y también realiza registro de llamadas de funciones, interceptación de API, pruebas de estrés, análisis de cobertura de código y muchas otras funciones de garantía de seguridad de aplicaciones.
• La plataforma Chaos Engineering de Proofdock se centra en la plataforma en la nube Microsoft Azure . Inyecta fallas a nivel de infraestructura, nivel de plataforma y nivel de aplicación.
• Gremlin es una plataforma de "fallo como servicio" que ayuda a las empresas a construir sistemas más resistentes mediante la práctica de la ingeniería del caos. Gremlin recrea las fallas más comunes en tres categorías ( Recurso , Red y Estado ) inyectando fallas de manera segura en los sistemas para identificar y corregir de manera proactiva fallas desconocidas.
• Codenomicon Defensics ^[24] es un marco de automatización de pruebas de caja negra que inyecta fallas en más de 150 interfaces diferentes, incluidos protocolos de red, interfaces API, archivos y estructuras XML. El producto comercial se lanzó en 2001, después de cinco años de investigación en la Universidad de Oulu en el área de inyección de fallas de software. VTT, uno de los miembros del consorcio PROTOS, publicó un trabajo de tesis que explica los principios de fuzzing utilizados. ^[5]
• Mu Service Analyzer ^[25] es una herramienta de prueba de servicios comerciales desarrollada por Mu Dynamics . ^[26] Mu Service Analyzer realiza pruebas de caja negra y caja blanca de servicios en función de sus interfaces de software expuestas, utilizando simulaciones de denegación de servicio, variaciones de tráfico a nivel de servicio (para generar entradas no válidas) y la reproducción de desencadenantes de vulnerabilidad conocidos. Todas estas técnicas ejercitan la validación de entradas y el manejo de errores y se utilizan junto con monitores de protocolo válidos y SNMP para caracterizar los efectos del tráfico de prueba en el sistema de software. Mu Service Analyzer permite a los usuarios establecer y rastrear métricas de confiabilidad, disponibilidad y seguridad a nivel del sistema para cualquier implementación de protocolo expuesta. La herramienta ha estado disponible en el mercado desde 2005 para clientes en América del Norte, Asia y Europa, especialmente en los mercados críticos de operadores de redes (y sus proveedores) y sistemas de control industrial (incluidas infraestructuras críticas ).
• Xception ^[27] es una herramienta de software comercial desarrollada por Critical Software SA ^[28] que se utiliza para pruebas de caja negra y caja blanca basadas en inyección de fallas de software (SWIFI) y inyección de fallas en cadena de escaneo (SCIFI). Xception permite a los usuarios probar la solidez de sus sistemas o solo parte de ellos, permitiendo tanto la inyección de fallas de software como la inyección de fallas de hardware para un conjunto específico de arquitecturas. La herramienta se utiliza en el mercado desde 1999 y tiene clientes en los mercados americano, asiático y europeo, especialmente en el mercado crítico de la industria aeroespacial y de telecomunicaciones. La familia completa de productos Xception incluye: a) La herramienta principal Xception, líder de última generación en tecnología de inyección de fallos implementada por software (SWIFI); b) Las herramientas complementarias Easy Fault Definición (EFD) y Xtract (Xception Analysis Tool); c) La herramienta Xception extendida (eXception), con las extensiones de inyección de fallas para Scan Chain y forzado a nivel de pin.
• AWS Fault injection Service es un servicio totalmente administrado para ejecutar experimentos de inyección de fallas en AWS que facilita la mejora del rendimiento, la observabilidad y la resiliencia de una aplicación. Los experimentos de inyección de fallas se utilizan en ingeniería del caos, que es la práctica de estresar una aplicación en entornos de prueba o producción creando eventos disruptivos, como un aumento repentino en el consumo de CPU o memoria, observando cómo responde el sistema e implementando mejoras.

Bibliotecas

• libfiu (Inyección de fallos en el espacio de usuario), biblioteca C para simular fallos en rutinas POSIX sin modificar el código fuente. Se incluye una API para simular fallas arbitrarias en tiempo de ejecución en cualquier punto del programa.
• TestApi es una biblioteca API de código compartido que proporciona funciones para pruebas de inyección de fallas, así como otros tipos de pruebas, estructuras de datos y algoritmos para aplicaciones .NET.
• Fuzzino es una biblioteca de código abierto que proporciona un rico conjunto de heurísticas difusas que se generan a partir de una especificación de tipo y/o valores válidos.
• krf es un módulo del kernel de Linux de código abierto que proporciona una función configurable para devolver probabilísticamente valores de error para llamadas al sistema. Se explica con más detalle en la publicación del blog.
• nlfaultinjection está diseñado para proporcionar un marco de inyección de fallas simple y portátil capaz de ejecutarse en casi cualquier sistema, sin importar cuán restringido sea y depende únicamente de la biblioteca estándar C.

Inyección de fallas en propiedades funcionales o casos de prueba.

A diferencia de las pruebas de mutación tradicionales, en las que se generan fallos mutantes y se inyectan en la descripción del código del modelo, también se ha investigado la aplicación de una serie de operadores de mutación recién definidos directamente a las propiedades del modelo en lugar de al código del modelo. ^[29] Las propiedades mutantes que se generan a partir de las propiedades iniciales (o casos de prueba) y validadas por el verificador de modelos deben considerarse como nuevas propiedades que se han omitido durante el procedimiento de verificación inicial. Por lo tanto, agregar estas propiedades recientemente identificadas a la lista de propiedades existente mejora la métrica de cobertura de la verificación formal y, en consecuencia, conduce a un diseño más confiable.

Aplicación de inyección de fallas.

La inyección de fallos puede adoptar muchas formas. En las pruebas de sistemas operativos , por ejemplo, la inyección de fallas a menudo la realiza un controlador ( software en modo kernel ) que intercepta las llamadas al sistema (llamadas al kernel) y devuelve aleatoriamente una falla para algunas de las llamadas. Este tipo de inyección de fallas es útil para probar software en modo de usuario de bajo nivel. Para software de nivel superior, varios métodos inyectan fallas. En el código administrado , es común utilizar instrumentación . Aunque la inyección de fallas se puede realizar manualmente, existen varias herramientas de inyección de fallas para automatizar el proceso de inyección de fallas. ^[30]

Dependiendo de la complejidad de la API para el nivel donde se inyectan las fallas, las pruebas de inyección de fallas a menudo deben diseñarse cuidadosamente para minimizar la cantidad de falsos positivos. Incluso una prueba de inyección de fallos bien diseñada puede a veces producir situaciones que son imposibles en el funcionamiento normal del software. Por ejemplo, imagine que hay dos funciones API , Commity PrepareForCommit, de modo que por sí solas, cada una de estas funciones puede fallar, pero si PrepareForCommitse llama y tiene éxito, Commitse garantiza que una llamada posterior tendrá éxito. Ahora considere el siguiente código:

 error = PrepareForCommit (); if ( error == ÉXITO ) { error = Confirmar (); afirmar ( error == ÉXITO ); }              

A menudo, será inviable que la implementación de la inyección de fallas realice un seguimiento del estado suficiente para garantizar la garantía que brindan las funciones API. En este ejemplo, una prueba de inyección de fallas del código anterior podría afectar a la afirmación , mientras que esto nunca sucedería en el funcionamiento normal.

Ver también

• Bebuging
• Pruebas de mutación
• Ingeniería del caos

Referencias

1. Moradi, Mehrdad; Van Acker, Bert; Vanherpen, Ken; Denil, Joaquín (2019). "Inyección de fallas híbridas implementada en modelo para Simulink (demostraciones de herramientas)". En Chamberlain, Roger; Taha, Walid; Törngren, Martín (eds.). Sistemas ciberfísicos. Diseño basado en modelos . Apuntes de conferencias sobre informática. vol. 11615. Publicación internacional Springer. págs. 71–90. doi :10.1007/978-3-030-23703-5_4. ISBN 9783030237035. S2CID  195769468.
2. Pastor, Carlton; Markantonakis, Konstantinos; Van Heijningen, Nico; Aboulkassimi, Driss; Gaine, Clemente; Heckmann, Thibaut; Naccache, David (2021). "Inyección de fallas físicas y ataques de canal lateral en dispositivos móviles: un análisis integral". Computadoras y seguridad . 111 (102471). Elsevier: 102471. arXiv : 2105.04454 . doi :10.1016/j.cose.2021.102471. S2CID  236957400.
3. Bar-El, Hagai; Choukri, Hamid; Naccache, David; Tunstall, Michael; Whelan, Claire (2004). "La guía de aprendiz de brujo para los ataques de fallas". Actas del IEEE . 94 (2). IEEE: 370–382. doi :10.1109/JPROC.2005.862424. S2CID  2397174.
4. J. Voas, "Inyección de fallas para las masas", Computadora, vol. 30, págs. 129-130, 1997.
5. Kaksonen, Rauli. Un método funcional para evaluar la seguridad de la implementación del protocolo. 2001.
6. A. Avizienis, J.-C. Laprie, Brian Randell y C. Landwehr, "Conceptos básicos y taxonomía de la informática segura y confiable", Computación confiable y segura, vol. 1, págs. 11 a 33, 2004.
7. JV Carreira, D. Costa y SJ G, "Inyección de fallas verifica la confiabilidad del sistema informático", IEEE Spectrum, págs. 50–55, 1999.
8. Benso, Alfredo; Prinetto, Paolo, eds. (2003). Técnicas y herramientas de inyección de fallas para la evaluación de la confiabilidad de sistemas integrados. Fronteras en pruebas electrónicas. Springer Estados Unidos. ISBN 978-1-4020-7589-6.
9. "Optimización de la inyección de fallas en la cosimulación de FMI mediante la partición de sensibilidad | Actas de la Conferencia de simulación de verano de 2019". dl.acm.org . Consultado el 14 de junio de 2020 .
10. Moradi, M., Oakes, BJ, Saraoglu, M., Morozov, A., Janschek, K. y Denil, J., 2020. EXPLORACIÓN DEL ESPACIO DE PARÁMETROS DE FALLAS UTILIZANDO LA INYECCIÓN DE FALLAS BASADA EN EL APRENDIZAJE DE REFUERZO.
11. Rickard Svenningsson, Jonny Vinter, Henrik Eriksson y Martin Torngren, "MODIFI: una herramienta de inyección de fallas implementada por MODel", Lecture Notes in Computer Science, 2010, volumen 6351/2010, 210-222.
12. GA Kanawati, NA Kanawati y JA Abraham, "FERRARI: un sistema flexible de inyección de errores y fallas basado en software", IEEE Transactions on Computers, vol. 44, págs. 248, 1995.
13. T. Tsai y R. Iyer, "FTAPE: una herramienta de inyección de fallas para medir la tolerancia a fallas", presentado en Computing in aerospace, San Antonio; Texas, 1995.
14. S. Han, KG Shin y HA Rosenberg, "DOCTOR: Un entorno integrado de inyección de fallas de software para sistemas distribuidos en tiempo real", presentado en el Simposio internacional sobre confiabilidad y rendimiento informático, Erlangen; Alemania, 1995.
15. S. Dawson, F. Jahanian y T. Mitton, "ORQUESTA: Un entorno de sondeo e inyección de fallas para implementaciones de protocolos de prueba", presentado en el Simposio internacional sobre confiabilidad y rendimiento informático, Urbana-Champaign, EE. UU., 1996.
16. Sitio web Grid-FIT Archivado el 2 de febrero de 2008 en Wayback Machine.
17. N. Looker, B. Gwynne, J. Xu y M. Munro, "Un enfoque basado en ontologías para determinar la confiabilidad de las arquitecturas orientadas a servicios", en las actas del décimo taller internacional IEEE sobre realidad orientada a objetos. Time Dependable Systems, EE. UU., 2005.
18. N. Looker, M. Munro y J. Xu, "Una comparación de la inyección de fallas a nivel de red con la inserción de código", en las actas de la 29.ª Conferencia internacional de aplicaciones y software informáticos del IEEE, Escocia, 2005.
19. Sitio web de LFI
20. Flatag (16 de mayo de 2020), Flatag/FIBlock , consultado el 16 de mayo de 2020
21. información del producto beSTORM
22. Sitio de herramientas ExhaustiF SWIFI
23. Descripción general del producto Holodeck Archivado el 13 de octubre de 2008 en Wayback Machine.
24. Descripción general del producto Codenomicon Defensics
25. Analizador de servicios Mu
26. Dinámica Mu, Inc.
27. Sitio web de Xcepción
28. Software crítico SA
29. Abbasinasab, Ali; Mohammadi, Mehdi; Mohammadi, Siamak; Yanushkevich, Svetlana; Smith, Michael (2011). "Inyección de fallas mutantes en propiedades funcionales de un modelo para mejorar las métricas de cobertura". 2011 14ª Conferencia Euromicro sobre Diseño de Sistemas Digitales . págs. 422–425. doi :10.1109/DSD.2011.57. ISBN 978-1-4577-1048-3. S2CID  15992130.
30. N. Looker, M. Munro y J. Xu, "Simulación de errores en servicios web", Revista internacional de sistemas de simulación, ciencia y tecnología, vol. 5, 2004.

enlaces externos

• Software de certificación de Certess Inc.
• Cómo DoorDash utiliza las pruebas de inyección de fallas para mejorar la confiabilidad