El caso de uso indebido es una herramienta de modelado de procesos comerciales que se utiliza en la industria del desarrollo de software. El término mal uso Case o caso mal uso se deriva de y es la inversa 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 el caso de uso se puede utilizar para describir cualquier acción realizada por el sistema. [2]
Descripción general
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 normal y el uso del software. Un caso de uso indebido, por otro lado, destaca algo que no debería suceder (es decir, un escenario negativo) y las amenazas identificadas por lo tanto, ayudan a definir nuevos requisitos, que se expresan como nuevos casos de uso.
Esta herramienta de modelado tiene varios puntos fuertes:
- Permite la provisión de una ponderación igual a los requisitos funcionales y no funcionales (por ejemplo, requisitos de seguridad, requisitos de plataforma, etc.), lo que puede no ser posible con otras herramientas.
- Enfatiza la seguridad desde el comienzo del proceso de diseño y ayuda a evitar decisiones de diseño prematuras.
- Es una herramienta para mejorar la comunicación entre los desarrolladores y las partes interesadas y es valiosa para garantizar que ambos estén de acuerdo sobre las soluciones críticas del sistema y el análisis de compensaciones. [3]
- La creación de casos de uso indebido a menudo desencadena una reacción en cadena que facilita la identificación de requisitos funcionales y no funcionales. El descubrimiento de un caso de uso indebido a menudo conducirá a la creación de un nuevo caso de uso que actúa como una contramedida. Esto, a su vez, podría ser objeto de un nuevo caso de uso indebido. [4]
- En comparación con otras herramientas, se relaciona mejor con los casos de uso y UML y facilita el empleo fluido del modelo.
Su mayor debilidad es su sencillez. Debe combinarse con herramientas más poderosas para establecer un plan adecuado para la ejecución de un proyecto. Otra debilidad es su falta de estructura y semántica.
Del uso al caso de mal uso
En una industria es importante describir el comportamiento de un sistema cuando responde a una solicitud que se origina en el exterior: 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 casos de uso lo convierte en un punto de partida apropiado para las actividades de diseño, gracias al uso de diagramas de casos de uso UML y al lenguaje del usuario final o 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 "caso de uso inverso" .
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 se encuentra 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 uno "negativo" es un escenario cuyo objetivo se desea que no ocurra por el organización en cuestión o deseada por un agente hostil (no necesariamente humano). [7]
Otra descripción de la diferencia es por [8] que define un caso de uso como una secuencia completa de acciones que le da un mayor valor al usuario, uno podría definir un caso de mal uso como una secuencia completa de acciones que resulta en una pérdida para la organización o para algunos interesado específico.
Entre el caso "bueno" y el "malo", el lenguaje para representar el escenario es común: los diagramas de casos de uso se incluyen formalmente en dos lenguajes de modelado definidos por la OMG : el lenguaje de modelado unificado (UML) y el lenguaje de modelado de sistemas (SysML ), y este uso de dibujar a los agentes y casos de uso indebido del escenario ayuda explícitamente a centrar la atención en él. [9]
Área de uso
Los casos de uso indebido se utilizan con mayor frecuencia en el campo de la seguridad. [10] Con la importancia cada vez mayor de los sistemas de TI, se ha vuelto vital para todas las empresas desarrollar la capacidad para proteger sus datos. [11]
Por lo tanto, por ejemplo, se podría usar un caso de uso indebido para definir lo que un pirata informático querría hacer con el sistema y definir sus requisitos. Un desarrollador o diseñador puede definir los requisitos del usuario y del pirata informático en el mismo diagrama UML que, a su vez, ayuda a identificar los riesgos de seguridad del sistema. [12]
Conceptos básicos
Se crea un diagrama de casos de uso indebido junto con un diagrama de casos de uso correspondiente. El modelo presenta 2 nuevas entidades importantes (además de las del modelo de caso de uso tradicional, caso de uso y actor :
- Caso de uso indebido : una secuencia de acciones que puede realizar cualquier persona o entidad para dañar el sistema.
- Usuario indebido : el actor que inicia el caso de uso indebido. Esto puede hacerse de forma intencionada o inadvertida.
Diagramas
El modelo de caso de uso indebido hace uso de los tipos de relación que se encuentran en el modelo de caso de uso; incluir , extender , generalizar y asociar . Además, introduce dos nuevas relaciones que se utilizarán en el diagrama:
- mitiga
- Un caso de uso puede mitigar la posibilidad de que un caso de uso indebido se complete correctamente.
- amenaza
- Un caso de uso indebido puede amenazar un caso de uso, por ejemplo, al explotarlo o impedir que logre sus objetivos.
Estos nuevos conceptos junto con los existentes del caso de uso dan el siguiente metamodelo, que también se encuentra en la fig. 2 en Sindre y Opdahl (2004). [2]
Descripciones
Hay dos formas diferentes de describir un caso de uso indebido textual; uno está integrado en una plantilla de descripción de casos de uso, donde se puede agregar un campo de descripción adicional llamado Amenazas . Este es el campo donde se pueden completar los pasos del caso de uso indebido (y los pasos alternativos). Esto se conoce como el modo ligero de describir un caso de uso indebido.
La otra forma de describir un caso de uso indebido es utilizando una plantilla separada solo para este propósito. Se sugiere heredar parte del campo de la descripción del caso de uso ( Nombre , Resumen , Autor y Fecha ). También adapta los campos Ruta básica y Ruta alternativa , donde ahora describen las rutas de los casos de mal uso en lugar de los casos de uso. Además de allí, se propone utilizar varios otros campos también:
- Nombre de caso de uso indebido
- Resumen
- Autor
- Fecha
- Ruta básica
- Caminos alternativos
- Puntos de mitigación
- Puntos de extensión
- Disparadores
- Condiciones previas
- Supuestos
- Garantía de mitigación
- Reglas comerciales relacionadas
- Perfil de usuario indebido potencial
- Grupos de interés y amenazas
- Terminología y explicaciones
- Alcance
- Nivel de abstracción
- Nivel de precisión
Como se puede entender, la lista anterior es demasiado completa para completarla por completo cada vez. No es necesario completar todos los campos al principio y, por lo tanto, debe verse como un documento dinámico. También se ha debatido si comenzar con diagramas o comenzar con descripciones. La recomendación de Sindre y Opdahl al respecto es que se debe hacer como en los casos de uso.
Sindre y Opdahl proponen los siguientes 5 pasos para utilizar casos de uso indebido para identificar los requisitos de seguridad:
- Identificar activos críticos en el sistema.
- Definir objetivos de seguridad para cada activo.
- Identificar las amenazas a cada uno de estos objetivos de seguridad, mediante la identificación de las partes interesadas que pueden querer causar daño al sistema.
- Identificar y analizar los riesgos de las amenazas, utilizando técnicas como la Evaluación de Riesgos.
- Defina los requisitos de seguridad para los riesgos.
Se sugiere utilizar un repositorio de casos de uso indebido reutilizables como soporte en este proceso de 5 pasos.
Investigar
Campo de investigación actual
La investigación actual sobre casos de uso indebido se centra principalmente en las mejoras de seguridad que pueden aportar a un proyecto, proyectos de software en particular. Se están considerando formas de aumentar la adopción generalizada de la práctica del desarrollo de casos de uso indebido durante las fases anteriores del desarrollo de la aplicación: cuanto antes se encuentre una falla, más fácil será encontrar un parche y menor será el impacto en el costo final de la aplicación. proyecto.
Otras investigaciones se enfocan en mejorar el caso de mal uso para lograr su objetivo final: porque [13] "hay una falta en el proceso de solicitud, y los resultados son demasiado generales y pueden causar una sub-definición o una mala interpretación de sus conceptos". Sugieren además "ver el caso de mal uso 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.
Mejora futura
Los casos de mal uso son bien conocidos por la población de investigadores. El cuerpo de investigación sobre el tema demuestra el conocimiento, pero más allá del mundo académico, el caso del mal uso no ha sido adoptado ampliamente.
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 los casos de uso indebido". [2] Proponen, en el mismo artículo, incrustar 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 deben crear sus propios gráficos de casos de uso indebido para los requisitos que son 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.
Otra investigación se centró en posibles soluciones concretas faltantes del caso de uso indebido: como [14] escribió: "Si bien este enfoque puede ayudar a obtener un alto nivel de 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 debe considerarse ni en qué contexto ". Estas críticas pueden abordarse con las sugerencias y mejoras presentadas en la sección anterior.
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 han agregado para mitigar vulnerabilidades y amenazas". [15]
Ver también
- Use el diagrama del caso
- Pasos para que el analista empresarial recopile los requisitos de seguridad de los casos de uso indebido [1]
- Manejo de excepciones
- Modelo de amenaza (software)
Referencias
- ↑ a b c Sindre y Opdahl (2001). " Captura de requisitos de seguridad a través de casos de uso indebido "
- ^ a b c Sindre y Opdahl (2004). " Obtención de requisitos de seguridad con casos de uso indebido Archivado 2011-07-16 en Wayback Machine "
- ^ Experiencia industrial inicial de casos de uso indebido en análisis de compensación (2002, por Ian Alexander) Archivado 2008-04-30 en Wayback Machine
- ^ Ian Alexander, Casos de uso indebido: casos de uso con intención hostil. Software IEEE , Vol 20, No 1, enero-febrero de 2003, 58-66. DOI: 10.1109 / MS.2003.1159030
- ^ Jacobson, "Ingeniería de software orientada a objetos: un enfoque basado en casos de uso", 1992 Addison-Wesley, Boston
- ^ Gunnar Peterson, John Steven "Definición de uso indebido dentro del proceso de desarrollo", IEEE SECURITY & PRIVACY, NOVIEMBRE / DICIEMBRE DE 2006
- ^ Ian Alexander "Caso de uso indebido: casos de uso con intención hostil", presentación
- ^ Guttorm Sindre, Andreas L. Opdahl, "Plantillas para descripción de casos de uso indebido"
- ^ Ian Alexander "Caso de uso indebido: casos de uso con intención hostil"
- ^ Asoke K. Talukder; Manish Chaitanya (17 de diciembre de 2008). Arquitectura de sistemas de software seguros . Prensa CRC. pag. 47. ISBN 978-1-4200-8784-0. Consultado el 5 de octubre de 2016 .
- ^ Jesper M. Johansson; Steve Riley (27 de mayo de 2005). Proteja su red de Windows: desde el perímetro hasta los datos . Addison-Wesley Professional. pag. 491 . ISBN 978-0-321-33643-9. Consultado el 5 de octubre de 2016 .
- ^ Asoke K. Talukder; Manish Chaitanya (17 de diciembre de 2008). Arquitectura de sistemas de software seguros . Prensa CRC. pag. 50. ISBN 978-1-4200-8784-0. Consultado el 5 de octubre de 2016 .
- ^ Raimundas Matulevičius, Nicolas Mayer, Patrick Heymans, "Alineación de casos de uso indebido con la gestión de riesgos de seguridad"
- ^ Fabricio A. Braz, Eduardo B. Fernandez, Michael VanHilst, "Obtención de requisitos de seguridad mediante actividades de uso indebido"
- ^ Lillian Røstad, "Una notación de caso de uso indebido extendido: incluidas las vulnerabilidades y la amenaza interna"