security in software development m.c. juan carlos olivares rojas may 2010

153
Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Upload: juana-alarcon-ramos

Post on 24-Jan-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Security in Software Development

M.C. Juan Carlos Olivares Rojas

May 2010

Page 2: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Conoce la importancia de la aplicación de la calidad en cada una de las fases en el desarrollo de un software.

• Genéricas

• Instrumentales: Capacidad de análisis y síntesis, Capacidad de organizar y planificar, Comunicación oral y escrita en su propia lengua, Conocimiento de una segunda lengua, Habilidades de gestión de información, Toma de decisiones.

Competencias

Page 3: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Interpersonales: Capacidad de trabajar en equipo interdisciplinario, Compromiso ético.

• Sistémicas: Capacidad de aplicar los conocimientos en la práctica, Habilidades de investigación, Capacidad de generar nuevas ideas (creatividad), Liderazgo, Capacidad para diseñar y gestionar proyectos, Iniciativa y espíritu emprendedor, Preocupación por la calidad, Búsqueda del logro.

Competencias

Page 4: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Actividades del Proyecto 50%

• Actividad Evaluadora Parcial Teórica 50%

Evidencias

Page 5: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Principios de seguridad informática.

• Definir y seguir las mejores prácticas de diseño.

• Análisis de riesgos.

• Creación de documentos seguros, herramientas y mejores prácticas para consumidores.

Temario

Page 6: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Políticas de código seguro.

• Políticas de prueba segura.

• Planeación de respuestas de seguridad.

• Modelos de Control de acceso basado en roles.

Temario

Page 7: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Las entregas de cada actividad se realizarán a más tardar el viernes de cada semana de forma presencial (a excepción de la última), podría ser antes en horario de clases en el cubículo.

• Actividad 1 semana del 17 al 21 de mayo• Programación de un sistema fortificado

de login (validación por formularios –no sólo password y usuario- al menos 5 campos, sistema escalonado de privilegios)

Actividades

Page 8: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Actividad 2 semana del 24 al 28 de mayo• Programación de mecanismos de cifrado

de datos tanto en almacenamiento como en comunicación. El cifrado deberá realizarse a través de criptosistemas asimétricos.

• Se sugiere la utilización de sistemas ya existentes (APIs, programas, etc.)

Actividades

Page 9: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Actividad 3 semana del 31 de mayo al 3 de junio. EXAMEN VIERNES 4 DE JUNIO.

• Programación de un módulo de contabilidad y de administración.

• La contabilidad es la generación de una bitácora en la que se indique los accesos a cada operación realizada por el sistema antes y después. La administración se hará a través de un sistema de privilegios, por ejemplo permitir solo x eliminaciones en un lapso de tiempo, o generar y reportes.

Actividades

Page 10: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• La contabilidad se hará de al menos 5 operaciones diferentes del sistema.

• La administración se hará sólo de dos operaciones.

• Exámenes de nivelación:

• Lunes 7 de junio examen teórico de la unidad 1 y 2.

Actividades

Page 11: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Martes 8 de junio examen práctico de la unidad 1 y 2

• Miércoles 9 de junio examen teórico de la unidad 3 y 4

• Jueves 10 de junio examen práctico unidad 3 (sólo una hora) o entrega de actividades de la unidad 4.

Actividades

Page 12: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

• Viernes 11 de junio. • Extra de Exámenes Teóricos.

• Lunes 14 de junio• Extra de exámenes prácticos (sólo uno).

Este mismo día se da calificaciones.

Actividades

Page 13: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

¿Qué es la seguridad?• El término seguridad proviene del latín

securitas. Se refiere a la seguridad como la ausencia de riesgo o también a la confianza en algo o alguien.

• Otras definiciones de seguridad: – Mecanismos de control que evitan el uso no

autorizado de recursos.

– Protección de información (datos) de daño intencionado o accidental

Page 14: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Seguridad• Los requisitos básicos de seguridad en

TICs son:

• Autenticación• Control de Acceso• Confidencialidad• Integridad• No repudio• Disponibilidad• Privacidad

Page 15: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Evolución de la seguridad• Al inicio de la computación, al sólo existir

pocas máquinas y pocos usuario la seguridad era prácticamente nula ya que se tenía confianza plena en las personas.

• Al popularizarse la computación personal trajo consigo que muchas personas pudiesen manejar computadoras. Esto originó que se dejará de confiar en las personas (diferencia entre vivir en un pueblo chico y uno grande).

Page 16: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Evolución de la Seguridad• Hasta este momento la seguridad era aun

controlable. Con la llegada de redes de computadoras (LAN) y el acceso a redes externas (WAN) como Internet el problema se agravó exponencialmente.

• Actualmente es cada vez mayor la cultura con respecto a la seguridad de las tecnologías de la información.

Page 17: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Evolución de la Seguridad• En un principio cuando las empresas

empezaron a considerar a las TICs como factores claves de éxito fue necesario que hubiese una persona encargada de la seguridad de dichos activos (1970s).

• En la década de 1980 fue necesaria la creación de grupos de trabajos de seguridad dentro de las empresas. Para la década de los 2000 la seguridad es cosa de todos los miembros.

Page 18: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Los grandes problemas• ¿Cuál es el elemento más importante en

una oganización? Los activos, principalmente activos de información.

• ¿cuál es el principal activo en una firma como AT&T, Telmex, etc.?

• Cobre en 1976 60%• Cobre, Fibra e Infraestructura 30% aprox.

en 2008.

Page 19: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Los grandes problemas• ¿Dónde está el demás dinero?• Sistemas de Información

• ¿Cúal es el activo más importante en Coca-Cola?

• La fórmula secreta. Es la misma desde 1886, sólo 3 personas la conocen en el mundo.

• Esta fórmula está protegida como secreto comercial.

Page 20: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Los grandes problemas

• El principal problema con la seguridad en TICs es que vivimos en una sociedad de información (conocimiento) donde está representa poder y el poder se ve reflejado en muchos factores, principalmente dinero.

