Está en la página 1de 20

UNIDAD 4.

- SEGURIDAD EN INGENIERIA DE SOFTWARE


INTEGRANTES DEL EQUIPO: TOMAS FERNANDO CELAYA VARGAS DANIEL TORRES BENITEZ ELEAZAR JIMENEZ GARCIA

4. SEGURIDAD EN INGENIERIA DE SOFTWARE


4.1 SEGURIDAD DE SOFTWARE

Seguridad del Software: Aplica a la proteccin y el mal uso de los datos (modificacin, eliminacin, etc.) contra usuarios desautorizados para el acceso al sistema.

La seguridad es una preocupacin latente en cualquier empresa tanto desde el punto de vista estructural (proteccin de datos, etc.) como desde el punto de vista de producto final (diseo de sistemas seguros, proteccin de software, etc.). La seguridad es un elemento integral del sistema, no depende exclusivamente de uno u otro componente del sistema, sino que debe abordarse desde la globalidad del sistema. La seguridad y la confianza del sistema pasan a ser perspectivas transversales de la arquitectura del propio sistema software as como de los servicios proporcionados por el sistema.

Los sistemas de software generalmente estn expuestos a muchos errores y fallas adems de que si sus usuarios no toman la seguridad apropiada, puede llegar a contraer algn virus informtico el cual puede llegar a ser muy daino o no, dependiendo del tipo de virus, es por eso que siempre que trabajemos con algn sistema, sin importar si lo hacemos por trabajo o por entretenimiento, siempre tenemos que contar con algn tipo de seguridad en sistemas de software.

La seguridad del software aplica los principios de la seguridad de informacin al desarrollo de software. La seguridad de la informacin es definida como "la proteccin de sistemas de informacin contra el acceso no autorizado o la modificacin de informacin.

La falta de seguridad se origina a partir de dos problemas fundamentales. Los sistemas que son tericamente seguros pueden no ser seguros en la prctica. Adems, los sistemas son cada vez ms complejos; la complejidad proporciona ms oportunidades para los ataques. Es mucho ms fcil probar que un sistema es inseguro que demostrar que es seguro.

Actualmente no hay ninguna solucin nica para asegurar la ingeniera de software. Sin embargo, hay mtodos especficos que mejoran la probabilidad de que un sistema sea seguro

Buena Prctica

La seguridad requiere ms manejo y mitigacin de riesgo de lo que requiere la tecnologa. Cuando se desarrolla software uno primero debe determinar los riesgos de una aplicacin particular. Por ejemplo, el web site tpico de hoy puede estar sujeto de una variedad de riesgos, variando desde la desfiguracin, la negacin distribuida de servicio (DDoS, descrita en detalle ms adelante) y hasta transacciones con las partes equivocadas. Una vez que los riesgos son identificados, el identificar las medidas de seguridad apropiadas se vuelve manejable. En particular, cuando se definen los requerimientos, es importante considerar cmo ser utilizada la aplicacin, quin usar la aplicacin, etc.

Confiabilidad del Software

La confiabilidad del software significa que un programa particular debe seguir funcionando en presencia de errores. Los errores pueden estar relacionados al diseo, la implementacin, la programacin, o errores de uso. El software seguro debe de funcionar en la presencia de errores o fallas de las cuales un atacante intenta tomar ventaja. Aunque la mayora del software tiene errores, la mayora de los cuales nunca se observarn bajo circunstancias normales, un atacante buscar esas fallas en un intento de comprometer el sistema. Muchos de los problemas de seguridad que vemos hoy estn relacionados con cdigo defectuoso. Por ejemplo, el gusano de la Internet de Morris utiliz el sobreflujo en el programa fingerd de UNIX para ganar acceso como superusuario en las computadoras que ejecutaron el programa. Los ataques de sobreflujo de bfer han sido el tipo de ataque ms comn en las ltimos diez aos e involucran instrucciones que sobrescriben el programa que est en ejecucin mediante la saturacin del bfer de entrada.

