Desarrollo de Software Seguro

Carlos Corts Bazn, Rubn Vzquez Medina, Rogelio Reyes Reyes

Seccin de Estudios de Posgrado e Investigacin, Instituto Politcnico Nacional, ESIME Culhuacan Av. Santa Ana No. 1000, Col. San Francisco Culhuacan, CP. 04430, Mxico, D.F. Tel. (55) 5729-6000 Ext. 73020 Fax (55) 5656-2058 E-mail: ccortesb@ipn.mx, ruvazquez@ipn.mx, rreyesre@ipn.mx
AbstractEn ste artculo se explican una serie de buenas prcticas que se deben considerar al momento de desarrollar sistemas de cmputo. stas buenas prcticas no solo abarcan los criterios necesarios para asegurar la calidad en el software, adems, se toma en consideracin aspectos relevantes para proveer de seguridad al software de tal manera que el producto final sea de calidad y seguro. Las buenas prcticas consideradas para ste artculo son basadas en normas de carcter internacional utilizadas por diferentes organismo de renombre.

El propsito de ste artculo es dar algunas recomendaciones en la etapa de desarrollo, por lo que no se detallar en el ciclo de vida del software. II. CONSIDERACIONES INICIALES

Al inicio del CVS es inherente tomar en cuenta aspectos relevantes enfocados a la seguridad, algunos de esos aspectos son: Disear y mantener manuales de procedimientos que indiquen los procesos generales en el CVS. Realizar un anlisis de riesgos que refleje las posibles vulnerabilidades que puedan ser explotadas. Identificar y categorizar la informacin segn su riesgo, en especial la informacin que va a ser almacenada en medios fsicos y la informacin de carcter confidencial. Identificar requerimientos de privacidad que permitan que la informacin no sea revelada a personas o entidades no autorizadas. Los requerimientos del sistema deben ser considerados en base a los conceptos de confidencialidad, integridad y disponibilidad. Lo anterior, no solo enfocados a la informacin que maneja el sistema, sino tambin de la empresa que lo utiliza. III. CDIGO SEGURO

I.

INTRODUCCIN

Durante el proceso del ciclo de vida del software, normalmente se toman en consideracin algunos parmetros, mtricas y pruebas para asegurar la calidad del producto final, todas las pruebas y validaciones son enfocadas a garantizar que el software cumpla con los requerimientos funcionales, es decir, que el software haga lo que dice hacer. Al considerar que la calidad es lo primordial durante ste proceso, se deja de lado la seguridad de ste y en el mejor de los casos, proveer de seguridad al software es relegado al final del proceso. La seguridad debe de ir de la mano de la calidad a lo largo de todo el proceso del ciclo de vida del software, lo cual implica que el software debe ser concebido de calidad y seguro. En todas las etapas del proceso debe estar inmersa la seguridad tanto en el anlisis, diseo, desarrollo, pruebas y mantenimiento (ver figura 1).

Anlisis Diseo

Hay que tomar en cuenta que la seguridad de un sistema depende de las caractersticas del mismo. A continuacin de describen algunas buenas prcticas al momento de escribir el cdigo de un sistema computacional:
Desarrollo Pruebas Mantenimiento

A. Cdigo limpio y ordenado Es importante escribir cdigo que cuente con una estructura adecuada, sin lneas de cdigo repetidas y agruparlas en mtodos o funciones. Deben utilizarse adecuadamente los espacios, sangras y saltos de lnea para organizar el cdigo. El uso de comentarios a lo largo de todo el cdigo tambin es una buen prctica, adicionalmente se debe utilizar un estndar para definir el nombre de variables, mtodos, funciones, clases y dems elementos. B. Eliminar variables y constantes en desuso Durante el proceso de desarrollo, es comn definir variables y constantes que a posteriori dejan de usarse ya que

Figura 1. Ciclo de vida del software.

