Retrospectiva Sprint 4
ASR Considerado para el Sprint
ASR: como usuario no autorizado, intento procesar una propuesta de negocio; el sistema debe mantener auditoría del proceso realizado y reversar el 100% de las modificaciones no autorizadas a dichas propuestas.
Resumen de Arquitectura
Para satisfacer los requerimientos ASR propuestos se evaluaron los elementos del sistema que tuvieran mayor impacto en determinar . El esfuerzo se concentró en el procesador de propuestas; lo que se evidencia especificamente en la vista funcional, la vista de operación y la vista de depliegue.
Modelos y Vistas Considerados para el Sprint
Diagrama Funcional
Diagrama de Despliegue
Protocolo para Manejo de Cambios
Para el manejo de cambios se plantea un protocolo de operación para aplicar cambios que separe responsabilidades e impida que un solo usuario conozca todo el proceso y cuente con el conocimiento suficiente del sistema para aplicar cambios no autorizados. Cualquier modificación al sistema es monitoreada por un sistema de supervisión de directorios de código abierto.
La tabla a continuación resume las responsabilidades y limitaciones de cada role involucrado.
| Role | Funciones | Limitaciones |
|---|---|---|
| Analista | Genera la especificación de cambios requeridos para el sistema | Desconoce la estructura interna del sistema, las responsabilidades de sus componentes, dónde está desplegado y cómo está desplegado |
| Desarrollador | Genera el paquete de cambios para ser aplicados al sistema | Desconoce dónde está desplegado y cómo está desplegado el sistema |
| Pruebas | Realiza pruebas funcionales del sistema y certifica que los cambios se alínean con la especificación del analista | Desconoce la estructura del sistema, las responsabilidades de sus componentes, dónde está desplegado y cómo está desplegado |
| Administrador de Configuración | Certifica que solo se hayan modificado los componentes requeridos por las pruebas del paquete que se aplicarán al sistema. Crea un paquete para ser desplegado en el sistema con instrucciones de mapeos de los componentes del paquete contra directorios en el sistema destino, sin conocer su ubicación física | Desconoce dónde está desplegado y cómo está desplegado el sistema |
| Administrador de Sistema | Se encarga de aplicar el paquete probisto por el administrador de configuración en los directorios físicos del servidor, siguiendo los mapeos provistos | Desconoce la estructura interna del sistema y las responsabilidades de sus componentes |
Resumen de Decisiones Críticas
Puntos de Sensibilidad
Los puntos de sensibilidad expuestos en nuestra vista funcional, despliegue y operacional se resumen a continuación.
| Id | Nombre | Componente | Impacto | Tipo de Ataque |
|---|---|---|---|---|
| PSSE-001 | Responsables de Acciones en el Sistema | Todos los componentes en el sistema | No registrar las actividades y sus responsables en el sistema impide identificar los responsables de acciones que se hagan en el sistema con malas intenciones | Spoofing |
| PSSE-002 | Responsables de cambios realizados a componentes del sistema | Todos los componentes | No registrar los cambios realizados al sistema impide identificar los responsables de cambios hechos al mismo con malas intenciones | System Tampering |
| PSSE-003 | Rastreo de Cambios Indebidos a la información del Sistema | Datos en la Base de datos | Cambios Maliciosos a los registros de la aplicación | Information Tampering |
Tácticas Empleadas
| Id | Nombre | Componentes | Punto de Sensibilidad | Descripción | Favorece |
|---|---|---|---|---|---|
| TASE-001 | Registro de Auditoría del Sistema | Todos los Componentes | PSDI-001 | Introducir un componente transversal a toda la arquitectura que permita registrar las acciones realizadas por componentes y usuarios en el sitema | Identificación de Responsables de acciones al interior sistema |
| TASE-002 | Uso de auditoría de la plataforma | PSDI-002 | Utilizar herramientas de auditoría de archivos y directorios para registrar acciones realizadas sobre los componentes del sistema que sean externas a éste | Identificación de Responsables y sus acciones que produzcan cambios externos sobre el sistema | |
| TASE-003 | Introducción de llave de seguridad a los registros de propuestas | PSDI-003 | Se agregaró una llave a todos los registros de propuestas de negocio, calculada a partir de los datos que ésta contenga. Al realizar acciones con una propuesta, el sistema comparará sus datos contra la llave y, de no coincidir, desactivará dicha propuesta hasta que sus datos sean restaurados y coincidan con la llave. Para reversar los cambios no autorizados a propuestas, el sistema contará con una copia cifrada de los registros de propuestas que serán usados para reemplazar sus contrapartes que cuyo estado haya sido detectado como inconsistente con su correspondiente llave de seguridad | Datos en la Base de Datos | Reverir cambios no autorizados |
Diseño y Resultado de Experimentación
Los escenarios de experimentación para probar la arquitectura planteada para soportar el ASR de seguridad se resumen a continuación.
| Id | PASE-001 |
|---|---|
| Propósito | Probar que el registro de acciones de usuarios del sistema y el cálculo de las llaves de seguridad de las propuestas de negocio no incremente significativamente los tiempos de respuesta |
| Resultados Esperados | Se espera que los cambios realizados no incrementen el tiempo promedio de latencia en más de 3% (1620 ms bajo condiciones normales de operación) |
| Recursos requeridos | Procesador de Propuestas, Procesador Batch, Procesador Serving, Procesador de Propuestas, Administrador de Inventarios, Administrador de Clientes, cronista de excepciones y relanzador de procesos |
| Elementos Arquitecturales Involucrados | Vista Funcional |
| Esfuerzo estimado | 20 minutos, 50 usuarios concurrentes y un promedio de 25 solicitudes por segundo |
| Resultados | El sistema presenta un tiempo de respuesta promedio de 1.78 milisegundos |
| Acciones a seguir | Probar el sistema con una mayor carga concurrente de usuarios y una mayor duración del estrés |
Experimentación NewRelic y Blazemeter.
NEWRELIC
| Id | PASE-002 |
|---|---|
| Propósito | Probar que el protocolo de auditoría exterior del sistema permite detectar fácil y rápidamente cambios realizados a componentes del sistema |
| Resultados Esperados | Se espera que el protocolo permita detectar los componentes cambiados y su responsable en un tiempo menor a 3 minutos a partir de la ocurrencia del echo |
| Recursos requeridos | Todos los componentes del sistema, un usuario que simule ser el hacker y otro usuario que simule ser el administrador de la plataforma |
| Elementos Arquitecturales Involucrados | Vista de Operación |
| Esfuerzo estimado | Alteraciones perdiodicas sobre la base de datos que almacena información sensible(Propuestas) |
| Resultados | El sistema presenta un tiempo de respuesta promedio de 1.78 milisegundos |
| Acciones a seguir | Probar el sistema con una mayor carga concurrente de usuarios y una mayor duración del estrés |
Para la experimentación se implementaron las siguientes tablas proposal_batches : Contiene las propuestas almacenadas en Batch y en este caso será el componente bajo ataque. proposal_Backups : Cuenta con un Backup seguro de la información del procesamiento batch, en caso de necesitar restaurarla:
En la siguiente figura se observan las propuestas Batches y Backups, con la información que valida antes del ataque.
Se realiza una modificación a al información de la propuestas directamente en la tabla proposal_Batches simulando ataques no autorizados. En la figura se muestra como el registro la propuesta quedó con información diferente a la mostrada en la figura anterior
En la siguiente figura se muestran 10 ataques detectados y almacenados en la tabla proposal_tampereds; ésta cuenta con una columna que indica si la propuesta ya fue restaurada con un campo Boolean, en el caso de los ataques 1-9 se realizó restauración de la propuesta modificada y el caso 10 se encuentra en proceso de restauración. La detección la realiza calculando el hash de la propuesta modificada y comparandola con el almacenado, si no coincide es enviada la tabla de proposal_tampereds y restaurada o reversada.
Despues de esto las tabla de propuestas Batch vuelve a su estado Original.
Análisis de Experimentación
La seguridad en el aplicativo permite detectar y reversar ataques de tampering efectuados directamente sobre la base de datos, adicionalmente almacenará una auditoria de transacciones realizadas en el aplcativo. Ésto es positivo y necesario para el sistema, pero incrementa su complejidad y carga transversal a todo el sistema lo que genera un incremento de la latencia del sistema, en la experimentación para nuestro sistema se encuentra un incremento de 1680 ms a 1780 m, lo cual sigue cuempliendo con la latencia requerida, pero con bajo margen.
Aspectos que Fallaron del Equipo de Trabajo.
- Se presentaron dificultades con el ambiente de desarrollo de uno de los integrantes del equipo que dificultaron el desarrollo de esta fase de la aplicación.
Aspectos que Resultaron del Equipo de Trabajo.
En el equipo funcionó bien la colaboración, con cada integrante aportó ideas y completó sus tareas de forma funcional.
Los integrantes poseen conocimiento técnicos adecuados para la experimentación de este primer Sprint, lo que ayudó a disminuir la curva de aprendizaje.
El control de tareas de forma escrita permitió tomar correctivos apriori para que todos los integrantes completaran sus asignaciones a tiempo.