• En México el 30% de los encargados de seguridad informática nunca se reúne con los altos directivos para hablar del aseguramiento de los activos de información.

Page 21: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Problemas de Seguridad• Prncipales mitos de la seguridad en TICs:

• Ya compramos un Firewall, ya tenemos seguridad ¿no?.

• Manejar el oscurantismo de lo inesperado.

• Nunca ha pasado nada, o al menos no nos hemos dado cuenta.

Page 22: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Problemas de Seguridad• No estoy en Internet, no necesito

seguridad.

• Mis empleados son gente de confianza!!!

• Ver el problema de la seguridad como un problema tecnológico.

• La seguridad es relativa. Lo único seguro es la muerte y los impuestos.

Page 23: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Problemas de Seguridad• El 1 de Mayo de 2004, el gusano Sasser

en una semana infectó a 18 millones de computadoras en el mundo, trajo a miles de negocios de rodillas y costó un estimado de 3,500 millones de Dólares.

• Algunas estadísticas en cuestión de problemas de seguridad son:

• 32% de la pérdida de datos es causada

por errores humanos.

Page 24: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Problemas de Seguridad• 25% de la pérdida de datos se deben a

fallas físicas

• 15% de la pérdida de datos es por la pérdida o robo del activo de información.

• La seguridad debe verse como una inversión no como un gasto. Es cierto que la seguridad es costosa pero es más costosa la inseguridad. “Ninguna medicina es útil si el paciente no la toma”

Page 25: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Problemas de Seguridad• La seguridad en TICs no solo afecta a

recursos computacionales, sino a cualquier activo de información de la empresa. Los activos pueden ser:

• Información propiamente tal : bases de datos, archivos, conocimiento de las personas.

• Documentos: contratos, manuales, facturas, pagarés, solicitudes de créditos.

Page 26: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Problemas de Seguridad• Software: aplicaciones, sistemas

operativos, utilitarios.

• Físicos: equipos, edificios, redes

• Recursos humanos: empleados internos y externos

• Servicios: electricidad, soporte, mantención.

Page 27: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Organismos internacionales • Existen muchas organizaciones

internacionales encargadas de la seguridad informática entre las principales destacan: ISO, IEEE, ACM, ISACA (Information System Audit and Control Association), ALSI (Academia Latinoamericana de Seguridad Informática).

• Dichos organismos se encargan de regular “mejores prácticas” (estándares, metodologías, guías base, etc.) en cuestión de seguridad informática.

Page 28: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad en seguridad• Una de las responsabilidades de la

administración de la función informática (administración de TICs) es garantizar la seguridad de los activos de información.

• El proceso de aseguramiento de los activos de información sigue una serie de pasos comunes:

• Identificación de activos de información y priorización de los mismos.

Page 29: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad de Seguridad• Se debe evaluar el activo para ver si

merece la pena implementar controles de seguridad.

• Se debe de guiar el trabajo a través de una normatividad o estándares los cuales nos indicarán: Qué trabajo hay que hacer, Quién lo debe hacer, Cuándo se hará y con qué frecuencia.

• Los estándares deben de ser claros (se deben adaptar a las necesidades internas)

Page 30: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad en Seguridad• No se puede administrar lo que no se

puede medir, es una de las máximas premisas de la administración. La seguridad debe de poderse cuantificar su desempeño en términos objetivos y tangibles.

• Después de medir hay que evaluar el desempeño e indicar que acciones se deben de tomar.

Page 31: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad en Seguridad• El componente crítico en todo sistema es

el usuario y la seguridad no es la excepción.

• ¿De qué sirve tener todo un sistema de seguridad avanzada en una casa si el usuario deja su llave pegada a la puerta (o su contraseña pegada al monitor de su computadora)?

• Se debe capacitar a los usuarios.

Page 32: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad de Seguridad• La gran mayoría de los incidentes de

seguridad ocurren desde dentro, teniendo el mito que es más frecuente hacia el exterior.

• La mejor forma de garantizar seguridad es a través de la planeación.

• La planeación se compone de tres fases: estimación, itinerario y seguimiento.

Page 33: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad de Seguridad• Existen dos enfoques de seguridad:

• En el discrecional, los usuarios tienen derechos de acceso diferentes (privilegios) por lo tanto son muy flexibles

• El control obligatorio, cada objeto está etiquetado con un nivel de clasificación y a cada usuario se le da un nivel de acreditación. Son sistemas jerárquicos y rígidos.

Page 34: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad de Seguridad• La autenticación es el proceso que consiste

en verificar que el usuario es quién dice ser.

• La autorización es el proceso para que un usuario pueda realizar una acción.

• Registro de auditoría es un archivo o base de datos en el que el sistema lleva la cuenta de las operaciones realizadas por los usuarios.

Page 35: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad de Seguridad

• Los controles de acceso obligatorio se rigen en base al principio de Bell-LaPadula:

• El usuario i puede recuperar el objeto j sólo si el nivel de acreditación de i es mayor o igual al nivel de clasificación de j (“propiedad de seguridad simple”).

Page 36: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Normatividad de Seguridad• El usuario i puede actualizar el objeto j

sólo si el nivel de acreditación de i es igual al nivel de clasificación de j.

• Los controles de acceso se dividen en 4: D, C, B y A.

• Donde D es la protección mínima, C es discrecional, B es obligatoria y A es verificada.

Page 37: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Nomrmatividad de Seguridad

• Dentro de C, se encuentran los niveles C1 (menos segura) y C2.

• DOS está clasificado en D

• ¿Qué es más seguro Windows o Linux?• Linux C1• Windows C2

Page 38: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Seguridad Física

• No sobrecargar los circuitos eléctricos y cordones de extensión. Asegurarse que el voltaje combinado no exceda la capacidad de los circuitos.

• Tener un extintor de fuegos tipos C.

• No utilizar ningún tipo de electrodoméstico dentro del site.