solo se usan para realizar pruebas o con algn otro fin, lo anterior no solo provoca un uso de memoria excesivo, adems, puede provocar huecos de seguridad que pueden ser explotados por software malicioso. De tal forma que el uso de variables y contantes debe ser controlado y la declaracin de estos elementos, debe ser definida en manuales de procedimientos, indicando el lugar especfico, dentro del cdigo, donde se deben declarar. C. Eliminar mtodos o funciones en desuso De igual manera que el punto anterior, existen mtodos o funciones que en algn momento quedan en desuso, lo que tambin representa problemas en el desempeo del producto final, por lo que se tiene que evitar que esto suceda. D. Minimizar el uso de buffer Se tiene que prestar atencin al utilizar funciones que hagan uso de buffer, ya que el mal uso de este puede generar un desbordamiento de memoria, sumado a ello, el hecho de que es el elemento ms vulnerado en el caso de los exploits y otros tipos malware. Se recomienda definir tamaos pequeos al usar buffers. E. Validar las entradas y salidas al sistema La mayora de las vulnerabilidades comunes en el software radican en la falta de validaciones de los datos que entran y salen de ste, lo que puede generar en problemas como la denegacin de servicio, inyeccin de datos o cdigo por accidente o de forma malintencionada. F. Uso correcto de nmeros enteros El mal uso de los enteros puede generar problemas de seguridad, entre los ms comunes estn el desbordamiento de buffers, ciclos infinitos y otros. Algunas recomendaciones: Usar enteros sin signo. De esta forma se obtiene un mayor rango de nmeros para hacer uso al momento de determinar el tamao de bferes y arreglos. Usar enteros sin signo en bucles. Minimiza la posibilidad de generar ciclos infinitos. Verificar que el tamao de la salida (en bytes) no sea ms grande que el tamao asignado para la aplicacin.

H. Evitar concatenar cadenas en sentencias SQL Al momento de construir sentencias SQL es comn cometer el error de concatenar los datos con constantes definidas para las operaciones en la base de datos por ejemplo: INSERT INTO EMPLOYEES + values; Para evitar la inyeccin SQL muchos desarrolladores usan tcnicas errneas como: Eso de procedimientos almacenados. Cifrado de la base de datos. Uso de SSL. Duplicacin o eliminacin de comillas dobles.

A pesar de que algunas de stas tcnicas pueden impedir un ataque, la nica forma de asegurar una sentencia SQL es construyndola adecuadamente desde el inicio. I. No usar mtodos de cifrado dbiles o vulnerados Existen algoritmos o tcnicas de cifrado considerados dbiles, debido a que se han visto vulnerados mediante diferentes tcnicas de ataques. Se recomienda el uso de algoritmos de cifrado que no se consideren dbiles. Algunos de ellos de muestran en la siguiente lista: MD4 MD5 SHA1 Algoritmos simtricos con llaves menores a 128 bits. RC4 y ARC, debido a la dificultar de trabajar con el flujo. Cifrados de bloques con ECB. Cualquier algoritmo de cifrado que no ha sido evaluado.

J.

Controles de acceso y monitoreo De acuerdo a la naturaleza de la aplicacin en cuestin, es inherente implementar controles de acceso que permitan otorgar ciertos privilegios dependiendo del tipo de usuario. As mismo se debe dar seguimiento a las actividades que cada usuario realice, de tal forma que alimente una bitcora y tener el control de las actividades del usuario. Algunos controles de acceso son: Clave de usuario y contrasea. Identificacin biomtrica: huella digital, iris del ojo, etc. Llave fsica de identificacin: USB, tarjeta, chip, etc. Otros.

G. Usar recursos en formatos estandarizados Se debe realizar una estandarizacin o normalizacin de los recursos que se utilizaran en la aplicacin. Esto permite mantener la seguridad al momento de acceder o ejecutar archivos desde la aplicacin en una ruta determinada. Si el archivo a acceder no se encuentra en la ruta preestablecida, ste no se ejecuta.

K. Definir roles y privilegios Para cada usuario del sistema se deben definir roles y los privilegios asignados a cada rol. Es decir, se deben tener tipos de usuarios bien definidos (roles) y las tareas a las que tienen acceso (privilegios). L. Interfaz entre mtodos o funciones Se debe definir la forma en que se van a comunicar los diferentes mtodos o funciones de la aplicacin. En este caso es recomendable realizar esta comunicacin mediante el uso de objetos de transporte o estructuras de datos, es decir, un objeto o estructura que contenga todos los datos que se requieren enviar o recibir, y no enviar datos por separado provocando errores y huecos de seguridad. M. Cifrado de contraseas En el caso de usar nombres de usuario y contraseas como mtodo de acceso a la aplicacin, es recomendable hacer uso de un algoritmo de cifrado que proteja esta informacin. N. Procesos en el servidor Cuando se trate de aplicaciones soportadas en internet, todos los procesos a realizar deben ser realizados en el servidor, porque se puede revelar informacin o procesos relevantes que no deban ser expuestos. La capa de presentacin, solo se debe encargar del envo y recepcin de datos, validaciones de campos y ser intermediario entre el usuario y la aplicacin WEB. Nunca se debe incluir informacin sensible en archivos, asp, php, html, etc. O. Usar mtodo post en formularios web Como medida adicional al momento de enviar informacin mediante formularios WEB, se recomienda el uso de mtodo post al momento del envo, lo anterior es para no mostrar los datos en la barra de navegacin del navegador WEB. P. Ofuscacin de cdigo Hoy en da existen aplicaciones capaces de descubrir el cdigo fuente de otra a partir del ejecutable, a ste proceso se le conoce como descompilador e independientemente del lenguaje de programacin utilizado, es posible conocer cada lnea de cdigo que conforma cualquier aplicacin. Una tcnica para evitar esto es realizar un ofuscamiento de cdigo, el cual consiste en cambiar cada lnea de cdigo, de tal forma que sea inteligible y difcil de leer. Q. Usar kits de desarrollo actualizados Uno de los aspectos menos atendidos pero de relevancia, es el uso de kits de desarrollo formales y reconocidos, de empresas con renombre que provean de actualizaciones

