El caso de uso indebido es una herramienta de modelado de procesos de negocios que se utiliza en la industria del desarrollo de software. El término caso de uso indebido o caso de uso indebido se deriva de y es el inverso de caso de uso . [1] El término fue utilizado por primera vez en la década de 1990 por Guttorm Sindre de la Universidad Noruega de Ciencia y Tecnología y Andreas L. Opdahl de la Universidad de Bergen , Noruega. Describe el proceso de ejecución de un acto malicioso contra un sistema, mientras que caso de uso puede usarse para describir cualquier acción realizada por el sistema. [2]
Los casos de uso especifican el comportamiento requerido del software y otros productos en desarrollo y son esencialmente historias o escenarios estructurados que detallan el comportamiento y uso normal del software. Por otro lado, un caso de uso incorrecto resalta algo que no debería suceder (es decir, un escenario negativo) y las amenazas identificadas de ese modo ayudan a definir nuevos requisitos, que se expresan como nuevos casos de uso.
Esta herramienta de modelado tiene varias ventajas:
Su mayor debilidad es su simplicidad, por lo que necesita combinarse con herramientas más potentes para establecer un plan adecuado para la ejecución de un proyecto. Otra de sus debilidades es su falta de estructura y semántica.
En una industria es importante describir el comportamiento de un sistema cuando responde a una solicitud que se origina desde afuera: los casos de uso [5] se han vuelto populares para los requisitos [1] entre los ingenieros gracias a sus características como la técnica de modelado visual, describen un sistema desde el punto de vista de un actor y su formato transmite explícitamente los objetivos de cada actor y los flujos que el sistema debe implementar para lograrlos. [6]
El nivel de abstracción de un modelo de caso de uso lo convierte en un punto de partida adecuado para las actividades de diseño, gracias al uso de diagramas de casos de uso UML y el lenguaje del usuario final o del experto en el dominio. Pero para los análisis de seguridad del software, los desarrolladores deben prestar atención a los escenarios negativos y comprenderlos. Por eso, en la década de 1990, nació en Noruega el concepto de "inverso de un caso de uso" .
El contraste entre el caso de uso indebido y el caso de uso es el objetivo: el caso de uso indebido describe comportamientos potenciales del sistema que las partes interesadas del sistema consideran inaceptables o, como dijeron Guttorm Sindre y Andreas L. Opdahl, "una función que el sistema no debería permitir". [1] Esta diferencia también está en los escenarios: un escenario "positivo" es una secuencia de acciones que conducen a un objetivo deseado por una persona u organización, mientras que un escenario "negativo" es un escenario cuyo objetivo no se desea que ocurra por parte de la organización en cuestión o lo desea un agente hostil (no necesariamente humano). [7]
Otra descripción de la diferencia es la de [8] que define un caso de uso como una secuencia completa de acciones que le da mayor valor al usuario, mientras que un caso de mal uso podría definirse como una secuencia completa de acciones que resultan en pérdidas para la organización o alguna parte interesada específica.
Entre el caso "bueno" y el caso "malo" el lenguaje para representar el escenario es común: los diagramas de casos de uso están formalmente incluidos en dos lenguajes de modelado definidos por el OMG : el Lenguaje de Modelado Unificado (UML) y el Lenguaje de Modelado de Sistemas (SysML), y este uso de dibujar los agentes y casos de mal uso del escenario explícitamente ayuda a centrar la atención en él. [9]
Los casos de uso indebido se utilizan con mayor frecuencia en el campo de la seguridad. [10] Con la creciente importancia de los sistemas de TI, se ha vuelto vital para cada empresa desarrollar la capacidad de proteger sus datos. [11]
Por ejemplo, un caso de uso indebido podría utilizarse para definir lo que un hacker querría hacer con el sistema y definir sus requisitos. Un desarrollador o diseñador puede entonces definir los requisitos del usuario y del hacker en el mismo diagrama UML, lo que a su vez ayuda a identificar los riesgos de seguridad del sistema. [12]
Se crea un diagrama de casos de uso incorrecto junto con un diagrama de casos de uso correspondiente. El modelo introduce dos nuevas entidades importantes (además de las del modelo de casos de uso tradicional, caso de uso y actor ):
El modelo de caso de uso incorrecto hace uso de los tipos de relación que se encuentran en el modelo de caso de uso: include , extend , generalize y association . Además, introduce dos nuevas relaciones para usar en el diagrama:
Estos nuevos conceptos junto con los existentes a partir de casos de uso dan como resultado el siguiente metamodelo, que también se encuentra en la figura 2 en Sindre y Opdahl (2004). [2]
Existen dos formas diferentes de describir un caso de uso indebido en formato textual. Una de ellas está integrada en una plantilla de descripción de caso de uso, donde se puede agregar un campo de descripción adicional llamado Amenazas . Este es el campo en el que se pueden completar los pasos del caso de uso indebido (y los pasos alternativos). Esto se conoce como el modo liviano de describir un caso de uso indebido.
La otra forma de describir un caso de uso indebido es mediante el uso de una plantilla independiente para este fin únicamente. Se sugiere heredar algunos de los campos de la descripción del caso de uso ( Nombre , Resumen , Autor y Fecha ). También se adaptan los campos Ruta básica y Ruta alternativa , donde ahora describen las rutas de los casos de uso indebido en lugar de los casos de uso. Además de esto, se propone utilizar también otros campos:
Como es de suponer, la lista anterior es demasiado extensa para completarla por completo cada vez. No es necesario completar todos los campos al principio, por lo que debe considerarse un documento vivo. También se ha debatido si se debe comenzar con diagramas o con descripciones. La recomendación dada por Sindre y Opdahl al respecto es que se debe hacer como con los casos de uso.
Sindre y Opdahl proponen los siguientes cinco pasos para utilizar casos de mal uso para identificar requisitos de seguridad:
Se sugiere utilizar un repositorio de casos de mal uso reutilizables como apoyo en este proceso de 5 pasos.
Las investigaciones actuales sobre casos de uso indebido se centran principalmente en las mejoras de seguridad que pueden aportar a un proyecto, en particular a los proyectos de software. Se están estudiando formas de aumentar la adopción generalizada de la práctica del desarrollo de casos de uso indebido durante las primeras fases del desarrollo de aplicaciones: cuanto antes se detecte un fallo, más fácil será encontrar un parche y menor será el impacto en el coste final del proyecto.
Otras investigaciones se centran en mejorar el caso de uso indebido para alcanzar su objetivo final: para [13] “existe una carencia en el proceso de aplicación, y los resultados son demasiado generales y pueden provocar una subdefinición o una mala interpretación de sus conceptos”. Sugieren además “ver el caso de uso indebido a la luz de un modelo de referencia para la gestión de riesgos de seguridad de sistemas de información (ISSRM)” para obtener un proceso de gestión de riesgos de seguridad.
Los casos de uso indebido son bien conocidos por la población de investigadores. El conjunto de investigaciones sobre el tema demuestra el conocimiento, pero más allá del mundo académico, el caso de uso indebido no ha sido ampliamente adoptado.
Como sugieren Sindre y Opdahl (los padres del concepto de caso de uso indebido): "Otro objetivo importante para el trabajo futuro es facilitar una adopción industrial más amplia de casos de uso indebido". [2] Proponen, en el mismo artículo, integrar el caso de uso indebido en una herramienta de modelado de casos de uso y crear una "base de datos" de casos de uso indebido estándar para ayudar a los arquitectos de software. Las partes interesadas del sistema deberían crear sus propios gráficos de casos de uso indebido para los requisitos que sean específicos de sus propios dominios de problemas. Una vez desarrollada, una base de datos de conocimiento puede reducir la cantidad de fallas de seguridad estándar utilizadas por los piratas informáticos lambda.
Otras investigaciones se centraron en posibles soluciones concretas faltantes para el caso de uso indebido: como escribió [14] "Si bien este enfoque puede ayudar a obtener información de alto nivel sobre los requisitos de seguridad, no muestra cómo asociar los casos de uso indebido con el comportamiento legítimo y los activos concretos; por lo tanto, no está claro qué caso de uso indebido se debe considerar ni en qué contexto". Estas críticas se podrían abordar con las sugerencias y mejoras presentadas en la sección precedente.
La estandarización del caso de uso indebido como parte de la notación UML podría permitir que se convierta en una parte obligatoria del desarrollo del proyecto. "Podría ser útil crear una notación específica para la funcionalidad de seguridad o contramedidas que se hayan agregado para mitigar vulnerabilidades y amenazas". [15]