Page 39: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Seguridad Física

• No tomar líquidos dentro del site.

• No fumar.

• Tener letreros de seguridad.

• No situar equipos en sitios altos para evitar caídas. No colocar equipos cerca de ventanas.

Page 40: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Seguridad Lógica

• La seguridad lógica está encargada de proveer una serie de controles que ayuden a asegurar los activos de información

• Ejemplo: un acuerdo en papel por el cual un usuario que desea obtener un bien o servicio de la compañía está de acuerdo en su uso y respeta lo estipulado.

Page 41: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Seguridad del Personal

• El recurso humano o capital intelectual es de suma importancia y garantizar su seguridad física en entornos donde la tecnología ayuda en los procesos de negocio es vital.

• Todos los controles deben de tener indicado la forma en que deben de ser utilizados por los miembros de la organización.

Page 42: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Usuarios y grupos. Roles• En muchos sistemas se requiere de la

autenticación y autorización de los usuarios para acceder a los recursos del sistema. A este tipo de mecanismos se les llama controles de acceso.

• No sólo se deben indicar usuarios y roles a nivel de sistema de cómputo sino que deben de estar a nivel organizacional.

Page 43: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Usuarios y Grupos. Roles• Los roles son el papel o conjunto de

privilegios que tiene un usuario o grupo.

• Se recomienda no manejar cuentas genéricas ni contraseñas cortas. Aunque esto se determina en las políticas de controles de acceso. Otros factores a determinar son por ejemplo la frecuencia del cambio de la contraseña.

Page 44: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Usuarios y Grupos. Roles• Aquí son muy importantes los controles

administrativos dado que se debe deslindar responsabilidades a los usuarios.

• Se debe hacer distinción entre los dueños, custodios y usuarios del activo de información.

• Así por ejemplo un usuario es responsable de su contraseña de usuario y no el administrador del sistema

Page 45: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Intrusos• Se considera intruso a toda aquella

persona o software que entra al sistema sin autorización.

• Las intrusiones a los sistemas de cómputo son uno de las principales incidentes de seguridad.

• La intrusión viola el principio de confidencialidad de la información pudiendo alterar la integridad y disponibilidad del recurso.

Page 46: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Código malicioso

• Se considera código malicioso a todo aquel tipo de software que con o sin la ayuda de un humano intenta vulnerar huecos de seguridad en un sistema.

• La información puede ser atacada de la siguiente forma:Intercepción, Interrupción, Modificación y Fabricación.

Page 47: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Amenazas de Seguridad

• Los ataques pueden ser:• Ataques pasivos• Ataques activos

• Ingeniería Social• Gusanos• Troyanos• Adware

Page 48: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Amenazas de Seguridad

• Virus informáticos• Spyware• Dialers• Exploit• Bots• Pharming

Page 49: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Amenazas de Seguridad

• Backdoor

• Bomba fork

• Keystroke o Keyloggers

• Párasito Informático

Page 50: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Amenazas de Seguridad

• Phishings• Pornware• Rabbit• Rootkit• Spam• Pop-Ups• Bomba Lógica• Cookies (Malas)• Trampas y/o Inocentadas

Page 51: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Mecanismos de Seguridad

• Cifrado

• Autorización

• Autenticación

• Auditoría

Page 52: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Mecanismos de Seguridad

• Derecho a la intimidad

• Elaboración de perfiles

• Dispositivos biométricos

• Uso de VPN

• Uso de certificados de autoridad

Page 53: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Mecanismos de Seguridad

• Antivirus• Firewall

• Anti-Spyware• Anti-Rootkits

• Parches (Service Pack)• Configuraciones• Trucos, Trucos y más trucos

Page 54: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Mecanismos de Seguridad

• Hacer copias de seguridad• Habilitar las zonas de seguridad

• Utilizar antivirus y dos firewalls*

• Control para padres• Utilización de sockets seguros (SSL)

Page 55: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Mecanismos de Seguridad

• Emplear claves difíciles de acordar.*

• Comprobar el estado del sistema operativo.

• Comprobación del estado del hardware

• Evitar descargas de archivos.• IDS Sistemas Detector de Intrusos• Utilización de Proxys

Page 56: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Espionaje• El espionaje es considerado otro tipo de

incidente de seguridad caracterizado por la intrusión de un agente externo al sistema para el robo de información.

• El espionaje es difícil de detectar y puede ocurrir en una infinidad de niveles.

Page 57: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Piratería• La piratería es considerada un incidente

más de seguridad y tiene dos vertientes.

• La primera vertiente está enfocada al hecho de que utilizar software pirata hace más vulnerable a nuestros sistemas.

• Por otra parte nos exponemos a problemas de licenciamiento que pueden contribuir a la no disponibilidad de un servicio o proceso de negocio.

Page 58: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Síntomas de Riesgo• Un síntoma es la salida de una función

normal que indica una posible anormalidad. Un síntoma es subjetivo, es observado por el paciente y no medible

• Los síntomas pueden ser crónicos, retardados o esporádicos. Se pueden mejorar o empeorar.

• Un signo es notificado por otras personas

Page 59: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Administración de Riesgos• La administración de riesgos es una etapa

crucial para el aseguramiento de los activos de información.

• La administración de riesgos incluye la detección de riesgos y el control de los mismos.

• ¿Qué es el riesgo?• Es la probabilidad de que una actividad no

deseada ocurra.

Page 60: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Administración del Riesgo• Todas las actividades tienen riesgo. No

existe una actividad 100% ni 0% riesgosa.

Page 61: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

La vulnerabilidad • Es un factor interno caracterizado por un

hueco de seguridad (una debilidad del sistema) que puede ser aprovechada por una amenaza.

• Las vulnerabilidades deben ser los elementos que deban atender los controles de seguridad para asegurar a los activos de información.

Page 62: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Las amenazas • Son factores externos que pueden

aprovechar las vulnerabilidades de un sistema para exponer a un activo de información.

