La
mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias para su
gestión 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 periódica por el fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de la organización que las desarrolla.
Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que la aplicación ya está desarrollada. Aquí muchas veces se encuentran errores que requieren el rediseño de parte de la aplicación, lo cual implica un costo adicional en tiempo y esfuerzo.
Seguridad en el análisis de requerimientos
Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que la aplicación ya está desarrollada. Aquí muchas veces se encuentran errores que requieren el rediseño de parte de la aplicación, lo cual implica un costo adicional en tiempo y esfuerzo.
Seguridad en el análisis de requerimientos
En
esta etapa, se deben identificar aquellos requerimientos funcionales que
tendrán impacto en los aspectos de
seguridad de la aplicación. Algunos de
ellos son: requerimientos de compliance con normativas locales o
internacionales (ej: PCI, SOX, “A” 4609, etc.), tipo de información que se
transmitirá o procesará (ej: Información pública o confidencial, datos
personales, datos financieros, contraseñas, datos de pago electrónico, etc.) y
requerimientos de registros de auditoría (ej: Qué debe registrar la aplicación
en sus Logs).
Seguridad en el diseño
Antes
de comenzar a escribir líneas de código, hay numerosos aspectos de seguridad que deben ser tenidos
en cuenta durante el diseño de la aplicación.
Algunos
de ellos son: Diseño de autorización (ej:
Definir los roles, permisos y privilegios de la aplicación), diseño de
autenticación (aquí se debe diseñar el modo en el que los usuarios se van a
autenticar, contemplando aspectos tales como los mecanismos o factores de
autenticación con contraseñas, tokens, certifcados, etc. posibilidades de
integrar la autenticación con servicios externos como LDAP, Radius o Active
Directory y los mecanismos que tendrá la aplicación para evitar ataques de
diccionario o de fuerza bruta (ej: bloqueo de cuentas, implementación de
“captchas”, etc.), diseño de los mensajes de error y advertencia, para evitar
que los mismos brinden demasiada información y que ésta sea utilizada por
atacantes y diseño de los mecanismos de protección de datos (aquí se debe
contemplar el modo en el que se protegerá la información sensible en tránsito o
almacenada; según el caso, se puede definir la implementación de encriptación,
hashes o truncamiento de la información).
Seguridad en la codificación
Seguridad en la codificación
Una
vez concluido el diseño, le toca a los desarrolladores el turno de codificar
los distintos componentes de la aplicación. Es en este punto en donde suelen
incorporarse, por error u omisión, distintos tipos de vulnerabilidades. Estas
vulnerabilidades podríamos dividirlas en dos grandes grupos a saber:
vulnerabilidades clásicas y vulnerabilidades funcionales. Las primeras son bien
conocidas y categorizadas.
En la
etapa de codificación, 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.
No hay comentarios:
Publicar un comentario