1. Ingeniería de Software
Ingeniería de Protección
Edelma Rodríguez Pérez
Noviembre 2012
1

2. Contenidos
• 14.1 Gestión del riesgo de Protección
• 14.2 Diseño para la Protección
• 14.3 Supervivencia del Sistema
2

3. Ataques
• Las vulnerabilidades de infraestructura pueden conducir a que
los atacantes obtengan sin autorización acceso a un sistema
de aplicación y a los datos.
3

4. Diferencias
Protección de Aplicación Protección de Infraestructura
• Problema de Ingeniería de Software • Problema de Gestión
Los ingenieros de sistemas deben Los administradores de sistemas
de asegurarse que el sistema se deben de configurar la
diseño para soportar ataques. infraestructura para resistir
ataques.
4

5. Gestión
• La gestión de la protección del sistema no es una tarea
sencilla, si no que debe incluir un rango de actividades
como:
• Gestión de usuarios y permisos
• Implementación y mantenimiento del software de
sistema
• Monitorización, detención y recuperación de ataque.
5

6. Gestión del riesgo de
Protección
• Se encarga de evaluar las posibles pérdidas que
se derivan de ataques a los activos en el sistema,
y de equilibrar dichas pérdidas frente a los
costos de los procedimientos de seguridad
encaminados a reducir las pérdidas.
6

7. Valoración del Riesgo
Valoración preliminar del Riesgo
• ¿Puede lograrse un nivel adecuado de seguridad a un costo
razonable?
Valoración del riesgo del ciclo de vida
• Informe de las decisiones técnicas de diseño e implementación
del sistema.
Valoración del riesgo operativo
• Debe implementarse a medida que evoluciona el sistema.
7

8. Clasificación de las Amenazas
•De intercepción
Amenazas
•De interrupción
•De modificación
•De fabricación
8

9. Análisis del riesgo del ciclo de
Vida
9

10. Lineamientos de Diseño
• Los lineamientos generales de diseño para protección, tienen
dos usos principales:
1. Ayudan a crear conciencia acerca de los temas de seguridad
en un equipo de ingeniería de software.
2. Pueden usarse como una lista de verificación que será útil
en el proceso de validación del sistema.
10

11. Lineamientos de seguridad
Lineamientos
1. Decisiones de seguridad con base en una política.
2. Evite solo un punto de falla.
3. Seguridad en caso de falla.
4. Equilibrio entre seguridad y usabilidad.
5. Registe las acciones del usuario.
6. Use redundancia y diversidad para reducir el riesgo.
7. Valide todas las entradas.
8. Compartimente sus activos.
9. Diseñe para implementar.
10. Diseñe para facilitar la recuperabilidad.
11

12. Lineamiento 1
• Decisiones de Protección con base en una política explicita
de seguridad.
• Una política de seguridad es un enunciado de alto nivel que
establece las condiciones fundamentales de seguridad para
una organización.
• Define el “que” de la seguridad en lugar del “como”.
• Los diseñadores deben consultar la política de seguridad, ya
que está constituye un marco para tomar y evaluar decisiones
de diseño.
12

13. Lineamiento 2
• Evite solo un punto de falla.
• En cualquier sistema crítico, una buena práctica de diseño es
tratar de evitar un solo punto de falla.
• No se debe de apoyar en un solo mecanismo para garantizar la
seguridad en vez de ello, se deben de emplear muchas
técnicas diferentes. A esto se le conoce “defensa en
profundidad”.
• Para proteger la integridad de los datos en un sistema hay que
mantener una bitácora ejecutable de los cambios realizados a
los datos.
13

14. Lineamiento 3
• Seguridad en Caso de Falla.
• Las fallas son inevitables en todos los sistemas.
• La protección siempre debe ser a prueba de fallas.
• Cuando falle el sistema, no se deben de usar procedimientos
de estado de emergencia que sean menos seguros que el
sistema en sí.
• La falla tampoco debe significar que el atacante acceda a
datos a los que normalmente no tendrían acceso.
14

15. Lineamiento 4
• Equilibrio entre seguridad y usabilidad.
• Las demandas de seguridad y usabilidad a menudo son
contradictorias.
• Para hacer seguro un sistema, se debe de introducir
comprobaciones de que los usuarios estén autorizados para
utilizar el sistema.
• Esto significa que los usuarios tardan mas tiempo para iniciar
el sistema y usarlo de manera efectiva.
• Conforme se agregan características de seguridad a un
sistema, es inevitable que este se vuelva menos usable.
15

16. Lineamiento 5
• Equilibrio entre seguridad y usabilidad.
• Si es prácticamente posible hacerlo, mantenga una bitácora de
las acciones del usuario.
• En esta bitácora se debe de registrar quien hizo qué, los
activos que utilizo, hora y fecha de acción.
• Si se mantiene esto como lista de comandos ejecutables,
tendrá la opción de reproducir la bitácora para recuperarse de
las fallas.
• La bitácora ayuda a detectar los ataques internos. Es decir, que
los usuarios del sistema intenten actuar de formas no
autorizadas.
16

17. Lineamiento 6
• Use redundancia y diversidad para reducir el riesgo.
• Redundancia significa conservar más de una versión del
software o de los datos de un sistema.
• Diversidad, significa que las diferentes versiones no deben
apoyarse sobre la misma plataforma, o implementarse
usando las mismas tecnologías.
17