• Las amenazas son más difíciles de prevenir dado que ya no podemos anticiparnos del todo.

• Los controles tienden a minimizar las amenazas y vulnerabilidades.

Page 63: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Los ataques • Se dan cuando se combina una amenaza

con una vulnerabilidad.

• Los ataques son cuantificados al impacto que pueden producir, generalmente expresados en dinero.

• El impacto puede darse por ejemplo al no tener un recurso disponible causando pérdidas económicas al no poder trabajar o bien un daño de imagen social.

Page 64: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Administración del Riesgo

¿Cuál es la probabilidad de que este evento ocurra?

Page 65: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Los riesgos

• Calculado por el producto de la probabilidad de ocurrencia de la amenaza vs los impactos que tendría el activo de materializarse dicha amenaza.

• Los riesgos generalmente son calculados a nivel estadístico como el número de frecuencia en que ha ocurrido un evento contra el número total de eventos disponibles.

Page 66: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Evaluación del Riesgo• Existen muchas metodologías para

calcular el riesgo. Todas ellas dependen de los usuarios.

• Los riesgos se calculan en tres niveles: alto, medio y bajo.

• Los riesgos son calculados por dimensiones como impacto y frecuencia de ocurrencia.

Page 67: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Evaluación del Riesgo

Page 68: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Modelado de Riesgos

Riesgo

VulnerabilidadesAmenazas

Controles

Requerimientos de seguridad Valor del activo

Activos

Proteccióncontra

Explotan

Reduce

Aumenta

Establece

Aumenta

Exponen

TieneAumenta

Implementan

Impacto en la organización

Page 69: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Modelado de Riesgos• Deben intervenir además del personal de

seguridad, los dueños, custodios y usuarios de los activos de información.

• Existen dos tipos de análisis de riesgo: Existen dos tipos de análisis de riesgos:

• Cualitativo y cuantitativo.

Page 70: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Modelado de Riesgos

Cuantitativo Cualitativo

Ventajas

Se asignan prioridades a los riesgos según las repercusiones financieras; se asignan prioridades de los activos según los valores financieros. Los resultados facilitan la administración del riesgo por el rendimiento de la inversión en seguridad. Los resultados se pueden expresar en términos de negocio (ejemplo: perdidas financieras, costos anuales) La precisión tiende a incrementarse con el tiempo a medida que se gana experiencia y se acumula información histórica.

Permite la visibilidad y la comprensión de la clasificación de riesgos.

Resulta más fácil lograr el consenso.

No es necesario cuantificar la frecuencia de las amenazas.

No es necesario determinar los valores financieros de los activos.

Resulta más fácil involucrar a personas que no sean expertas en seguridad o en informática.

Page 71: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Modelado de RiesgosCuantitativo Cualitativo

Desventajas

Los valores de impacto asignados a los riesgos se basan en las opiniones subjetivas de los participantes. Los procesos para alcanzar el consenso y resultados creíbles consumen mucho tiempo. Los cálculos pueden ser complejos y lentos. Los resultados sólo se presentan en términos monetarios y pueden ser difíciles de interpretar por algunas personas. El proceso requiere experiencia, los participantes no pueden ser educados con facilidad a través del proceso.

No hay una distinción suficiente entre los riesgos importantes.

Es difícil de justificar la inversión en la implementación de los controles debido a que no hay bases de un análisis costo-beneficio.

Los resultados dependen de la calidad del equipo que este trabajando en el proceso.

Page 72: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Matriz de RiesgosNivel Definición de Ocurrencia

Alto La amenaza tiene una gran probabilidad de ocurrencia, y los controles que previenen

esta vulnerabilidad son inefectivos.

Medio La amenaza tiene probabilidad de ocurrencia, pero los

controles actuales pueden impedir que se explote dicha

vulnerabilidad.

Bajo La amenaza es de muy baja probabilidad o los controles

existentes evitan que suceda.

Page 73: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Matriz de RiesgosMagnitud del Impacto Definición del Impacto

Alto Si se explota la vulnerabilidad:1.Existe una pérdida monetaria de los activos tangibles o recursos más importantes de la empresa2.Se ve afectada la misión, reputación o interés de la empresa3.Existen pérdidas humanas o lesiones mayores

Medio Si se explota la vulnerabilidad:1.Puede resultar en la pérdida monetaria de activos o recursos2.puede violar o impedir la misión, reputación o interés de la empresa3.Puede resultar en una lesión

Bajo Si se explota la vulnerabilidad:1.Puede resultar en la pérdida de algunos recursos o activos2.Puede llegar a afectar de manera casi imperceptible la misión, reputación o interés de la empresa

Page 74: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Matriz de Riesgos

Nivel de Riesgo Impacto Vulnerabilidad

Muy Alto Alto Alto

Alto Alto Medio

Alto Medio Alto

Medio Alto Bajo

Medio Medio Medio

Medio Medio Bajo

Medio Bajo Alto

Medio Bajo Medio

Bajo Bajo Bajo

Page 75: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Matriz de RiesgosWEB

Server

Acceso no autorizado

B A M Se puede presentar el caso en el que personal no autorizado accese al equipo a nivel hardware o software durante el trayecto del Servicio hacia el sitio del Cliente, por lo cual impactaría en el desempeño adecuado del activo.

Front END Server

Falla de Hardware M A A Puede presentarse el caso en que alguna de las partes del activo funcione en forma deficiente, con lo cual afectaría en su funcionamiento general y afectaría también al aprovisionamiento adecuado del servicio.

WEB

Server

Negación de Servicio

A A MA Puede presentarse un ataque DoS dada la popularidad del sitio y la falta de controles para mitigar este ataque, si deja de responder el servicio causaría daños graves financieros y de imagen

Page 76: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Reglas del Negocio

76

Ejemplos más estructurados:Reglas de Operación

- 24x7 monitoreo y atención a fallas

- Equipo y solución de filtrado operada en XYZ por el equipo de Operaciones

