Blog - Metodologías y Legislación

Usar puntuación: / 0
MaloBueno 

La norma ISO/IEC 17799 tiene un dominio de control exclusivo sobre actividades del desarrollo de software, el cual nos permite conceptualizar en nuestras mentes un mapa de requerimientos de seguridad, previos a cualquier inicio de un proyecto.

En el desarrollo de cada uno de nuestros proyectos, los activos de información más importantes se relacionan con el software creado en todas sus variantes.

Con esto concluiremos la ISO/IEC 17799.

...

Desarrollo y Mantenimiento de Sistemas

Requisitos de seguridad de los sistemas (*)

Los requerimientos de seguridad de los sistemas deben ser garantizados cualquiera fuera el alcance que posea nuestra aplicación: para clientes externos, para clientes internos o aplicaciones complementarias. El conjunto de requerimientos funcionales sobre seguridad dependerá del análisis característico de la organización que utilice el sistema, los activos de información que serán protegidos y de la identificación de los riesgos que debamos mitigar. Las políticas de seguridad de la organización, en este punto juegan un papel de importancia dado que determinan el marco natural sobre la cual se basarán los desarrollos de seguridad. Como resultado del análisis indicaremos una lista de controles y monitoreos, que debemos reflejar dentro del sistema desarrollado, los cuales serán las herramientas del área de seguridad y/o de las áreas de auditoria. Si poseemos un módulo de seguridad completo, significará un diferencial a la hora de compararnos con otros sistemas. El costo de incorporar los requerimientos de seguridad en el primer paso de diseño es considerablemente menor, que al hacerlo luego de la fase de implementación, por tal motivo, considerar los aspectos de seguridad en su fase inicial implica no solo el valor agregado en el producto, sino también una visión integra a un costo desde el inicio bajo.

Costos de la aplicación de la seguridad según la fase del proyecto

Seguridad en los sistemas de aplicaciones (*)

Las aplicaciones son utilizadas para administrar y almacenar información particular de cada una de las áreas de la organización. Esta información debe ser integra, confidencial y debe estar disponible frente a las necesidades de cada una de las personas que la requieran. Por eso uno de los objetivos en el desarrollo de programas es impedir pérdidas, modificaciones o uso indebido de datos de los usuarios con nuestros sistemas aplicativos. Para ello debemos incorporar controles, validaciones y registros de actividades que nos permita asegurar y proteger la integridad de la información.

Como diagrama clásico utilizaremos el esquema de Entrada – Proceso – Salida, donde indicaremos conceptos de validaciones y controles que debemos analizar en cualquier desarrollo de sistemas.

Esquema de Entrada – Proceso – Salida

El ingreso de datos en cualquier aplicativo, lo debemos validar y controlar, permitiendo incorporar información consistente a nuestro sistema. Estos datos de entrada pueden ser ingresados a través de las pantallas de los usuarios o capturados por interfaces automáticas o semiautomáticas desde otros sistemas. Para ello podemos incorporar validaciones a fin de mitigar los conceptos que a continuación detallamos:

-    Datos incompletos o faltantes: por ejemplo la incorporación de datos obligatorios en el ingreso de una ficha de un cliente.
-    Fuera de rango: por ejemplo cuando debemos ingresar una calificación de 0 a 10 y alguien ingresa un 12. Particularmente en estos casos se utilizan de acuerdo al lenguaje utilizado, los llamados combos o drop down, donde se despliega la lista de valores posibles.
-    Caracteres inválidos: por ejemplo, el uso de algunos signos particulares cuando ingresamos una contraseña.
-    Incongruencias transitivas entre datos ingresados: en este caso la validación se relaciona por efecto transitivo entre dos o mas datos ingresados, por ejemplo, si validamos que la fecha de nacimiento debe ser menor que la fecha de finalización de la escuela primaria y esta menor que la finalización de la secundaria.
-    Dígitos verificadores, por ejemplo, el código de control en los números de CUIT (documentos personales) donde el último dígito se calcula aplicando una fórmula matemática sobre los otros primeros números.
-    Momento de la validación. El proceso de validación lo podemos realizar cuando ingresamos el dato, o bien, al final cuando ejecutamos un evento específico.

Durante el procesamiento interno de los datos, debemos incorporar controles que nos permitan lograr el seguimiento de las estructura de datos y proteger la integridad de la información. Como base conceptual podemos mencionar algunos de los controles y validaciones conocidos:

