Seguridad en aplicaciones
Email |
¿Desea imprimir?
Regístrese ahora
Las aplicaciones es una de las capas más importantes en el ambiente de la tecnología de la información pero desafortunadamente muy ignorada desde la perspectiva de la seguridad. Me refiero, sobre todo, a las aplicaciones transaccionales donde realmente se hace el proceso y que residen en el back-end de la infraestructura ( Legacy, Cliente Servidor, Distribuidas, Orientadas a Objetos, ERP´s, CRM´s etc.) y no a las que hoy día en el mercado se les pone mayor atención que son las basadas en Web.
Actualmente la referencia que se tiene con respecto a la seguridad en aplicaciones es el control de acceso y éste en definitiva es un punto importantísimo pero no suficiente. Cuando hablamos de una seguridad más robusta en las aplicaciones, éstas definitivamente deberían tener una seguridad nativa -como le llamo a los controles intrínsicos que tiene la aplicación. Un ejemplo sería un digito verificador ( 0056788349-3 ) contenido en un número de cuenta de cualquier aplicación bancaria, el cual permite que no haya error en la captura o lectura de la cuenta y garantice que es una cuenta existente.
Una de las reglas de dedo en la seguridad en aplicaciones es cuando se sabe que si en el ciclo de desarrollo de una aplicación no se analiza, diseña e implementan los controles. Es decir, actuar preventivamente y proactivamente muy difícilmente se hará en producción aunque hay honrosas excepciones y les comento esto porque hoy día estamos trabajando en un
proyecto de esta índole. Una de tantas razones es que en la mayoría de las organizaciones las aplicaciones literalmente están con alfileres y que por lo tanto es prácticamente imposible que dejaran que la gente de seguridad (que como se comento anteriormente difícilmente se involucra con las aplicaciones) pudiera echarles mano por la simple y sencilla razón que la operación y el servicio es primero.
Entonces la pregunta obligada es ¿qué pasa con todas nuestras aplicaciones que están en producción, tienen seguridad nativa o no? ¿Qué tan adecuada es? ¿Es suficiente? En mi experiencia les puedo comentar que las respuestas no serán nada positivas por la simple y sencilla razón de que la gente que desarrolla piensa en funcionalidad y no en seguridad. Es comprensible desde el punto de vista del desarrollador ya que por lo general no tienen un enfoque de seguridad y lo podemos comprobar muy sencillamente con una pregunta: ¿cuántos encargados de seguridad conocen que vengan de la parte de desarrollo?
Otro problema es que, debido al enfoque y alcance que hoy día se le da a la seguridad, se hacen análisis de vulnerabilidades a la red, a los sistemas operativos, por ahí a las bases de datos, a las aplicaciones Web (utilizando scanners) pero ¿qué pasaría si quisiéramos o nos pidieran saber que tan bien está la seguridad de mi aplicación de cajeros automáticos o cualquier otra aplicación? Dicho en otras palabras, “necesitamos que se haga un análisis
de vulnerabilidades a mi aplicación de cajeros automáticos por la razón que ustedes gusten y manden ¿qué haríamos? ¿Dónde conseguiríamos un scanner?
Imposible de encontrar. La respuesta menos adecuada: no se puede hacer.
O simplemente y sencillamente “no sé cómo hacerlo”.
Hoy día la sugerencia es que se evalúen los controles de la aplicación. El problema es que la mayoría de las veces no se tienen guías especificas de evaluación de controles para poder obtener las vulnerabilidades de la aplicación.
Sin embargo, a continuación describiré de manera general qué se puede hacer en estos casos donde impera la necesidad de no modificar el código para implementar seguridad en aplicaciones en producción, aunque reitero que no es la mejor forma ya que estamos actuando correctivamente.
Aún así, nos puede ayudar muchísimo para que esas aplicaciones trabajen con un nivel de riesgo aceptable. Ya hablamos anteriormente que lo mejor es hacerlo en el desarrollo y justo de este tema hablaremos en la segunda entrega de este articulo.
Todas las aplicaciones transaccionales (exceptuando las Web que trabajan de distinta forma por su funcionamiento y manera que se desarrollan) siguen unas etapas que les podemos llamar áreas de control o seguridad que se muestran en la figura 1.
Todo empieza con la necesidad de la seguridad en el origen de la transacción debido a que se tiene que asegurar que la información ingrese completa y exacta a la aplicación. La validez y exactitud de los datos en las aplicaciones están directamente relacionadas con la existencia y funcionamiento de los controles en el origen de los datos. Algunos de los objetivos que se deberán cumplir son la autorización del origen de una transacción, que no sea efectuada por usuarios no autorizados, y que la originación de una transacción no contenga errores.
La segunda etapa es la de entrada de datos o transacciones y aquí es vital tener controles para asegurar que la información introducida a la aplicación esté completa y exacta. Algunos objetivos a cubrir en esta etapa son que el proceso de entrada de los datos o transacciones se desarrolle con exactitud para todos los datos fuente recibidos, y que el proceso de entrada permita una óptima validación de los mismos.
Los controles en la comunicación de datos son necesarios para asegurar que estos no pierdan su integridad, confidencialidad y disponibilidad, si es que la aplicación requiere que haya comunicación de los datos desde el momento en que son introducidos hasta el momento que son recibidos.
Los objetivos a cumplir en esta etapa serían el asegurar controles adecuados para que los datos se transmitan de acuerdo a lo especificado por la aplicación.
La siguiente etapa es el proceso y se necesita tener controles adecuados para asegurar que la información sea procesada de forma exacta y completa y no se tengan incidentes de seguridad que violen la integridad, confidencialidad y disponibilidad de los datos esto hasta su salida. El proceso tiene muchas características ya que no es posible observar físicamente la secuencia de operaciones hechas por la computadora. Algunos de los objetivos a perseguir es tener controles que verifiquen que todas las transacciones sean introducidas para su proceso y aprovechar algunas de las bondades que ofrecen hoy día los sistemas operativos en cuestión de seguridad.
La siguiente etapa tiene que ver con el almacenamiento de los datos (en la mayoría de los casos en una base de datos) y es necesario tener controles para asegurar que los datos se mantengan sin haber perdido su integridad, confidencialidad y disponibilidad durante los periodos en que no están siendo utilizados por la aplicación. Algunos objetivos serían asegurar la protección de los datos por una pérdida, robo, o cambios no autorizados en la
base de datos, así como el tener procedimientos y herramientas para garantizarlarecuperación de los datos.
La última etapa es fundamental para poder cerrar el ciclo de la seguridad de las aplicaciones en producción y es de suma importancia el tener controles en la salida de los datos para que estos sean obtenidos y conocidos por usuarios autorizados. Imagínense que de alguna u otra manera tuviéramos una muy buena seguridad en las etapas anteriores, ¿de qué nos serviría si
en la salida de los datos estos llegaran a usuarios o personas no autorizadas y pudieran conocer o modificar dichos datos? Así es de importante tener controles para la salida de datos. Algunos objetivos serían asegurar que los datos procesados incluyan datos autorizados, completos y exactos, asegurar que el resultado sea conocido, utilizado o entregado a usuarios autorizados.
En realidad hablar de seguridad en las aplicaciones en general es complejo y mucho más si hablamos de aplicaciones en producción. El punto es dar a conocer que hay muchas cosas que se pueden hacer en relación a dichas aplicaciones y que no todo está perdido debido a su complejidad y entorno en el que se encuentran. Es importante dar a conocer que se tienen soluciones efectivas y probadas ya sea haciendo un análisis de vulnerabilidades, implementando seguridad a la aplicación o ambas.
En la segunda entrega veremos todo lo relacionado a la seguridad en el
desarrollo de las aplicaciones.
Continuará…
ORIGEN DE LA TRANSACCIÓN
ENTRADA DE DATOS (BATCH/ON
LINE/TIEMPO REAL)
TRANSMISION DE DATOS
PROCESO EN LA COMPUTADORA
SALIDA DE DATOS
ALMACENAMIENTO
Y RECUPERACIÓN DE DATOS
tabla 1
Adrián Palma es licenciado en Informática. Cuenta con más de 22 años de experiencia en Seguridad Informática y TI, actualmente es Director General
de Integridata , tiene las certificaciones CISSP,CISA,CISM,BSA, conferencista a nivel internacional y catedrático del diplomado de Seguridad en el ITESM,
Ex presidente de la ALAPSI Internacional y actualmente director de educación de la misma. educacion@alapsi.org
No hay artículos relacionados.