- Cliente dueño de la cuenta, tiene privilegios para realizar cambios a los perfiles de sus usuarios vía el WEBKIT

- Filtrado esta dentro de la solución de los switches de Cache

- Perfiles definidos por el usuario no pueden cambiar ni modificar los perfiles. Tampoco pueden solicitar apoyo para cambiar perfiles, solo el usuario administrados puede hacer esto.

- Solamente el dueño (administrador) de la cuenta puede pedir cambios

- Soporte por medio del centro de atención para clientes de Internet Dial-Up

Atención a Clientes

- Facturación plana, adicional a la cuota de Dial-Up

- Puede ofrecerse un mes de prueba gratis

- Ajuste proporcional al tiempo que se utilizo cuando no entra la solicitud en los ciclos de facturación

Facturación

- Entrega hecha por parte de TMK (adicional a Dial-Up cuando se solicite en conjunto)

- No requiere configuración del lado del cliente

- Cliente se le da una clave de acceso para configurar los accesos adicionales con los perfiles que el requiera.

Entrega de Servicios

Page 77: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Pasos Recomendados en una Estrategia de Seguridad

Page 78: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Evaluación de Activos

Page 79: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Control de acceso • Es una tecnología, política, proceso o

procedimiento que contrarresta una amenaza y por consecuencia mitiga los riesgos asociados a un activo.

• Los controles de acceso se encargan de asegurar que los activos de información los utilicen quien debe de utilizarlos. Nótese que no se valida su correcto funcionamiento.

Page 80: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Controles de A. ISO 27000• A.11.1 Business requirement for access

control. Objetivo: una política de control de acceso debe ser establecida, documentada y revisada en base a los requerimientos de negocio.

• A.11.2 User access management Los temas que se norman en términos generales son: Habilitación de cuentas y registro de usuarios, mediante un proceso formal y expedito que incluya: altas, bajas, suspensiones y cambios de los mismos…

Page 81: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Controles de Acceso• A.11.3 User responsibilities • Objetivo: Prevenir acceso no autorizado y

evitar comprometer o el robo de información: Uso de contraseñas, se deben seguir las mejores prácticas en la selección y uso de contraseñas. Escritorio limpio y equipo no atendido, los usuarios deben guardar en forma segura la información crítica del negocio que esté en cualquiera de sus.

Page 82: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Control de Acceso• A.11.5 Operating system access control • Los accesos específicos a los sistemas

operativos de la infraestructura de TI deben ser controlados por procedimientos de identificación y autenticación robustos, se debe minimizar el desplegar una vez que los usuarios tienen acceso a estos sistemas información del tipo y versión del sistema operativo para evitar brindar información innecesaria…

Page 83: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Control de Acceso• A.11.6 Application and information access

control: El acceso a la información y sistemas de información ya sea por usuarios o personal de soporte debe ser restringido de acuerdo con el proceso de asignación de privilegios. La infraestructura de cómputo de los sistemas de información con información sensitiva debe ser separada para evitar accesos no autorizados. Se debe limitar y registrar el número de intentos fallidos de conexión de los usuarios de los sistemas de información.

Page 84: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line• Un base line es un conjunto de reglas

establecidas que forman una base de normas o prácticas sobre un proceso o sistema.

• Estas normas o prácticas son establecidas normalmente como una base de comparación entre organizaciones o empresas para verificar un nivel de cumplimiento.

Page 85: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line• Para poder establecer un base line, se

requieren varios elementos:

• basarse en algunos estándares internacionales o mejores prácticas,

• normas publicadas por algunas organizaciones reconocidas internacionalmente y

• experiencias obtenidas por la práctica en las organizaciones.

Page 86: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line• Establecer un base line en seguridad de

información, requiere mucha experiencia y madurez, no es muy práctico solo “copiar” base line de otras organizaciones dado que cada organización es diferente, tiene necesidades diferentes de acuerdo a sus niveles de madurez y necesidades.

• Generalmente están listados en orden de importancia aunque pueden no serlo.

Page 87: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control Acceso• Para cada activo de información y

sistema de información debe existir una bitácora externa al mismo para el registro de usuarios autorizados para acceder a los mismos.

• Debe establecerse procedimientos para verificar que el nivel de acceso concedido es apropiado para el propósito de negocio y que sea consistente con la directriz de control de accesos

Page 88: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso• El procedimiento de creación de usuarios

debe indicar como se otorga la autorización requerida antes de otorgar el acceso solicitado.

• El formato de solicitud de autorización para dar de alta o modificación de un usuario a un activo con los siguientes campos:– Nombre del usuario– Sistema o aplicación al cual requiere acceso,

revocación o modificación.

Page 89: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso– Organización a la que pertenece – Privilegios solicitados – Gerencia que solicita el acceso

• El usuario final que se le brinda el acceso debe recibir una notificación con el permiso otorgado, privilegios y responsabilidades asociadas a la cuenta o en su defecto la razón por la que fue denegado el acceso

Page 90: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso• Se debe asegurar no proporcionar

accesos hasta no completar los procedimientos de autorización establecidos.

• Se debe mantener un registro formal de todas las personas registradas con derecho a usar los activos de información o sistemas de información.

Page 91: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso• La autorización del acceso al sistema debe

realizarse por el administrador de a cargo de la custodia del activo de información o sistema de información y debe registrarse en la bitácora de usuarios autorizados

• La bitácora de registro de usuarios debe tener al menos los siguientes campos: – Nombre usuario – Organización a la que pertenece – Identificador del usuario en el sistema

Page 92: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso– Grupo al que pertenece (en caso que los

privilegios se administren por grupo)– Rol del usuario en el sistema: Administrador,

Desarrollador de software, Operador de respaldo, etc.

– Usuario de aplicación – Privilegios otorgados en el sistema o aplicación– Fecha en que fueron otorgados – Estado actual del usuario – Fecha del último cambio en los accesos – Persona que autorizó la creación de usuario y

los privilegios otorgados

Page 93: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso• En el caso que un activo de información o