constantes y suporte tcnico. As mismo el IDE utilizado, debe cumplir con estas caractersticas. IV. REVISIN DE NORMAS O LEYES LOCALES DE CARCTER
OBLIGATORIO

Sin importar las medidas tomadas al momento del realizar el ciclo de vida del software, siempre se deben considerar las normas o leyes locales de carcter obligatorio con la intencin de estar alineados a las leyes y no ser acreedores a canciones o a exponer a las aplicaciones a riesgos concretos. En ste rubro se consideran los datos personales que la aplicacin usa para sus procesos y almacenamiento. Para un correcto uso de los datos usados en el sistema se debe de considerar los aspectos legales y ticos, ya que estos datos sern almacenados o transmitidos. Los aspectos a considerar son: Revisar las leyes y polticas locales. Identificar el tamao y caractersticas de la base de datos. Definir un mtodo de cifrado de la base de datos. Uso y administracin adecuados de cookies. V. PRUEBAS DE SEGURIDAD

Al finalizar el proceso es pertinente realizar las pruebas adecuadas, no solo para garantizar la calidad de la aplicacin, adicionalmente, se deben realizar exhaustivas pruebas de seguridad que proporciones certidumbre en ste rubro. Algunas de las normas que se pueden usar para ste fin son: OSSTMM. The Open Source Security Testing Methodology Manual. Es un manual de metodologas para pruebas y anlisis de seguridad realizado siguiendo la metodologa OML (Open Methodology License) siendo el manual en s publicado bajo licencia Creative Commons 3.0, lo cual permite el libre uso y distribucin del mismo. ISO/IEC 24759. Test requirements for cryptographic modules. Es un estndar para la evaluacin de requerimientos de seguridad para mdulos de cifrado. NIST 800-133. Recommendation for Cryptographic Key Generation. Son recomendaciones que se deben considerar al momento de generar llaves de cifrado. Gua de pruebas OWASP. Gua de pruebas para aplicaciones WEB. SP 800-115. Technical Guide to Information Security Testing. Pruebas de seguridad para la informacin. En general toda la serie 800 del NIST. Otras.

VI.

CONCLUSIONES

Al implementar algunas buenas prcticas de seguridad al momento de realizar el ciclo de vida del software, no solo garantizamos la calidad de ste, adems minimizamos vulnerabilidades y se proporciona un mnimo de seguridad requerida, se protege la informacin del usuario dando confianza de que dicha informacin difcilmente ser vulnerada. REFERENCIAS
[1] [2] [3] Somerville, Ian. (2005). Ingeniera de Software, Sptima edicin. Pearson Addison Wesley. Len Serrano, Gonzalo. (2006). Ingeniera de Sistemas de Software, Cuarta edicin. Isdefe. Stallings, William. Cryptografy and Network Security: Principles and practice. Fifth Edition. United States of America: Prentice Hall, 2006. 719p. ISBN: 0-13-609704-9 Rami Aguirre, Jorge. Libro Electrnico De Seguridad Informtica y Criptografa. 6 edicin. Madrid Espaa: Universidad Politcnica de Madrid, 2006, 1106 p. ISBN: 84-86451-69-8. International Systems Security Engineering Association (ISSEA). Systems Security Engineering Capability Maturity Model (SSE-CMM). Version 3.0, 2003 National Institute of Standards and Technology (NIST). Security Considerations in the System Development Life Cycle. SP 800-64, 2008. Fundamental Practices for Secure Software Development 2nd edition, SAFECode, February 8, 2011.

[4]

[5]

[6] [7]