4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias para su gestin de negocio. Como todo software, estas aplicaciones pueden contener fallas de seguridad y a diferencia del software comercial, no se dispone de actualizaciones o parches liberados en forma peridica por el fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de la organizacin que las desarrolla. Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que la aplicacin ya est desarrollada. Aqu muchas veces se encuentran errores que requieren el rediseo de parte de la aplicacin, lo cual implica un costo adicional en tiempo y esfuerzo.

Est comprobado que cunto ms temprano se encuentre una falla de seguridad en el ciclo de vida del desarrollo de software, ms rpida y econmica ser su mitigacin. Cul es el rumbo a seguir? Las buenas prcticas indican la conveniencia de incluir seguridad de la informacin desde el principio y a lo largo de todas las etapas del ciclo de vida de desarrollo, conocido como SDLC por ser las siglas en ingls de Software Development Life Cicle. Estas etapas pueden variar segn la modalidad de cada organizacin, pero a grandes rasgos son las siguientes: anlisis de requerimientos, diseo funcional y detallado, codificacin, testing/QA, implementacin/puesta en produccin.

Seguridad en el anlisis de requerimientos En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrn impacto en los aspectos de seguridad de la aplicacin. Algunos de ellos son: requerimientos de cumplir con normativas locales o internacionales (ej: PCI, SOX, A 4609, etc.), tipo de informacin que se transmitir o procesar (ej: Informacin pblica o confidencial, datos personales, datos financieros, contraseas, datos de pago electrnico, etc.) y requerimientos de registros de auditora (ej: Qu debe registrar la aplicacin en sus Logs).