sistema de información se entregue en custodia a una determinada organización se debe firmar una carta responsiva en la cual acepta la responsabilidad de la custodia del activo de información así como de las operaciones autorizadas a ejecutar

Page 94: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso• La organización usuaria debe notificar al

custodio del activo de información o del sistema de información cuando un usuario haya cambiado de rol o haya salido de la compañía para la revocación inmediata del acceso.

• Se debe remover inmediatamente los derechos de acceso cambiado de área de trabajo o abandonado la organización.

Page 95: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Base Line Control de Acceso• Se debe de verificar periódicamente las

cuentas de los usuarios y remover aquellos identificadores de usuarios que resulten redundantes.

• Métricas:• Número de Altas y Bajas de usuarios • Número de autorizaciones para dar de

alta o modificación de un usuario a un activo de información

• Número de usuarios con acceso permitido.

Page 96: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Detección de intrusos • La detección de intrusos es una actividad

díficil de llevarse acabo.

• Se puede realizar la detección de intrusos con herramientas como la auditoria, los controles de acceso entre otras.

• Más que la detección nos interesa el aseguramiento del activo.

Page 97: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Detección de código malicioso

• La detección de código malicioso también es una actividad complicada de llevar acabo dado que no tenemos la certeza de las actividades que va a realizar un software hasta que este se ejecuta.

• Basándose en ese principio nuestra seguridad está condicionada a los efectos visibles (patrones o firmas) que se presenten y aun conociéndolos no tenemos la certeza absoluta que pueda ser malicioso.

Page 98: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditorias de seguridad• La auditoria es la evaluación de una

persona, sistema, proceso, proyecto o producto.

• La auditoría se utiliza como mecanismo de control para logar el aseguramiento de la calidad.

• La auditoría se centra en verificar y validar el control interno de una organización. En cuestión de seguridad es lo mismo.

Page 99: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditorías de Seguridad• La auditoría describe como se hacen las

cosas, no tanto su existencia. Por ejemplo al auditar una base de datos se está validando el uso de la base de datos y no su existencia.

• La auditoría es todo un proceso de verificación de lo que se dice ser con lo que se tiene.

• Las auditorías pueden ser generales o técnicas

Page 100: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditoría de Seguridad• La auditoría de seguridad es una

auditoria técnica. Se recomienda que sea una auditoria de control superior (externa) aunque es deseable que se haga de manera interna para control interno.

• La auditoría en general y la especializada en seguridad debe de realizarse en los procesos de negocios de las organizaciones.

Page 101: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditorías de Seguridad• ¿Qué es lo que se audita?

• Activos de información y la información misma respecto a como se usa y que se cumplan las políticas de seguridad.

Page 102: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditorías de Seguridad

Page 103: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditorías de Seguridad• El proceso de auditoria finaliza con un

reporte en el cual se indican los hallazgos encontrados y la evidencia que confirma dichos hallazgos.

• Si no se tiene evidencia sustantiva no se puede sustentar ninguna opinión profesional.

• Con la evidencia recabada se debe de poder reconstruir la instantánea de lo evaluado.

Page 104: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditorías de Seguridad• Para realizar auditorías de seguridad se

requiere previamente realizar planeación. Sino se tiene un plan de auditorías no se puede garantizar que es seguro.

• Se pueden utilizar herramientas de análisis de vulnerabilidades para revisar posibles activos.

• Es más recomendable utilizar versiones propias de análisis de vulnerabilidades.

Page 105: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Auditorías de Seguridad• Se pueden realizar a través de forma

manual o auxiliándose de alguna herramienta actualizada.

• Los auditores no solucionan los problemas encontrados, sólo los reportan de la misma forma que en desarrollo de software un tester prueba no codifica.

Page 106: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Teoría Criptográfica• El criptoanálisis estudia el proceso de

descifrar los mensajes poniéndolos en su forma original, o bien tratando de romper la seguridad.

• La forma correcta del término es cifrar y descifrar la información.

• La criptografía es una ciencia muy antigua.

Page 107: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Las claves• Las claves o llaves son el mecanismo por

el cual se pueden cifrar y descifrar la información.

• Existen varios algoritmos de cifrado cayendo en el área de simétricos y asimétricos.

• ¿Qué diferencia existente entre ellos?

Page 108: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Las Claves• En los simétricos la misma clave se utiliza

para cifrar y descifrar el mensaje. En los asimétricos se utilizan llaves distintas siendo el esquema más generalizado el PKI (Public Key Infrastructure).

• Se recomienda utilizar claves asimétricas, aunque los mecanismos simétricos son más fáciles de administrar.

Page 109: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Aplicaciones criptográficas

• Las aplicaciones de la criptografía son muchas, en general se trata que la información sea menos vulnerable a cualquier tipo de ataque.

securesender

securereceiver

channel data, control messages

data data

Alice Bob

Trudy

Page 110: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Aplicaciones criptográficas

Page 111: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Protocolos criptográficos

Page 112: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Criptografía Simétrica

Page 113: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Cifrado Asimétrico

Page 114: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Comparación

Page 115: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Tipos de Cifrado

Page 116: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Criptografía de Llave Simétrica

Cifrado por Sustitución: substituir un caracter por otro– Cifrado monoalfabetico:

Texto plano: abcdefghijklmnopqrstuvwxyz

Texto cifrado: mnbvcxzasdfghjklpoiuytrewq

Texto Plano: bob. i love you. alice

Texto Cifrado: nkn. s gktc wky. mgsbc

E.g.:

Page 117: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

DES: Data Encryption Standard• Estándar de Cifrado NIST 1993• Llave de 56 bits, Entrada de 64 bits• How secure is DES?

– Con el poder de cálculo actual se puede descifrar en 4 meses

• Mayor seguridad:

– Usar tres llaves secuenciales (3-DES) en cada dato

– Usar encdenamiento de bloques

Page 118: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

DES

Page 119: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

3DES