-    Registro de actividades en bases de seguimiento, sobre las actividades que realice el usuario y la secuencia que el proceso determine.
-    Conjunto de marcas o banderas, de forma que determinen un circuito secuencial en los pasos de una transacción. Por ejemplo, para que una transacción pueda ser trasmitida debe estar previamente ingresada, controlada y verificada, siendo estas tres, marcas disponibles en el registro asociado.
-    Marcas de vuelta atrás. Generalmente aplicado en el uso de una sesión de una base de datos, en donde un ingreso de usuario determina una instancia inicial y si esta operación es rechazada entonces se produce una vuelta atrás volviendo al conjunto inicial de datos.
-    Controles entre registros individuales y datos consolidados. Por ejemplo, el conjunto de movimientos operativos de un sistema contable contra el saldo propio del día que estamos controlando.
-    Controles inicio y finalización de procesos, característicos en el conjunto de procesos que se ejecutan durante el inicio y cierre de día de un aplicativo, donde se almacena información sobre fecha/hora inicio y finalización, estado de finalización del proceso, cantidad de registros procesados, suma de saldos procesada, cantidad de registros con error, etc.
-    Análisis de consistencia o autenticación de información procesada, asociado con comunicaciones de información entre procesos, donde parte de los datos enviados permiten controlar la trasmisión del mismo.
-    Encriptación de datos, utilizada para proteger la confidencialidad, autenticidad e integridad de la información almacenada en las bases de datos, archivos o trasmitidas entre los procesos de aplicaciones.
-    Controles de integridad de la información almacenada en base de datos y archivos.

El último paso de control es la salida de los datos procesados. Si consideramos que la entrada se encuentra correctamente validada y el procesamiento interno fue el correcto, naturalmente la salida deberá ser correcta. Igualmente existen algunos controles o conceptos adicionales que podemos emplear en las validaciones de salida:

-    Aplicación de las validaciones símiles a las de la entrada de datos. Por ejemplo, si mostramos la ficha de un cliente podemos aplicar las validaciones utilizadas anteriormente al momento del ingreso, a fin de controlar la calidad de los datos almacenados.
-    Conciliación de la salida de información versus otra fuente de información, o un procesamiento diferente de los datos de entrada.
-    Control de totales de cantidades, suma de saldos u otro tipo de numerales que nos permitan determinar si la información de salida es producto de los datos provenientes de la entrada.
-    En muchos casos, la implementación lógica del sentido común frente a los datos de salida, es importante como control. En la medida que el lenguaje nos permita trasladar el sentido común a las validaciones de salida, más rica será la información suministrada.

Seguridad de los archivos y documentos del sistema (*)

Los programas y con ello los elementos que los componen (objetos, componentes, estructuras de base de datos, librerías, etc.), conforman el principal activo de información de los equipos de desarrollo y mantenimiento de sistemas. Adicionalmente incorporamos a estos activos, toda la documentación de respaldo del análisis funcional y de diseño que nos permitió crear el aplicativo en cuestión. Por ello debemos garantizar la protección de los proyectos informáticos y sus actividades complementarias, de manera de restringir a las personas no vinculadas en este proceso y a controlar la utilización de los activos de información mencionados.

Cuando analizamos las actividades operativas, mencionamos la separación de ambientes determinados entre desarrollo, prueba y producción. En esta situación existía un responsable por el pasaje de las versiones de los programas entre cada uno de los ambientes. El foco que ahora queremos darle, es sobre la protección del conjunto de programas que estamos desarrollando antes de realizar el pasaje a la instancia siguiente. En el momento del desarrollo de un proyecto, establecemos conjuntos de requerimientos determinados por actividades de programación en común. A cada uno de los equipos de desarrollo les entregamos dichos requerimientos, junto con los programas iniciales para realizar el mantenimiento o bien para crear una nueva versión sobre estos. Las actualizaciones o mejoras son desarrolladas por los programadores y luego son integradas por una persona, quien será la responsable por controlar que versión fue entregada, que número de versión tendrá la actualizada y que conjunto de programas todavía tienen en su poder los programadores. El conjunto de estos códigos fuentes son responsabilidad de la metodología de desarrollo implementada y los controles de integridad y consolidación complementarios. Esta metodología nos permitirá mantener un orden del progreso del proyecto y un registro de auditoria de las actividades desarrolladas. Los procesos de compilación, generación de códigos objetos, archivos ejecutables, son considerados otras instancias de esta metodología y deberán ser controlados y monitoreados de la misma manera. Particularmente los archivos ejecutables serán el último paso, que luego de pasado el control de calidad por intermedio de las pruebas unitarias del sistema, determinará un paquete o librería generando una versión del entregable. El historial de las versiones anteriores las debemos mantener de acuerdo a la política de resguardo acordada, acompañada con la documentación técnica que nos permita determinar que instancia del desarrollo aplica a cada una de las versiones resguardadas.