18. Lineamiento 7
• Valide todas las entradas.
• Un ataque común al sistema implica proporcionar al sistema
entradas inesperadas que hacen que se comporte en forma no
anticipada.
• Otro ataque bastante común es el llamado “envenenamiento
SQL”, en el que el usuario malicioso ingresa un fragmento de
SQL que interpreta un servidor.
18

19. Lineamiento 8
• Compartimente sus activos.
• Compartimentar significa que no debe permitir el acceso a la
información del sistema con el criterio de todo o nada.
• En vez de ello debe de organizar en compartimentos la
información del sistema.
• Los usuarios deben de tener acceso solo a la información que
necesitan, y no a toda la información de un sistema.
• Tambien se debe de tener mecanismos en el sistema para
garantizar un acceso inesperado.
19

20. Lineamiento 9
• Diseñe para implementar.
• Muchos problemas de seguridad surgen porque el sistema no
esta configurado correctamente al implementarse en su
entorno operacional.
• Siempre se debe de diseñar un sistema de forma que se
incluyan instalaciones para simplificar la implementación en el
entorno del cliente, comprobar errores y omisiones
potenciales de configuración en el sistema implementado.
20

21. Lineamiento 10
• Diseñe para facilitar la recuperabilidad.
• Sin importar cuanto esfuerzo se use en mantener la seguridad
de los sistemas, siempre se debe diseñar su sistema con la
idea de que podría ocurrir una falla de seguridad.
• De ahí que deba de pensar en cómo recuperarse de posibles
fallas y restaurar el sistema a un estado operativo seguro.
21

22. Diseño para implementar
• La implementación de un sistema implica configurar el
software para funcionar en un entorno operacional, instalar el
sistema en las computadoras en ese entorno, y configurar el
sistema instalado para dichas computadoras.
Fig. 14.7 Implementación del Software 22

23. • La configuración puede ser un proceso simple que implique
establecer algunos parámetros internos en el software para
reflejar las preferencias del usuario.
• Configuración e implementación se ven a menudo como
temas de administración del sistema y por consiguiente, se
consideran fuera del ámbito de los procesos de ingeniería de
software.
• Desde luego, la buena practica administrativa ayuda a evitar
muchos problemas de seguridad que surgen de errores de
configuración e implementación.
• Sin embargo, los diseñadores tienen la responsabilidad de
“diseñar para implementación”. 23

24. Soporte de implementación:
• Se recomiendan cuatro formas de incorporar soporte de
implementación en un sistema:
1. Incluir soporte para ver y analizar las configuraciones.
2. Minimizar los privilegios por defecto.
3. Localizar parámetros de configuración.
4. Proporcionar formas sencillas de corregir vulnerabilidades
de seguridad.
24

25. Supervivencia del sistema
• La seguridad de los sistemas no depende solo de las
decisiones de diseño locales, si no también de la seguridad de
aplicaciones externas, servicios web y la infraestructura de la
red.
• Esto significa que, sin importar cuánta atención se ponga a la
seguridad, no es posible garantizar un sistema que podrá
resistir a ataques externos.
• La supervivencia o resiliencia es una propiedad emergente de
un sistema como su totalidad, y no una propiedad de
componentes individuales, que en sí mismos podrían ser no
supervivientes.
25

26. • La supervivencia de un sistema refleja su capacidad para
continuar la entrega de servicios empresariales esenciales o
críticos para la misión y para legitimar a los usuarios mientras
está bajo ataque o después de que se daño parte del sistema.
• El daño podrá ser causado por un ataque o una falla del
sistema.
• El trabajo en la supervivencia del sistema apunta al hecho de
que las vidas económica y social dependen de una
infraestructura crítica controlada por computadora.
26

27. Supervivencia
• Conservar la disponibilidad de los servicios críticos es la
escancia de la supervivencia. Esto significa que se debe
conocer:
• Los servicios del sistema más críticos para una empresa.
• La calidad mínima del servicio a preservar.
• Cómo pueden comprometerse dichos servicios.
• Cómo pueden protegerse tales servicios.
• Cómo recuperarse rápidamente si los servicios dejan de estar
disponibles.
27

28. Estrategias complementarias
1. Resistencia
• Evitar los problemas mediante la construcción de
capacidades en el sistema para repeler ataques.
2. Reconocimiento
• Detectar los problemas mediante la construcción de
capacidades del sistema para descubrir ataques y fallas.
3. Recuperación
• Tolerar los problemas por medio de la construcción de
capacidades en el sistema para entregar servicios esenciales 28
mientras está bajo ataque.

29. Etapas en el análisis de la
supervivencia
1.Revisar los
requerimientos y
la arquitectura del
sistema
4. Identificar los 2. Identificar los
puntos débiles y servicios y
estrategias de componentes
supervivencia. críticos
3. Identificar
ataques y
componentes 29
comprometidos

30. Actividades en Etapas
• Las actividades clave en cada una de las etapas en el análisis
de supervivencia son las siguientes:
1. Comprensión del sistema.
2. Identificación de servicios críticos.
3. Simulación de ataque.
4. Análisis de supervivencia.
30

31. Posibilidades de ataque
Ataque Un usuario malicioso siente rencor contra un
usuario acreditado del sistema. Consigue
acceso al sistema usando sus credenciales.
Coloca pedidos maliciosos y compra y vende
acciones, con la intención de causar
problemas al usuario autorizado.
Un usuario no autorizado corrompe la base de
datos
31