Page 120: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Criptografía de Llave Pública

Simétrica• Requiere enviar la

llave por un canal seguro

• ¿Cómo se deben poner de acuerdo para determinar la llave si previamente no se conocen los emisores y receptores?

Asimétrica Enfoque diferente [Diffie-

Hellman76, RSA78]

Emisor y Receptor no comparten la llave secreta

La llave pública la conoce cualquiera

La llave privada solo la conocen cada quien.

Page 121: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Public key cryptography

plaintextmessage, m

ciphertextencryptionalgorithm

decryption algorithm

Bob’s public key

plaintextmessageK (m)

B+

K B+

Bob’s privatekey

K B-

m = K (K (m))B+

B-

Page 122: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Firmas digitales, huellas digitales y certificados digitales

• Las aplicaciones de criptografía van más allá de simplemente cifrar un texto. En algunas ocasiones se necesita verificar la autenticidad de algo para ello están las firmas, las huellas y los certificados digitales.

Page 123: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Firmas DigitalesFirma digital para un mensaje m:• Bob “firma” m cifrándolo con su llave

privada KB, creando un mensaje “firmado” KB(m)

--

Querida Alice!

Hola …)

Bob

Mensaje de Bob, m

Algoritmo de cifrado de cllave publica

Llave privada de Bob

K B-

Mensaje de Bob, m, firmado con su llave primaria

K B-(m)

Page 124: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Firmas Digitales• Si Alice recibe un mensaje m, con firma digital KB(m)

• Alice verifica m firmada por Bob aplicando la clave pública de Bob KB a KB(m) entonces verifica KB(KB(m) ) =

m.

• Si KB(KB(m) ) = m, quien haya frmado m debió haber

usado la llave privada de Bob.

+ +

-

-

- -

+

Alice comprobó que: Bob firmó m. Nadie más firmo m. Bob firmo m y no m’.

No repudio-

Page 125: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Certificados de Clave PúblicaProblema de las llaves públicas:• Cuando Alice obtiene la llave pública de (de un

sitio Web, correo, diskette), ¿Cómo sabe realmente que es la clave pública de Bob?

Solución:• Confiando en una autoridad certificadora (CA)

Page 126: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Certification Authorities

• Certification Authority (CA): liga una llave pública K a una Entidad privada E.

• E registra s llave pública con CA.– E provee de “pruebas de identidad” a la CA. – CA crea un certificado que liga a E con su llave

Pública.– El certificado contiene la llave pública de firmada por

la CA.Bob’s public

key K B+

Bob’s identifying informatio

n

digitalsignature(encrypt)

CA private

key K CA-

K B+

certificate for Bob’s public

key, signed by CA

-K CA(K ) B

+

Page 127: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Autoridades de Certificación• Cuando Alice quiere la llave pública de Bob:

– Obtiene el certificado de Bob (por medio de Bob or de alguién más).

– Aplica la llave pública de CA al certificado de Bob, para obtener la llave pública de Bob.

Bob’s public

key K B+

digitalsignature(decrypt)

CA public

key K CA

+

K B+

-K CA(K ) B

+

Page 128: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Un Certificado contiene

• Número de serie (único)• Información acerca del dueño certificadocertificate,

incluyendo el algoritmo de validación.

Page 129: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Pretty good privacy (PGP)• Estándar de Facto de

Firma de Correo Electrónico

• Usa criptografía simétrica, asimetrica.

• Provee de secrecía, auntenticación del emisor e integridad.

• Inventor: Phil Zimmerman, (3 años de investigación)

---BEGIN PGP SIGNED MESSAGE---Hash: SHA1

Bob:My husband is out of town tonight.Passionately yours, Alice

---BEGIN PGP SIGNATURE---Version: PGP 5.0Charset: noconvyhHJRHhGJGhgg/

12EpJ+lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2

---END PGP SIGNATURE---

Un mensaje firmado con PGP:

Page 130: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Criptoanálisis• Algunos ejemplos de algoritmos

simétricos:

Page 131: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

RSA• Un ejemplo de RSA

Page 132: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Políticas y Normas• El gran problema de la seguridad:

“Tenemos (mas que suficientes) tecnologías de seguridad, pero no sabemos como estamos (en el caso de que lo estemos) de seguros”.

• En términos genéricos tenemos mejor calidad de vida pero eso no nos garantiza tener seguridad.

Page 133: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Políticas y Normas• Como se había comentado lo más

importantes es saber lo que se quiere proteger (políticas y normas)

• Algunos problemas de seguridad en SO:

• Arranque inseguro– ¿Quién lo arranca?– ¿Es realmente el código original?

Page 134: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Seguridad en el Desarrollo de Software

• Hasta hace poco muy pocas metodologías de desarrollo de software consideraban a la seguridad como un requerimiento básico de calidad.

• La tendencia ha cambiado bastante a tal punto que existen metodologías como SDL (Microsoft) que manejan roles y procesos de seguridad.

Page 135: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Seguridad en Desarrollo de Sw• La parte más importante de la seguridad

es considerarlo como un requerimiento obligatorio (implícito) a como actualmente son las validaciones de entrada.

• Parte importante de la seguridad se puede ver desde diferentes enfoques en cada parte del proceso de desarrollo (análisis, diseño, implementación, pruebas, etc.) pero siempre es importante las arquitecturas de del software con respecto a la seguridad.

Page 136: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Código y poder

• El código fuente es poder– Tanto para defenderse como para atacar

• Compartir el código es compartir el poder.– Con los atacantes y defensores

• Publicar el código fuente sin hacer nada más degrada la seguridad

• Por el contrario, publicar el código fuente permite a los defensores y a otros elevar la seguridad al nivel que les convenga.

Page 137: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Software Seguro

• El software Fiable es aquel que hace lo que se supone que debe hacer.

• El software Seguro es aquel que hace lo que se supone que debe hacer, y nada mas.– Son los sorprendentes “algo mas” los que producen

inseguridad.