El acceso de terceros (clientes y proveedores), al conjunto de activos deberá ser restringido de acuerdo a la necesidad de acciones y los compromisos contractuales establecidos entre ambas partes. Este punto lo desarrollamos anteriormente cuando cumplimiento legal, contrataciones externas y accesos de terceros.

Cuando elaboramos el proceso de control de calidad de los aplicativos, necesariamente tenemos que definir casos de pruebas que permitan encontrar falencias en el desarrollo. Una buena prueba de calidad no es aquella que no genere errores, sino todo lo contrario. Para ello es necesario armar casos de pruebas reales, donde muchas veces se utilizan copias de los ambientes de producción que determinan muy acertadamente las distintas combinaciones requeridas para las pruebas de sistemas. En tal caso medidas de confidencialidad deberán ser tomadas para preservar la información utilizada y para permitir que la misma no sea utilizada por terceros no autorizados. El copiado de la información del ambiente de producción al ambiente de prueba deberá ser autorizado por los dueños de esta información, a fin de que ellos evalúen el riesgo de utilización de la misma, documentando este proceso correctamente. Una vez que el conjunto de información copiado y procesado no es utilizado más, el mismo deberá ser borrado y debemos efectuar el control correspondiente.

Protección de los programas (versionado) y casos de pruebas (control calidad)

Seguridad en los procesos de desarrollo y de soporte (*)

a seguridad aplicada en los procesos de desarrollo y soporte, apunta a proteger los programas del sistema en cada uno de los ambientes, la información propia en cada uno de ellos y que cualquier cambio que realicemos no impacte en el resto del mapa de aplicaciones de la organización. La manera de aplicar un esquema seguridad es mediante la inclusión de procedimientos y de equipos interdisciplinarios donde intervienen responsables de las áreas usuarias y de informática. Estos equipos trabajan en forma conjunta analizando cada pedido de cambio y cada instalación de nueva versión, este sea en el ambiente de prueba como en el ambiente de producción. Donde aseguraremos la calidad de los programas instalados en el ambiente de prueba, y reduciremos el riesgo de toda implementación en el ambiente de producción. El conjunto de procedimientos, conlleva una serie de documentos y roles de personas que nos permitan realizar los controles y el seguimiento correspondiente asegurando la integridad de los activos de información tanto del equipo de desarrollo como del resto de la organización.

Información necesaria aplicada al control de cambios de programas

- Referentes, dueños o responsables usuarios del aplicativo en cuestión.
- Referentes o responsables del área de desarrollo del aplicativo en cuestión.
- Identificación del aplicativo, versión, módulo, y detalle de la actualización o mejora instala.
- Detalle de programas, componentes, servicios y bases de datos que serán actualizados.
- Número de identificación y sobre que ambiente fue realizada.
- Aprobación formal de la prueba realizada por el área de desarrollo.
- Aprobación formal de la prueba realizada por el área usuaria.
- Casos de pruebas, resultados esperados y resultados obtenidos de dichas pruebas.
- Documentación de respaldo de las pruebas realizadas.
- Autorización del equipo multidisciplinario de la instalación o no, en cuestión.
- Conjunto de incidentes solucionados o no, luego de la prueba realizada.
- Detalles del entorno o consideraciones particulares al momento de la instalación.

Conclusión de la ISO/IEC 17799

Concluyendo sobre lo expuesto de este estándar internacional, debemos centrarnos en una posición de compromiso y responsabilidad frente a la seguridad de la información y determinar cual es el nivel de nuestro equipo de trabajo u organización frente a este tema. Los niveles adquieren relevancia dentro del marco estratégico, táctico y operativo de nuestra organización o equipo de trabajo.

Para ello hemos preparado 20 disparadores autoevaluadores que nos permitirá repasar rápidamente los dominios de la normativa y los objetivos más importantes en cada uno de ellos. Queda para cada uno de nosotros la decisión de quedarse en el estado de comodidad actual, o bien, dar el paso de llevar el conocimiento a la práctica, buscando aprender y mejorar el nivel de seguridad en lo que a nuestras actividades se refiere. El análisis efectuado sobre esta normativa tiene por objeto conocer los temas que anteriormente no sabíamos que existían y salir de nuestra ceguera en los temas de seguridad de la información, para poder ir creciendo profesionalmente, siendo mas competentes en la implementación a pasos escalonados de una normativa de estas características.

