INSTITUTO TECNOLOGICO SUPERIOR DE FELIPE CARRILLO PUERTO

INGENIERIA DE SOFTWAREMAESTRA: ING. CINTIA ISABEL ARCEO FUENTESUNIDAD 4IDENTIFICACION DE METODOS DE SEGURIDADINTEGRANTES: TANYA D. SANCHEZ CHAN NATANAEL I. TUN AGUILARJAVIER E. RODRIGUEZ ROJASJ 1 GRUPO: A Felipe carrillo puerto Q. Roo a 19 de Mayo del 2014

INTRODUCCIONEn la actualidad el software requiere de seguridad para poder ser aplicado siendo as ms eficientes y difciles de crakear. Pero para poder saber acerca de la seguridad del software se deben identificar los tipos de seguridad que existen y as poder aplicarlas, de esta forma tendremos un software seguro.Si se sabe de seguridad solo es que para poder tener un buen software tiene que ser seguro pero no se sabe que tcnicas hay que usar para poder poner seguridad al software ni aun se sabe cmo implementarlo.A continuacin veremos las maneras que existen de identificar la seguridad del software desde donde empezar para sabes si el software es seguro o no, como podemos identificar su seguridad.

IDENTIFICACION DE METODOS DE SEGURIDADActualmente la mayora de los procesos de desarrollo no incluyen seguridad, o bien la incluyen al final (etapa de testing)El costo de solucionar las vulnerabilidades es mayor cuanto ms tarde se detectan las mismas (igual que los bugs)

Grandes mitos y excusas flacas La seguridad de la aplicacin es responsabilidad del programador. Nadie sabe cmo funciona, por ende, no la van a atacar. Si no se encontraron vulnerabilidades hasta ahora A nadie le interesara atacar nuestra aplicacin. La aplicacin es segura porque corre detrs de un firewall. La aplicacin es segura porque usa encripcin. Si no corre como Administrador / root, no funciona. Si, ese feature (que es inseguro) viene habilitado por default, pero el administrador lo puede deshabilitar. No hay manera de explotarla. No hay tiempo para incluir seguridad.

Tendencia actualParticipacin de Seguridad Informtica desde el comienzo de todos los proyectos de desarrollo.Incorporar seguridad a lo largo de todas las etapas del ciclo de vida del desarrollo de software (SDLC). Anlisis Diseo Codificacin Testing DeploymentSeguridad en el anlisis de requerimientosDurante el anlisis de requerimientos, se pueden identificar diversas caractersticas que derivarn en los requerimientos de seguridad del software.Por ejemplo:

Arquitectura de la aplicacin Cliente/servidor o Desktop?Plataforma donde correr la aplicacin PC / Palm / Telfono celularTipos de datos que se almacenan o transfieren Confidenciales / pblicosRequerimiento de conformidad con normativas y marcos regulatorios SOX, PCI-DSS, A 4609 Tipos de registro que el sistema debe generarAcceso a recursos, uso de privilegios, etc. Perfiles de usuario necesarios para la aplicacinAdministrador, revisor, editor, usuario bsico, etc. Tipos de acceso a los datos por parte de cada perfilLectura, escritura, modificacin, agregado, borrado, etc. Acciones sobre el sistema que puede hacer cada perfilCambiar la configuracin del sistemaArrancar o detener servicios Modos de autenticacinPasswords, Tokens, Biomtricos1 factor, 2 factores, etc.

Seguridad en el diseo

Muchas de las vulnerabilidades encontradas en aplicaciones tuvieron su causa en errores de diseo. Ej.: Aplicacin Home banking (WEB) Inclua el nmero de cuenta en el request de transferencias No validaba que la cuenta origen perteneciera al usuario logueado Vulnerabilidad: Transferencias desde cuentas ajenas Aplicacin de Adm y Finanzas (Consola Unix) Tomaba el usuario de una variable de entorno Permita que el usuario escapara a un shell Vulnerabilidad: Se puede establecer un usuario arbitrario Buenas prcticas para el diseo de una aplicacin segura Reduccin de Superficie de ataque Criterio del menor privilegio Fallar de manera segura Criterio de defensa en profundidad Diseo seguro de mensajes de error Diseo seguro de autenticacin Separacin de privilegios Interaccin amigable con Firewalls e IDS's. Administracin segura informacin Sensible Diseo de Auditora y Logging Anlisis de riesgo Anlisis de riesgo Threat Modeling Tcnica formal, estructurada y repetible que permite determinar y ponderar los riesgos y amenazas a los que estar expuesta nuestra aplicacin. Consta de las siguientes etapas: 1) Conformar un grupo de anlisis de riesgos 2) Descomponer la aplicacin e identificar componentes clave. 3) Determinar las amenazas a cada componente de la aplicacin. 4) Asignar un valor a cada amenaza. 5) Decidir cmo responder a las amenazas. 6) Identificar las tcnicas y tecnologas necesarias para mitigar los riesgos identificados. Mtodo STRIDE Ayuda a identificar amenazas en los componentes de un sistema Su nombre es un acrnimo de: Spoofing Identity: Suplantar la identidad de otro usuario o servicio. Tampering with Data: Modificar maliciosamente datos almacenados. Repudiation: Imposibilidad de identificar el autor de una accin. Information Disclosure: Divulgar informacin a usuarios no autorizados. Denial of Service: Provocar que un servicio deje de funcionar. Elevation of privilege: Conseguir privilegios mayores a los asignados Mtodo DREAD Ayuda a ponderar las amenazas identificadas. Es un acrnimo de los siguientes 5 tems: Damage Potencial: Cun importante es el dao de esta amenaza? Reproducibility: Cun reproducible es la vulnerabilidad? Exploitability: Cun fcil es de explotar? Affected Users: Cules y cuntos usuarios se veran afectados? Discoverability: Cun fcil de descubrir es la vulnerabilidad?

Seguridad en la codificacin

La falta de controles adecuados en la codificacin, muchas veces deriva en vulnerabilidades que pueden comprometer a la aplicacin o a los datos de la misma Los tipos de vulnerabilidades ms habituales son: Stack buffer overflows Heap buffer overflows SQL Injections Cross Site Scripting (XSS) Directory Traversal Authentication Bypass Information Disclosure Escalamiento de privilegios Manejo inseguro de sesiones Denegacin de servicio

Buenas prcticas para una codificacin segura

Validar siempre los datos de entrada antes de procesarlos Nunca confiar en que los datos recibidos sean correctos. Realizar validacin de datos en todas las capas Usar siempre criterio de White List en las validaciones Controlar tamao y tipo de datos Sanitizar los valores de entrada y salida Eliminar o escapear caracteres especiales Transformar los datos de entrada a un encoding establecido Reemplazar sentencias SQL dinmicas por Stored Procedures Evitar generar cdigo con valores ingresados por el usuario No mezclar datos con cdigo Capturar errores de capas inferiores y no mostrarlos al usuario

Testing funcional Vs. Testing de seguridad

Tcnicas de testing de seguridad Testing de seguridad funcional Testing Funcional (clsico) aplicado a las funcionalidades de seguridad de una aplicacin. Ej.: Testing de seguridad basado en Riesgo Tcnica que se desprende del Threat Modelling Se identifican todas las interfaces de la aplicacin Se generan casos de test sobre cada interfaz basado en STRIDE

Testing con un cliente / server falso Consiste en disear un cliente o server Ad Hoc que permita: Enviar peticiones /respuestas incorrectas o invlidas. Enviar peticiones/ respuestas fuera de orden. Insertar delays arbitrarios. Comportarse de manera diferente al cliente o servidor real. Test de stress Consiste en llevar la carga o funcionalidad de la aplicacin al lmite Generar una carga alta de peticiones/transacciones a la aplicacin. Mantener esta carga durante tiempos prolongados. Simular trfico en rfagas.

Test de mutacin de datos Se testea la aplicacin ingresando en sus interfaces datos mutados Revisin de cdigo Permite encontrar vulnerabilidades que son muy difciles de detectar con otros mtodos de testing de seguridad (ej.: BackDoors) Enfoque tradicional: Grupo de revisin Enfoque rpido: Revisin por pares

Seguridad en la implementacin (deployment) Si no se implementa la aplicacin de forma segura, se pueden echar por tierra los esfuerzos de las etapas anteriores. Hardening de software de base Servicios innecesarios Usuarios y contraseas default Configuracin de intrpretes Proceso de implementacin Separacin de ambientes Administracin de implementacin y mantenimiento Releases y Patches Firma de cdigo

CONCLUCIONComo se pudo ver hay diferentes formas de seguridad para un software y puede haber distintas formas de identificar su seguridad desde el comienzo en donde analizaremos cada parte como ser el diseo que debe contener en su codificacin como se debe codificar la forma del testeo en el cual se ve ms la seguridad con distintos mtodos y por deployment el cual se usa para desechar etapas anteriores las cuales no son seguras al momento de implementar el software.

En conclusin podemos ver que implementar seguridad en un software es muy necesario no solo porque sea trabajo del programador s que para que el cliente quede satisfecho con el trabajo.