• Para estar seguro, debes de ejecutar solo software perfecto :-)

• O, hacer algo para mitigar ese “algo mas”

Page 138: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

El problema M & M

The ‘M&M’ ProblemCubierta Dura

Resuelto por seguridad perimetral

Interior SuaveEl problema

adicionalque hay que

resolver

Page 139: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Arquitectura Fortaleza• Protección perimetral• Estático, no diferenciado• Difícil de modificar y adaptar• Descuida el insider problem

Page 140: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Arquitectura Aeropuerto• Mayor flexibilidad

• Múltiples zonas de seguridad basadas en roles

• Protecciones multinivel interzonas

• Colección jerárquica de fortalezas interactuantes

Page 141: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Arquitectura Aeropuerto

Page 142: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Arquitectura P2P• Conceptos dinámicos de confianza,

autenticación y autorización

• Requerimientos comerciales->Requerimientos tecnológicos

• Inferir en tiempo real qué quiero hacer y con quién quiero hacerlo

• Puede requerir servicios provistos por TTP (Trusted Third Parties).

Page 143: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Arquitectura SD3• Propuesta por Microsoft en SDL

SeguroSeguro porpor diseñodiseño

SeguroSeguro dede formaforma

predeterminadapredeterminada

SeguroSeguro enen implementaciónimplementación

ArquitecturaArquitectura yy códigocódigo segurossegurosAnálisis de amenazasAnálisis de amenazasReducción de los puntos Reducción de los puntos vulnerablesvulnerablesMenorMenor áreaárea expuestaexpuesta aa ataquesataquesLas características que no se usan Las características que no se usan están desactivadas de forma están desactivadas de forma predeterminadapredeterminadaPrivilegios mínimosPrivilegios mínimos

Protección:Protección: detección,detección, defensa, defensa, recuperaciónrecuperación yy administraciónadministraciónProceso: guías de procedimientos Proceso: guías de procedimientos y de arquitecturay de arquitecturaUsuarios: aprendizajeUsuarios: aprendizaje

Page 144: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Consejos de Seguridad• Tenga en cuenta la seguridad

– Al comienzo del proceso– Durante el desarrollo– Durante la implementación– En los hitos de revisión del software

• No deje de buscar errores de seguridad hasta el final del proceso de desarrollo

Page 145: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Los retos de la seguridad en las empresas

Servidores con roles múltiples y

variados

Servidores con roles múltiples y

variados

Recursos limitados para implementar soluciones

de seguridad

Recursos limitados para implementar soluciones

de seguridad

Amenazas internas o

accidentales

Amenazas internas o

accidentales

Sistemas obsoletosSistemas obsoletos

El acceso físico rompe muchas

medidas de seguridad

El acceso físico rompe muchas

medidas de seguridad

Falta de expertos en seguridad

Falta de expertos en seguridad

Consecuencias legales

Consecuencias legales

Page 146: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Policies, Procedures, & Awareness

Policies, Procedures, & Awareness

Seguridad FísicaSeguridad Física

Fortificacion del SO, Autenticación, Parches

Firewalls, Acceso a Red, Redes de Cuarentena

Guardias, Cerraduras, etc.

Segmentos de Red, IPSec

Fortificación, antivirus

ACLs, cifrado, EFS

Documentación, formación

Perímetro

Red Interna

Host

Application

Datos

Segmentos de Red, IPSec

Guardias, Cerraduras, etc.

Firewalls, Acceso a Red, Redes de Cuarentena

Defensa en Profundidad

Políticas, Procesos y Concienciación

Políticas, Procesos y Concienciación

Seguridad FísicaSeguridad Física

Usando una estrategia por capas• Se incrementa el riesgo de ser detectado para el

atacante• Se reduce su probabilidad de tener éxito

Fortificación del SO, Autenticación, Parches

Fortificación, antivirus

ACLs, cifrado, EFS

Documentación, formación

Perímetro

Red Interna

Host

Aplicación

Datos

Page 147: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Consejos de Seguridad• Programar bien!!!

• No utilizar funciones inseguras que puedan provocar fallos de desbordamiento.

• En C/C++ se debe tener mucho cuidado con los punteros

• Se recomienda no utilizar funciones como: strcpy() strcat() sprintf() scanf()sscanf() fscanf() vfscanf(), entre otras.

Page 148: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Fortificación• El “hardening” (fortificación o

endurecimiento) es una técnica de control de seguridad que consiste en tomar medidas elevadas de seguridad en los servidores o equipos de usuarios.

• No existe un conjunto de pasos únicos, esto se maneja de forma variada, dependiendo del SO y de los servicios disponibles aunque generalmente existen directrices y líneas base que se pueden seguir.

Page 149: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Fortificación• Revisa que servicios se deben de

ejecutar.

• Revisa el grado de seguridad continuamente.

• Manejar distintos tipos de restricciones.

• Utiliza certificaciones como common criteria.

Page 150: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Oscurantismo• Es un mecanismo de seguridad que

consiste en ocultar información y servicios.

• Un servidor Web se ejecuta en el puerto 80 pero puede cambiarse de puerto. Esto garantiza cierta seguridad hasta que no se descubra el servicio.

• El código abierto es un ejemplo claro que el oscurantismo no funciona.

Page 151: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Oscurantism0• NO SE DEBEN DE UTILIZAR NUNCA

CONFIGURACIONES PREDETERMINADAS.

• Se deben cambiar las configuraciones predeterminadas de forma robusta antes de entrar a la red.

• El conocimiento de configuraciones predeterminadas es un vector ataque muy utilizado.

Page 152: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

Referencias• Pressman, R. (2004). Ingeniería del

Software un Enfoque Práctico. Sexta Edición. McGraw Hill.

• Guido, J. y Clements, J., “Administración Exitosa de Proyectos”, Segunda Edición, Thomson, México, 2003, ISBN: 0-324-07168-X.

Page 153: Security in Software Development M.C. Juan Carlos Olivares Rojas May 2010

¿Preguntas?