Security in Software Development

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

Competencias 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 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.

Evidencias Actividades del Proyecto 50%
Actividad Evaluadora Parcial Teórica 50%

Temario 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 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.

Actividades 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 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 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 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 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 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.

¿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

Seguridad Los requisitos básicos de seguridad en TICs son:
Autenticación Control de Acceso Confidencialidad Integridad No repudio Disponibilidad Privacidad

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).

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.

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.

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 % Cobre, Fibra e Infraestructura 30% aprox. en 2008.

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.

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.

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.

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.

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.

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”

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.

Software: aplicaciones, sistemas operativos, utilitarios. Físicos: equipos, edificios, redes Recursos humanos: empleados internos y externos Servicios: electricidad, soporte, mantención.

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.

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.

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)

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.

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.

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.

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.

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.

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”).

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

Amenazas de Seguridad Los ataques pueden ser: Ataques pasivos
Ataques activos Ingeniería Social Gusanos Troyanos Adware

Amenazas de Seguridad Virus informáticos Spyware Dialers Exploit Bots
Pharming

Amenazas de Seguridad Backdoor Bomba fork Keystroke o Keyloggers
Párasito Informático

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

Mecanismos de Seguridad
Cifrado Autorización Autenticación Auditoría

Derecho a la intimidad Elaboración de perfiles Dispositivos biométricos Uso de VPN Uso de certificados de autoridad

Antivirus Firewall Anti-Spyware Anti-Rootkits Parches (Service Pack) Configuraciones Trucos, Trucos y más trucos

Hacer copias de seguridad Habilitar las zonas de seguridad Utilizar antivirus y dos firewalls* Control para padres Utilización de sockets seguros (SSL)

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

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.

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.

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

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.

Administración del Riesgo
Todas las actividades tienen riesgo. No existe una actividad 100% ni 0% riesgosa.

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.

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.

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.

Administración del Riesgo
¿Cuál es la probabilidad de que este evento ocurra?

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.

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.

Evaluación del Riesgo

Modelado de Riesgos Riesgo Amenazas Vulnerabilidades Protección contra
Explotan Amenazas Vulnerabilidades Protección contra Aumenta Aumenta Exponen Riesgo Activos Controles Reduce Establece Tiene Implementan Aumenta Valor del activo Requerimientos de seguridad Impacto en la organización

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.

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.

Modelado de Riesgos Cuantitativo 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.

Definición de Ocurrencia
Matriz de Riesgos Nivel 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.

Definición del Impacto
Matriz de Riesgos Magnitud del Impacto Definición del Impacto Alto Si se explota la vulnerabilidad: Existe una pérdida monetaria de los activos tangibles o recursos más importantes de la empresa Se ve afectada la misión, reputación o interés de la empresa Existen pérdidas humanas o lesiones mayores Medio Puede resultar en la pérdida monetaria de activos o recursos puede violar o impedir la misión, reputación o interés de la empresa Puede resultar en una lesión Bajo Puede resultar en la pérdida de algunos recursos o activos Puede llegar a afectar de manera casi imperceptible la misión, reputación o interés de la empresa

Matriz de Riesgos Nivel de Riesgo Impacto Vulnerabilidad Muy Alto Alto
Medio Bajo

Matriz de Riesgos WEB 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 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. Negación de Servicio 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

Reglas del Negocio Ejemplos más estructurados: Atención a Clientes
- 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 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. Facturación - 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 Entrega de Servicios - 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.

Pasos Recomendados en una Estrategia de Seguridad

Evaluación de Activos

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.

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…

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.

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…

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.

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.

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.

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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

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.

¿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.

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.

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. Moodle Case Exist many user created by machines (spam) Solutions?

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.

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.

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?

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.

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. Alice Bob channel data, control messages secure sender secure receiver data data Trudy

Aplicaciones criptográficas

Protocolos criptográficos

Criptografía Simétrica

Cifrado Asimétrico

Comparación

Tipos de Cifrado

Criptografía de Llave Simétrica
Cifrado por Sustitución: substituir un caracter por otro Cifrado monoalfabetico: Texto plano: abcdefghijklmnopqrstuvwxyz Texto cifrado: mnbvcxzasdfghjklpoiuytrewq E.g.: Texto Plano: bob. i love you. alice Texto Cifrado: nkn. s gktc wky. mgsbc

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

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.