Disparadores Autoevaluadores

1.- ¿Cuáles son las políticas de seguridad que protege las actividades de nuestro equipo de trabajo u organización? ¿Consideramos que la máxima autoridad responsable de la organización se encuentra comprometida con estas políticas?
2.- ¿Quién es la persona referente en gestionar los aspectos de la seguridad de la información dentro de nuestro equipo de trabajo? ¿Cómo se encuentran conformados los roles dentro de nuestro equipo de trabajo? ¿Para qué están cada uno de ellos?
3.- ¿Para qué debe acceder un tercero a los activos de información de nuestro equipo de trabajo? ¿De qué tercero estamos hablando? ¿Cuáles son los mecanismos de control que utilizamos cuando accede un tercero?
4.- ¿Las actividades contratadas externamente cumplen las mismas o mejores políticas de seguridad que la de nuestra organización?
5.- ¿Cuáles son los activos de información más relevantes con los que tenemos contacto? ¿Qué clasificación poseen? ¿Cómo están siendo protegidos?
6.- ¿Cómo es protegida la propiedad intelectual de los programas que desarrollamos? ¿Cómo está estructurado el licenciamiento de nuestros desarrollos?
7.- ¿Tenemos un módulo de seguridad totalmente probado y alineado a las mejores prácticas internacionales? ¿Cómo hemos implementado la administración de privilegios y perfiles dentro del aplicativo? ¿Qué características distintivas puedo indicar sobre el concepto de contraseñas en nuestros desarrollos? ¿
8.- ¿Cuáles son los controles y monitoreos que son propuestos a través del módulo de seguridad de nuestro aplicativo? ¿Qué reportes o informes ofrece? ¿Qué actividades de seguridad del usuario estamos registrando?
9.- ¿Cada cuánto realizamos un entrenamiento de nuestros sistemas a todos nuestros clientes? ¿Y sobre los aspectos aplicados a la seguridad de los activos de información? ¿Nuestros clientes nos piden el entrenamiento o nosotros realizamos el pedido en forma periódica? ¿Nuestros clientes saben lo que no saben o no saben que no saben?
10.- ¿Cuál es el circuito administrativo con que cuenta nuestro equipo de trabajo, para la recepción, seguimiento, resolución y aprendizaje de los incidentes o errores encontrados por nuestros clientes?
11.- Antes de que nos retiremos de nuestro escritorio ¿Bloqueamos la pantalla de nuestra computadora a fin de que ninguna persona pueda acceder a nuestra información?
12.- Antes de retirarse de la organización ¿Controlamos que la información que queda en nuestro escritorio no sea confidencial y sea fácilmente accedida por un tercero?
13.- ¿Cuál es nuestro plan de acción en caso de ocurrir una emergencia en las instalaciones de nuestra organización que impida darle continuidad al negocio?
14.- ¿Nuestro equipo de trabajo posee separado las funciones de control de las operativas, y las administrativas de las de ejecución?
15.- ¿Se encuentran separados los ambientes de desarrollo, prueba y producción?
16.- ¿Con qué frecuencia realizamos copias de resguardos de nuestra información? ¿Por cuánto tiempo son resguardadas?
17.- ¿Cómo se definieron los requerimientos de seguridad del módulo de seguridad de nuestro aplicativo? ¿Desarrollamos un módulo único o distinto por cada uno de los aplicativos desarrollados?
18.- ¿Con qué validaciones cuenta el ingreso de datos de nuestro aplicativo? ¿Qué controles de proceso interno posee? ¿Qué controles conciliatorios implementamos en la exposición de datos de salida?
19.- ¿Qué metodología utiliza nuestro equipo en la protección de los programas y bases de datos utilizados en nuestros desarrollos? ¿Quién es la persona responsable de la protección y seguimiento de estos activos de información?
20.- ¿Cómo determinamos los riesgos y el momento oportuno de la instalación de paquetes de programación en los diferentes ambientes de prueba y producción? ¿Cómo es el proceso de control y validación?

Las 4 partes de este artículo podrán consultarse en los siguientes enlaces luego de su publicación: Parte 1, Parte 2, Parte 3 y Parte 4. 

Autor: Oscar Andrés Schmitz