Consejos Para El “Desarrollo Seguro De Aplicaciones”

• 1. Ningún componente es confiable hasta demostrar lo contrario

• Un error común en el desarrollo de software es englobar funcionalidad sensible en un ambiente de ejecución sobre el cual no tenemos ningún tipo de control. No es debido suponer que los componentes del sistema son confiables hasta que esto pueda ser demostrado. Por ejemplo, si tenemos un entorno de cliente-servidor, se deben tomar las precauciones contra posibles clientes adulterados desplegando mecanismos de verificación. Debemos pensar que éste se encuentra en el dominio del usuario, quien no siempre tendrá las mejores intenciones.

• 2. Delinear mecanismos de autenticación difíciles de eludir

• La autenticación es el proceso que nos permite acreditar la identidad del usuario y asignarle un identificador único. El desarrollo de métodos autenticación centralizados que cubran cada posible camino de ingreso es uno de los pilares en la construcción de aplicaciones seguras. Si se trata de páginas web, debemos pensar qué sitios requerirán el manejo de usuarios autenticados, y cuidar que terceros indebidos no se entrometan en el sistema desde URLs no protegidas. La utilización de múltiples factores de autenticación nos permitirá reforzar el sistema comprobando no sólo lo que el usuario sabe sino, por ejemplo, también lo que éste posee.

• 3. Autorizar, además de autenticar

• La autorización es el proceso que designa si un usuario autenticado puede o no realizar una acción que cambia el estado del sistema. Los procesos de autorización sobre usuarios autenticados deben ser pensados desde el diseño y previenen contra sesiones que han caído en las manos equívocas.

• 4. Separar datos de instrucciones de control

• Este punto es clave cuando se trabaja con código capaz de modificarse a sí mismo, o lenguajes que compilan dicho código en tiempo de ejecución -tales como JavaScript-, donde las mismas instrucciones se reciben como datos. Entonces, se vuelve de suma importancia sanear las entradas que recibe el sistema para evitar que atacantes puedan manipular el flujo de ejecución ingresando datos maliciosos.

• 5. Validar todos los datos explícitamente

• Las entradas al sistema deben evaluarse con una filosofía de lista blanca por sobre lista negra: determinar qué se permitirá, y denegar todo aquello que no se corresponda. Debemos pensar que un atacante interpreta los datos como posibles lenguajes de programación, con la intención de manipular el estado del sistema. Por esto, se torna necesario inspeccionar estos datos de entrada, generando los procedimientos automáticos para llevarlos a formas canónicas bien conocidas.

• 6. Utilizar criptografía correctamente

• La comprensión de las nociones criptográficas que aplican al sistema en desarrollo es necesaria para poder entender qué elementos y qué característica de los mismos se busca proteger, contra qué formas de ataque, y consecuentemente, cuál es la mejor manera de lograr este objetivo. La creación de propias soluciones criptográficas, como siempre, es una decisión riesgosa que puede derivar en un sistema defectuoso, y por tanto es rotundamente desaconsejada. En cambio, se debe acudir al correcto asesoramiento para encontrar las librerías y herramientas que nos permitan aumentar el costo de ataque para el cibercriminal.

• 7. Identificar datos sensibles y cómo se los debería gestionar

• Resulta complicado proteger nuestra información si no tenemos en claro qué es lo que realmente buscamos cuidar. La definición de los datos cuya protección resulta fundamental para el funcionamiento del sistema es crítica, puesto que a partir de ella podremos comenzar a esbozar los procesos para el diseño de la seguridad desde el mismo comienzo del ciclo de desarrollo, y no como un añadido en las etapas de implementación o despliegue.

• 8. Considerar siempre a los usuarios del sistema

• Un sistema técnicamente perfecto que no cubre las necesidades de los usuarios es un sistema inservible. La seguridad utilizable debe ser una de las metas a alcanzar cuando se plantean los objetivos de seguridad para el sistema. Por un lado, no es prudente transferir al usuario cuestiones de seguridad que pueden resolver los mismos desarrolladores, a fin de evitar la fatiga. 9. La integración de componentes cambia la superficie de ataque

• Las aplicaciones actuales constituyen sistemas complejos con muchos componentes interactuando de manera simultánea. Cada vez que se realiza un cambio en el sistema, el panorama de seguridad cambia y debe ser revaluado. Esta rexaminación es el resultado de la coordinación entre las áreas y proyectos.

• 10. Considerar cambios futuros en objetos y actores

• Desde el diseño, debemos considerar que las propiedades del sistema y sus usuarios cambian constantemente. Algunos factores a considerar son el crecimiento de la población de usuarios, cómo las migraciones afectan al sistema, o cómo afectarán vulnerabilidades futuras sobre componentes que se han desplegado a gran escala.

• En resumen…

• Las organizaciones actuales han comenzado a comprender que la identificación y remediación temprana de problemas posee un costo inversamente proporcional al tiempo que el error permanece en el sistema.
•