Public key cryptography
+ Bob’s public key K B - Bob’s private key K B plaintext message, m encryption algorithm ciphertext decryption algorithm plaintext message K (m) B + m = K (K (m)) B + -

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.

Firmas Digitales Firma digital para un mensaje m:
Bob “firma” m cifrándolo con su llave privada KB, creando un mensaje “firmado” KB(m) - - K B - Mensaje de Bob, m Llave privada de Bob K B - (m) Querida Alice! Hola …) Bob Mensaje de Bob, m, firmado con su llave primaria Algoritmo de cifrado de cllave publica

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 -

Certificados de Clave Pública
Problema 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)

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. - K CA (K ) B + digital signature (encrypt) K B + Bob’s public key K B + CA private key certificate for Bob’s public key, signed by CA - Bob’s identifying information K CA

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. K B + - K CA (K ) B + digital signature (decrypt) Bob’s public key K B + CA public key + K CA

Un Certificado contiene
Número de serie (único) Información acerca del dueño certificadocertificate, incluyendo el algoritmo de validación.

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) Un mensaje firmado con PGP: ---BEGIN PGP SIGNED MESSAGE--- Hash: SHA1 Bob:My husband is out of town tonight.Passionately yours, Alice ---BEGIN PGP SIGNATURE--- Version: PGP 5.0 Charset: noconv yhHJRHhGJGhgg/12EpJ+lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2 ---END PGP SIGNATURE---

Criptoanálisis Algunos ejemplos de algoritmos simétricos:

RSA Un ejemplo de RSA

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.

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?

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.

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.

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.

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” Doing Something Code Auditing: static or dynamic analysis of programs to detect flaws, e.g. ITS4 and friends Vulnerability Mitigation: compiled in defense that block vulnerability exploitation at run-time, e.g. StackGuard and friends Behavior Management: OS features to control the behavior of programs Classic: mandatory access controls Behavior blockers: block known pathologies

Resuelto por seguridad perimetral
El problema M & M The ‘M&M’ Problem Interior Suave El problema adicional que hay que resolver Cubierta Dura Resuelto por seguridad perimetral

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

Arquitectura Aeropuerto
Mayor flexibilidad Múltiples zonas de seguridad basadas en roles Protecciones multinivel interzonas Colección jerárquica de fortalezas interactuantes

Arquitectura Aeropuerto

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).

Arquitectura SD3 Propuesta por Microsoft en SDL Seguro por diseño
Arquitectura y código seguros Análisis de amenazas Reducción de los puntos vulnerables Menor área expuesta a ataques Las características que no se usan están desactivadas de forma predeterminada Privilegios mínimos Seguro de forma predeterminada Protección: detección, defensa, recuperación y administración Proceso: guías de procedimientos y de arquitectura Usuarios: aprendizaje Seguro en implementación

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

Los retos de la seguridad en las empresas
Recursos limitados para implementar soluciones de seguridad Servidores con roles múltiples y variados Sistemas obsoletos Amenazas internas o accidentales Consecuencias legales Falta de expertos en seguridad El acceso físico rompe muchas medidas de seguridad

Defensa en Profundidad
Usando una estrategia por capas Se incrementa el riesgo de ser detectado para el atacante Se reduce su probabilidad de tener éxito Policies, Procedures, & Awareness Seguridad 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 Políticas, Procesos y Concienciación Seguridad Física Datos ACLs, cifrado, EFS Aplicación Fortificación, antivirus Fortificación del SO, Autenticación, Parches Host Red Interna Segmentos de Red, IPSec Firewalls, Acceso a Red, Redes de Cuarentena Perímetro Guardias, Cerraduras, etc. Documentación, formación

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.

Un error frecuente Nunca debe asumirse que establecer seguridad perimetral es todo lo que debe hacerse Los Firewalls pueden ser comprometidos Algunos puertos estarán abiertos para la comunicación con el exterior y los ataques se harán, sobre todo, contra ellos Los ataques pueden ser lanzados internamente, y las estadísticas dicen que eso será lo más probable

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.

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.

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.

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.

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: X.

¿Preguntas?

Security in Software Development

Presentaciones similares

Presentación del tema: "Security in Software Development"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Security in Software Development

Presentaciones similares

Presentación del tema: "Security in Software Development"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback