INSTITUTO TECNOLOGICO SUPERIOR

DE FELIPE CARRILLO PUERTO

INGENIERIA DE SOFTWARE
MAESTRA: ING. CINTIA ISABEL ARCEO
FUENTES
UNIDAD 4
IDENTIFICACION DE METODOS DE
SEGURIDAD
INTEGRANTES:
TANYA D. SANCHEZ CHAN
NATANAEL I. TUN AGUILAR
JAVIER E. RODRIGUEZ ROJAS
J 1
GRUPO: A
Felipe carrillo puerto Q. Roo a 19 de Mayo del 2014

INTRODUCCION
En 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 SEGURIDAD
Actualmente 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 actual
Participacin 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
Deployment
Seguridad en el anlisis de requerimientos
Durante 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 celular
Tipos de datos que se almacenan o transfieren
Confidenciales / pblicos
Requerimiento de conformidad con normativas y marcos regulatorios
SOX, PCI-DSS, A 4609
Tipos de registro que el sistema debe generar
Acceso a recursos, uso de privilegios, etc.
Perfiles de usuario necesarios para la aplicacin
Administrador, revisor, editor, usuario bsico, etc.
Tipos de acceso a los datos por parte de cada perfil
Lectura, escritura, modificacin, agregado, borrado, etc.
Acciones sobre el sistema que puede hacer cada perfil
Cambiar la configuracin del sistema
Arrancar o detener servicios
Modos de autenticacin
Passwords, Tokens, Biomtricos
1 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


















CONCLUCION
Como 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.