Caso de mal uso - Misuse case
El caso de uso indebido es una herramienta de modelado de procesos de negocio utilizada 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 . 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.
Visió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, 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 en soluciones críticas del sistema y análisis de compensaciones.
- 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 conduce a la creación de un nuevo caso de uso que actúa como contramedida. Esto, a su vez, podría ser objeto de un nuevo caso de uso indebido.
- 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 desde el exterior: los casos de uso se han vuelto populares para los requisitos entre los ingenieros gracias a sus características como la técnica de modelado visual, describen un sistema de un actor. El punto de vista y su formato transmite explícitamente los objetivos de cada actor y los flujos que el sistema debe implementar para lograrlos.
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 de un sistema consideran inaceptables o, como dijeron Guttorm Sindre y Andreas L. Opdahl, "una función que el sistema no debería permitir". 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 uno "negativo" es un escenario cuyo objetivo no se desea que ocurra por la organización en cuestión. o deseado por un agente hostil (no necesariamente humano).
Otra descripción de la diferencia es 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 algún 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 mal uso del escenario ayuda explícitamente a centrar la atención en él.
Área de uso
Los casos de uso indebido se utilizan con mayor frecuencia en el campo de la seguridad. Con la importancia cada vez mayor del sistema de TI, se ha vuelto vital para todas las empresas desarrollar la capacidad para proteger sus datos.
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. Luego, 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.
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 se puede hacer 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, explotándolo 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).
Descripciones
Hay dos formas diferentes de describir un caso de mal uso textual; uno está incrustado 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 mal uso (y pasos alternativos). Esto se conoce como el modo ligero de describir un caso de mal uso.
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 considerarse un documento dinámico. También se ha debatido si comenzar con diagramas o comenzar con descripciones. La recomendación dada por Sindre y Opdahl al respecto es que debe hacerse como en los casos de uso.
Sindre y Opdahl proponen los siguientes 5 pasos para utilizar casos de uso indebido para identificar 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 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.
Investigación
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 aplicaciones: 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 "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 los 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". Proponen, en el mismo artículo, incorporar 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 hackers lambda.
Otra investigación se centró en posibles soluciones concretas faltantes del caso de uso indebido: como se escribió: "Si bien este enfoque puede ayudar a obtener un alto nivel de 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".
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)