Please enable JavaScript.
Coggle requires JavaScript to display documents.
Yustin Barnet Cardona G-351, Programación orientada a Aspectos,…
Yustin Barnet Cardona G-351
Modelo UMLSec
UMLSec es una metodología de desarrollo basada en UML
Se utiliza para especificar requisitos de seguridad relacionados con integridad y confidencialidad.
Utiliza mecanismos de extensión de UML para expresar estereotipos, etiquetas, restricciones y comportamiento en presencia de ataques.
El modelo define operaciones que un atacante puede realizar en un subsistema y modela cómo actúa el subsistema en su presencia.
UMLSec define estereotipos de seguridad, como "secrecy" y "secure link", que identifican requisitos de seguridad relacionados con la confidencialidad y la seguridad en la comunicación física.
El objetivo es garantizar que un atacante en un subsistema estereotipado, como "secrecy", no pueda leer el contenido del subsistema a través de nodos y enlaces específicos.
Modelo Casos de mal uso
Casos de Mal Uso son el opuesto de los casos de uso UML y representan acciones que el sistema no debería permitir.
En un caso de uso, se describe la secuencia de acciones que aportan valor al usuario, mientras que en un caso de mal uso, se describe la secuencia de acciones que causan pérdidas para la organización o los usuarios interesados.
Se menciona la existencia de un "mal actor," que es lo contrario a un actor en el contexto de casos de uso. Un mal actor es un usuario no deseado que no debe ser compatible con el sistema y podría ser un agresor.
Modelo Análisis de riesgo Threat Modeling
Threat Modeling es una técnica formal y estructurada para determinar y ponderar los riesgos y amenazas que enfrentará una aplicación.
Consta de varias etapas clave, que incluyen:
Conformar un grupo de análisis de riesgos.
Descomponer la aplicación e identificar componentes clave.
Determinar las amenazas específicas que afectan a cada componente de la aplicación.
Asignar un valor a cada amenaza para evaluar su gravedad.
Decidir cómo responder a las amenazas, lo que implica la adopción de medidas de mitigación.
Identificar las técnicas y tecnologías necesarias para reducir los riesgos identificados.
Testing con un cliente servidor falso
Se trata de una estrategia de prueba que implica la creación de un cliente o servidor "Ad Hoc".
El propósito de este enfoque es simular condiciones de prueba que son difíciles de reproducir en un entorno real.
El cliente/servidor falso permite realizar las siguientes acciones de prueba:
Enviar peticiones/respuestas incorrectas o inválidas.
Enviar peticiones/respuestas fuera de orden.
Insertar retrasos arbitrarios en la comunicación.
Comportarse de manera diferente al cliente o servidor real para evaluar cómo se comporta el sistema bajo circunstancias anómalas o adversas.
Programación orientada a Aspectos
La Programación Orientada a Aspectos (AOP) es una metodología que permite separar los elementos funcionales del software de conceptos no funcionales, como sincronización, manejo de memoria, distribución, seguridad, etc.
La AOP implica separar la funcionalidad básica de estos aspectos y entre sí utilizando mecanismos de abstracción y composición.
Permite a los desarrolladores escribir, ver y editar aspectos como entidades separadas y coherentes en todo el sistema de manera inteligente y eficiente.
Los tres elementos principales de la AOP son: un lenguaje base o componente para definir la funcionalidad principal, lenguajes de aspectos para especificar el comportamiento de los aspectos (como COOL, IDL, ASPECJ), y un tejedor de aspectos que combina los lenguajes en tiempo de ejecución o compilación.
La POA facilita a los desarrolladores escribir, ver y editar aspectos de manera inteligente, eficiente e intuitiva.
La POA redefine la forma de interacción en comparación con la programación orientada a objetos tradicional, ya que se basa en puntos de enlace en lugar de declaraciones de tipo y llamadas a procedimientos.
RECUPERADO DE: "Introducción a los S-SDLC" de Santiago Acosta M.