Seguridad en el diseo Antes de comenzar a escribir lneas de cdigo, hay numerosos aspectos de seguridad que deben ser tenidos en cuenta durante el diseo de la aplicacin. Algunos de ellos son: diseo de autorizacin (ej: Definir los roles, permisos y privilegios de la aplicacin), diseo de autenticacin (aqu se debe disear el modo en el que los usuarios se van a autenticar, contemplando aspectos tales como los mecanismos o factores de autenticacin con contraseas, tokens, certificados, etc. posibilidades de integrar la autenticacin con servicios externos como LDAP, Radius o Active Directory y los mecanismos que tendr la aplicacin para evitar ataques de diccionario o de fuerza bruta (ej: bloqueo de cuentas, implementacin de captchas, etc.), diseo de los mensajes de error y advertencia, para evitar que los mismos brinden demasiada informacin y que sta sea utilizada por atacantes y diseo de los mecanismos de proteccin de datos (aqu se debe contemplar el modo en el que se proteger la informacin sensible en trnsito o almacenada; segn el caso, se puede definir la implementacin de encripcin, hashes o truncamiento de la informacin).

Una vez que se cuenta con el diseo detallado de la aplicacin, una prctica interesante es la de realizar sobre el mismo un anlisis de riesgo orientado a software. Existen tcnicas documentadas al respecto, tales como Threat Modeling. Estas tcnicas permiten definir un marco para identificar debilidades de seguridad en el software, antes de la etapa de codificacin. Como valor agregado, del anlisis de riesgo orientado a software se pueden obtener casos de prueba para ser utilizados en la etapa de Testing/QA.

Seguridad en la codificacin Una vez concluido el diseo, le toca a los desarrolladores el turno de codificar los distintos componentes de la aplicacin. Es en este punto en donde suelen incorporarse, por error u omisin, distintos tipos de vulnerabilidades. Estas vulnerabilidades podramos dividirlas en dos grandes grupos a saber: vulnerabilidades clsicas y vulnerabilidades funcionales. Las primeras son bien conocidas y categorizadas. Ejemplo de estas vulnerabilidades son las presentes en el OWASP Top 10 (Vulnerabilidades de inyeccin, Cross Site Scripting, errores en manejo de sesiones, etc.) como as tambin otras vulnerabilidades no ligadas directamente con las aplicaciones WEB, como desbordamiento de buffer, denegacin de servicio, etc. Los Frameworks de desarrollo de aplicaciones son una buena ayuda en este punto, ya que ofician de intermediario entre el programador y el cdigo, y permiten prevenir la mayora de las vulnerabilidades conocidas. Ejemplos de estos frameworks son Struts, Ruby on Rails y Zope.

Vulnerabilidades funcionales son aquellas ligadas especficamente a la funcionalidad de negocio que posee la aplicacin, por lo que no estn previamente categorizadas. Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los siguientes: una aplicacin de banca electrnica que permite realizar transferencias con valores negativos, un sistema de subastas que permite ver los valores de otros oferentes, un sistema de venta de entradas para espectculos que no impone lmites adecuados a la cantidad de reservas que un usuario puede hacer. En la etapa de codificacin, una de las reglas de oro es verificar todos los valores de entrada y de salida. Esto es, asumir siempre que el valor pudo haber sido manipulado o ingresado maliciosamente antes de ser procesado.

Testing / QA de seguridad Tradicionalmente, la labor del equipo de Testing/QA fue la de encontrar y reportar errores funcionales de la aplicacin. Para esto, se desarrollan casos de test basados en la funcionalidad esperada. A esto denominamos testing funcional y bsicamente consiste en validar que la aplicacin haga lo que se esperaba que hiciera. Sucede que habitualmente hay un desfasaje entre el diseo original de la aplicacin (lo que se espera que haga) y la implementacin real (lo que realmente hace). Aqu surgen 3 reas bien definidas: lo que fue definido y la aplicacin hace, lo que fue definido y la aplicacin no hace (errores funcionales) y lo que no fue definido pero la aplicacin hace.

Es en este ltimo grupo, en donde habitualmente estn las vulnerabilidades, y el testing funcional clsico no es capaz de encontrarlas. Por este motivo se necesitan nuevas tcnicas para explorar lo desconocido. El testing de seguridad se basa principalmente en probar la aplicacin con escenarios no planificados, incluyendo valores mutados, fuera de rango, de tipo incorrecto o malformados, acciones fuera de orden, etc. Existen herramientas automticas que pueden ayudar al analista de QA en la bsqueda de errores. Las mismas son tiles por su velocidad y capacidad de automatizacin, pero pueden causar falsos positivos, y por lo general no son buenas detectando vulnerabilidades funcionales. Es por esto que los mejores resultados resultan de la combinacin de tcnicas automticas y manuales.

Implementacin / Puesta en produccin Una mala configuracin al momento de implementar la aplicacin podra echar por tierra toda la seguridad de las capas anteriores. Tanto la aplicacin como el software de base deben configurarse de manera segura al momento de poner el software en produccin. En este punto se deben contemplar tareas tales como: cambio de usuarios y contraseas iniciales o por defecto, borrado de datos de prueba y cambio de permisos de acceso. Es tambin importante mantener una correcta separacin de los ambientes de desarrollo, testing y produccin y procedimientos de traspaso seguro de uno a otro de estos ambientes.

La seguridad en las aplicaciones de software debe abordarse desde el primer da del proceso de desarrollo y a lo largo de todas las etapas del mismo. En cada una de estas etapas, se pueden realizar diversas actividades que en su conjunto ayudarn a aumentar la seguridad de la aplicacin de software que se est desarrollando. Es importante que en cada organizacin, el sector de seguridad de la informacin sea invitado a participar a lo largo de todo el proceso de desarrollo como supervisor de las tareas y verificaciones de seguridad. La integracin de seguridad a lo largo del SDLC ayuda a reducir las fallas de seguridad como as tambin los costos de la aplicacin, tanto tangibles (tiempo / dinero) como intangibles (imagen de la organizacin)