GUÍA DE CONTROLES GENERALES DE SISTEMAS DE INFORMACIÓN

Transcripción

1 GUÍA DE CONTROLES GENERALES DE SISTEMAS DE INFORMACIÓN Anexo a la Guía de Ayuda y Referencia a las nuevas Normas Técnicas en la auditoría de cuentas en entornos informatizados

2 Contenido INTRODUCCIÓN... 3 Controles del área de SEGURIDAD... 4 SL1 Política de seguridad... 4 SL2 Identificación de usuarios... 6 SL3 Política de contraseñas... 8 SL4 Autorización de usuarios SL5 Gestión de usuarios SL6 Usuarios administradores SL7 Seguridad física SL8 Controles Antivirus SL9 Supervisión de la Seguridad Controles del área de DESARROLLO PD1 Gestión de cambios PD2 Cambios autorizados PD3 Adquisición de aplicaciones y servidores PD4 Cambios de emergencia PD5 Integración de nuevas aplicaciones PD6 Entorno de pruebas PD7 Selección de proveedores PD8 Acuerdos de Nivel de Servicio Controles del área de EXPLOTACIÓN MS1 Copias de seguridad MS2 Pruebas periódicas de las copias de seguridad MS3 Supervisión de los procesos de sistemas MS4 Gestión de incidencias MS5 Protección de hojas de cálculo MS6 Traspasos de información MS7 Ejecución de procesos automáticos Guía de controles generales de sistemas de información Página 2

3 INTRODUCCIÓN A continuación se detallan las guías explicativas asociadas a los controles de Seguridad (SL), Desarrollo (PD) y Explotación (MS). Estas guías han sido desarrolladas utilizando como marco de referencia el CobIT (Control Objectives for Information Technology) y su objetivo es proporcionar una primera aproximación sobre los aspectos más relevantes en la auditoría de sistemas de información. Como aproximación, estas guías suponen una visión genérica y formativa que sus autores tienen sobre la materia, no pretendiendo ser en ningún caso la única visión ni la más relevante. Por otra parte, estas guías se han desarrollado de forma genérica, debiendo el auditor adaptar su conocimiento y plan de trabajo a cada uno de los sistemas concretos auditados. En conclusión, estas guías no pueden tomarse como una checklist o una visión única, sino que deben tenerse en cuenta en términos de formación y ampliación de conocimientos para auditores no especialistas en sistemas de información. Ante cualquier duda sobre cómo proceder en una situación concreta se recomienda se solicite consejo profesional de personal cualificado en materia de auditoría de sistemas de información. El presente documento y su contenido son propiedad de ISACA Barcelona Chapter. Guía de controles generales de sistemas de información Página 3

4 Controles del área de SEGURIDAD SL1 Política de seguridad Se dispone de una política de seguridad de la información. RIESGO ASOCIADO No disponer de una política de seguridad de la información suele estar relacionado con una escasa involucración de la dirección en los aspectos relacionados con la seguridad y, en última instancia, aumenta el riesgo de pérdida de confidencialidad, integridad y disponibilidad de la información. PRUEBA DE DISEÑO La política de seguridad es un documento, explícitamente aprobado por la dirección, donde ésta se compromete a implantar y supervisar una serie de controles en materia de seguridad de la información. Es un documento breve que contiene una declaración de intenciones genérica acerca de los aspectos más relevantes para la dirección, como por ejemplo la regulación del uso de los recursos de la organización únicamente para el desempeño de las funciones del empleado, o la obligación de reportar a la dirección cualquier incidente de seguridad. La política de seguridad es el punto de partida para el denominado cuerpo normativo de seguridad, de más bajo nivel y que contendrá normas, procedimientos y estándares más específicos, como por ejemplo la política antivirus. En consecuencia, se debe preguntar por la existencia de una política de seguridad y si ésta se encuentra aprobada por la dirección y ha sido debidamente actualizada. En caso de que se disponga de ella, se adjuntará como evidencia del control. En caso contrario, es posible que la organización disponga de algún procedimiento de más bajo nivel, como por ejemplo política de gestión de usuarios o política de respaldo. Se solicitará evidencia de todos los documentos relacionados con estos aspectos disponibles. Se debe validar también que la política se encuentre al alcance de todos los empleados de la organización. Tal y como se ha comentado en el apartado anterior, la organización puede no disponer de una política pero sí de procedimientos de seguridad de bajo nivel. A continuación se relacionan algunos procesos de bajo nivel que podría encontrar un auditor: Mecanismos para distinguir la información confidencial de la normal. Procedimientos de utilización de sistemas informáticos (uso del correo, de internet ) Cláusulas de confidencialidad en caso de accesos externos a información. Guía de controles generales de sistemas de información Página 4

5 Alta, modificación y eliminación de usuarios en el sistema. Mecanismos de control de acceso lógico (quién puede acceder a qué). Planificación de copias de respaldo en caso de que se pierda algún fichero. Mecanismos de seguridad física (un torno en la entrada, extintores ) Procedimientos de aceptación de nuevos empleados (revisión de credenciales antes de la contratación ) Procedimientos de protección de los equipos informáticos (antivirus, protección de red ) Metodología de desarrollo de nuevas aplicaciones o modificaciones sobre las existentes. El auditor deberá valorar, en ausencia de una política formal, cuántos de los procesos anteriores se encuentran cubiertos y formalizados. Es habitual que una organización pueda ejecutar muchos de estos procesos sin llegar a tenerlos formalizados ni aprobados. Aunque sea un defecto de forma, no formalizar estos procesos puede suponer riesgos considerables, dada la complejidad habitual de los procesos de sistemas. Por otra parte, muchas organizaciones se encuentran sujetas a la normativa sobre datos de carácter personal (LOPD) y, por tanto, disponer del denominado documento de seguridad LOPD. Este documento recoge todos los requerimientos de seguridad implementados por la organización en materia de LOPD y puede ser muy útil para detectar los procedimientos de bajo nivel antes mencionados. Sin embargo, este documento NO constituye una política de seguridad en sí misma, y debe tenerse en cuenta que la LOPD tiene como ámbito los datos de carácter personal únicamente. La política de seguridad abarca cualquier tipo de información, personal o no, informatizada o no. PRUEBA DE EFICACIA OPERATIVA La prueba de eficacia operativa es muy sencilla ya que la población se compone de un único documento. Se recomienda validar que se encuentre firmado, actualizado y se haya publicado adecuadamente. La política debe cubrir toda la organización, incluyendo cualquier sistema, ubicación o cualquier otro activo. Adicionalmente, validar, sobre una muestra de usuarios de distintas responsabilidades, si tienen conocimiento de la política de seguridad y si sabrían ubicarla si fuera necesario. Se debe adjuntar como evidencia toda la documentación recibida. Guía de controles generales de sistemas de información Página 5

6 SL2 Identificación de usuarios La Organización ha establecido un mecanismo de identificación/autenticación para los sistemas de información, que proporcione responsabilidad individual (cuentas individuales por usuario). RIESGO ASOCIADO Disponer de cuentas compartidas para determinadas funciones clave del negocio impide realizar un seguimiento de la responsabilidad asociada a determinadas acciones críticas, como puede ser cerrar un período contable, realizar pagos, transferencias, etc PRUEBA DE DISEÑO Preguntar al responsable del proceso de creación de usuarios por si se dispone de alguna regla sobre nomenclatura de usuarios o normativa al respecto, como por ejemplo que todos los usuarios comiencen por la inicial del nombre y el primer apellido de la persona (julian perez = jperez) Preguntar si hay excepciones a esta regla. Como ejemplos de excepciones, podrían ser las siguientes: Usuarios administradores del sistema, suelen utilizar usuarios admin o similar. Usuarios de fábrica o de producción, que suelen compartir el mismo usuario en función de su turno de fabricación. Usuarios de recepción, que suelen compartir también en función de su turno de trabajo. Adjuntar como evidencia cualquier normativa formalizada al respecto. Es importante que se puedan asociar los usuarios de sistema a personas concretas, de forma que situaciones donde la nomenclatura de usuario es críptica (julian perez = usuario1346) no son aconsejables. Por otra parte, si la organización no tiene controlados sus usuarios genéricos (compartidos por varias personas) suele ser síntoma de escasez de control en este sentido. Los usuarios con acceso a información contable (entrada de apuntes, realización de pagos) o a información sensible (RRHH, dirección), no deberían compartirse. PRUEBA DE EFICACIA OPERATIVA Solicitar al responsable de sistemas un listado de usuarios de los sistemas que soportan los procesos más críticos (contabilidad, tesorería, RRHH principalmente) Sobre dicho listado, el auditor deberá validar si se cumple la normativa interna (se haya formalizado o no) sobre creación de nombres de usuario (validar si todos los usuarios tienen el formato inicial más apellido, en el caso anterior). Guía de controles generales de sistemas de información Página 6

7 El auditor también deberá identificar aquellos usuarios que podrían ser compartidos, como por ejemplo admin, usuario00, guest, contabilidad, etc En función del número de usuarios existente, el auditor puede solicitar únicamente una muestra de usuarios, de acuerdo con la metodología de auditoría que esté aplicando. Sobre dichos usuarios deberá pedir justificación. Es posible que una organización tenga usuarios genéricos o que no respetan la nomenclatura establecida. Es criterio del auditor determinar si dichos usuarios son relevantes para la auditoría o no. Por ejemplo, un usuario compartido contabilidad por más de tres personas limita bastante las opciones de trazabilidad, responsabilidad y control interno de una organización. En cambio, un usuario compartido de recepción de un hotel tiene un riesgo más limitado, ya que únicamente puede afectar al arqueo de caja del día, probablemente, y ya se dispondrá de controles de proceso que permitan mitigar el riesgo de pérdida. Este control es especialmente relevante en sectores o puestos con elevada rotación y cierta responsabilidad. En cuanto a las justificaciones, es recomendable que la organización intente identificar las personas detrás de cada usuario aunque no sea mediante los sistemas. Por ejemplo, si un usuario se comparte por tres personas en función de su turno en la fábrica (de ocho horas cada uno), se puede identificar la persona con el usuario y sabiendo el turno concreto en que trabaja. De esta forma sí se puede establecer responsabilidad. Guía de controles generales de sistemas de información Página 7

8 SL3 Política de contraseñas La organización ha definido controles de autenticación basados en la existencia de contraseñas. La política de seguridad contiene las reglas de administración y sintaxis de las mismas. RIESGO ASOCIADO Disponer de usuarios con contraseñas débiles (cortas, repetibles, sencillas, etc ) aumenta el riesgo de suplantación de identidad de usuarios legítimos, lo que puede conllevar falta de confidencialidad, integridad y disponibilidad de la información. PRUEBA DE DISEÑO Preguntar al administrador por la política corporativa de contraseñas. Se encuentre formalizada o no, dicha política debería contener al menos los siguientes aspectos: Caducidad (cada cuánto tiempo el usuario debe cambiar la contraseña) Bloqueo por intentos fallidos (número de intentos de gracia que el usuario dispone hasta el bloqueo de la cuenta) Complejidad (Requisitos de complejidad como usar minúsculas y mayúsculas, usar signos de puntuación o no usar nombres de diccionario) Tiempo de inactividad (tiempo de inactividad en el sistema, tras el cual el usuario queda bloqueado y se debe reintroducir la contraseña) Longitud mínima y máxima de la contraseña. Histórico de contraseñas (al cambiar de contraseña, el usuario no puede volver a repetir un número determinado de contraseñas antiguas) La política de contraseñas debería especificar los sistemas incluidos dentro de la normativa, como por ejemplo Windows como sistema operativo y SAP como herramienta corporativa. En consecuencia, el auditor deberá preguntar por los parámetros definidos para los sistemas más relevantes de la organización. En primer lugar se debe evaluar si la organización dispone de una política de contraseñas definida y valorar su nivel de formalización, adjuntándola como evidencia en caso de que exista. En segundo lugar se deberá evaluar la bondad de la política de contraseñas definida (formalizada o no). Los valores más habituales de los parámetros son: Caducidad: Entre 45 días y 90 días. Bloqueo por intentos fallidos: Entre 3 intentos y 10. Complejidad: Activada (depende del sistema, pero requerimientos típicos hacen que sean necesarios números y caracteres raros, o impiden que la contraseña sea el nombre de la organización). Tiempo de inactividad: Entre 15 minutos y 2 horas. Longitud mínima y máxima: Mínima entre 5 o 6 y máxima 10. Guía de controles generales de sistemas de información Página 8

9 Histórico de contraseñas: Entre 5 y 20. Evaluar la bondad de los criterios definidos por la organización depende del criterio del auditor, ya que la efectividad del control dependerá de la combinación de varios parámetros. Por ejemplo, no sirve de nada que el usuario cambie la contraseña cada 15 días si no hay requisitos de complejidad y de histórico, y siempre pone como contraseña: Otro ejemplo habitual es disponer de contraseñas muy complejas, que combinen caracteres raros, números y letras (por ejemplo C4st4ña_P1l0ng4). Este tipo de contraseñas lo que conseguirán es que el usuario se la apunte en un papel y la tenga encima de la mesa, lo que desvirtúa el control. En tercer lugar se debe evaluar si el sistema permite parametrizar este tipo de condiciones, es decir, longitud de contraseña, etc Si no lo permite habría una deficiencia de control relevante, ya que por muchas políticas que hayan definido será difícil ponerlas en práctica. Si el sistema permite parametrizar las condiciones se podrá realizar la prueba de eficacia operativa posterior. PRUEBA DE EFICACIA OPERATIVA El auditor deberá realizar una prueba independiente para cada uno de los sistemas involucrados en la auditoría. Como habitualmente son pocos sistemas involucrados y dado el riesgo asociado al control, se recomienda no realizar muestreo en relación a las pruebas de este control. Para cada sistema involucrado, solicitar al responsable de sistemas evidencia de la parametrización de la seguridad (es decir, de los parámetros anteriores). Sobre dicha evidencia evaluará la adecuada implantación de los parámetros de seguridad en base a si son los que se han definido en la política de contraseñas de la organización. También se evaluará si son adecuados. Se debe adjuntar como evidencia toda la documentación recibida y solicitar justificación de aquellos casos en que no se disponga. En cuanto al alcance, lo más habitual es que el auditor tenga en cuenta el sistema operativo principal (aquel con el que entran al sistema todos los usuarios) y la aplicación con afectación contable. En cuanto a las evidencias, lo más habitual es obtener un pantallazo del sistema donde vengan configurados los parámetros a analizar. La mayoría de sistemas y aplicaciones estándar disponen de un menú donde obtener estos parámetros directamente. Otra opción es probar directamente las directrices en el sistema, utilizando un usuario creado para la prueba e intentando cambiarle la contraseña con diferentes longitudes, etc En ocasiones también puede obtenerse evidencia a partir de entrevistas. No es extraño que el propio responsable de contabilidad o administración le comente al auditor que no ha modificado su contraseña de acceso en todo un año. Guía de controles generales de sistemas de información Página 9

10 Algunas organizaciones disponen de una aplicación mediante la cual el usuario sólo debe autenticarse una vez para tener acceso a todas las aplicaciones que necesita (por ejemplo el Directorio Activo de Windows) Guía de controles generales de sistemas de información Página 10

11 SL4 Autorización de usuarios Los usuarios disponen de permisos en el sistema de acuerdo a las funciones que desempeñan. Dichos permisos se encuentran aprobados por sus responsables y cumplen una adecuada segregación de funciones. RIESGO ASOCIADO No disponer de controles sobre la asignación de permisos sobre los usuarios puede conllevar que personal interno acceda, modifique o elimine información para la que no tiene autorización. PRUEBA DE DISEÑO Preguntar al responsable de sistemas por la política de accesos a los sistemas. La política de accesos es la que define a qué puede acceder y a qué no un usuario de la organización. La política de accesos de la organización debería cumplir los siguientes requisitos: Todos los accesos deben ser autorizados por el responsable de la información accedida. Es decir, el responsable del área de contabilidad (o sus jerárquicamente superiores) debería ser el que decidiera quién puede acceder y quién no a la información sobre contabilidad. El usuario tendrá acceso únicamente a la información que necesita para el desempeño de sus funciones. Por ejemplo, un usuario de contabilidad no debería tener acceso a la aplicación de RRHH a menos que también realice funciones de formación o gestión de personal. Se deben cumplir requisitos de segregación de funciones. Por ejemplo, siempre que sea posible evitar que el mismo usuario que realice un pedido sea el mismo que realice el pago de dicho pedido. Habitualmente las organizaciones implementan un sistema de grupos y perfiles en los sistemas para definir estos límites. En el caso de que no haya una política definida, el auditor puede preguntar por la implementación real de los grupos y perfiles, y evaluar hasta qué punto se cumplen los tres requisitos anteriores. La aprobación de accesos no suele ser demasiado formal. De todas formas, un responsable de área (por ejemplo, el director financiero) debería conocer en una empresa no muy grande, todas las personas que pueden acceder a la información bajo su responsabilidad. Por otra parte, se recomienda incluir en la política una revisión periódica de los accesos de los empleados. Al ser el responsable funcional el encargado de validar la revisión, uno de los beneficios es que los usuarios pueden darse por aprobados tras la revisión. La segregación de funciones es muy compleja de implementar en organizaciones pequeñas, especialmente cuando los departamentos de administración están compuestos por pocas Guía de controles generales de sistemas de información Página 11

12 personas. En estos casos, el auditor debe tener en cuenta la posible implementación de controles alternativos, como por ejemplo, en el caso anterior de pedidos y pagos, que siempre haya un responsable independiente encargado de supervisar el pago. PRUEBA DE EFICACIA OPERATIVA El auditor deberá realizar una prueba independiente para cada uno de los sistemas involucrados en la auditoría. Para cada sistema, el auditor deberá solicitar al responsable de sistemas un listado con todos los usuarios disponibles. En función del número de usuarios existente, el auditor puede solicitar únicamente una muestra de usuarios, de acuerdo con la metodología de auditoría que esté aplicando. El listado deberá contener el identificador de usuario y todos los accesos del mismo, habitualmente agrupados en perfiles y grupos lógicos. Para los usuarios el auditor debe validar que sus accesos (grupos y perfiles a los que pertenece) se encuentran aprobados y son revisados periódicamente. También deberá validar si se cumple la normativa existente con respecto a segregación de funciones y si los usuarios disponen de más permisos de los que necesitan. Se debe adjuntar como evidencia toda la documentación recibida y solicitar justificación de aquellos casos en que no se disponga. En función del sistema analizado, validar realmente los permisos de cada usuario puede ser una tarea muy compleja. Es por este motivo que se recomienda un primer nivel de análisis basado en analizar los perfiles y grupos, que suelen ser más sencillos. Los perfiles y grupos suelen tener nombres representativos, como por ejemplo contabilidad o administración, ya que son utilizados por los administradores para la gestión de usuarios. Por ejemplo, ante una nueva incorporación al área de contabilidad, se le asignará al usuario probablemente el grupo contabilidad, con todos los permisos que conlleve. Habitualmente los permisos a los usuarios se asignan en varios niveles: Nivel general, es decir, los permisos compartidos por el departamento, donde se incluye una carpeta de red compartida, habitualmente y las aplicaciones típicas. Nivel personal, es decir, una carpeta de red personal para el usuario y ciertas transacciones sólo disponibles para él. Por ejemplo, el director financiero debería ser uno de los pocos usuarios con capacidad para cerrar un período contable. Nivel específico, es decir, varias personas compartiendo una unidad de red no departamental. Es el caso habitual del área de gestión de RRHH, donde suele haber carpetas específicas para el personal encargado de Nóminas, a las que no pueden acceder las personas encargadas de formación, por ejemplo, a pesar de compartir departamento. Una opción para analizar la adecuación de los permisos de usuarios es utilizar un enfoque inverso, es decir, preguntar por una función específica y obtener los usuarios autorizados. Por Guía de controles generales de sistemas de información Página 12

13 ejemplo, se puede preguntar por los usuarios con capacidad de realizar pagos y compararlos con las personas que realizan dicha función. No es lógico que todo el departamento tenga esta capacidad si finalmente sólo una o dos personas realizan dicha función. En todo caso, se recomienda solicitar la ayuda de un especialista en auditoría de sistemas si el auditor detecta que la asignación de permisos a usuarios es demasiado compleja (un número elevado de grupos y perfiles o un elevado número de permisos específicos) Guía de controles generales de sistemas de información Página 13

14 SL5 Gestión de usuarios La Organización ha implementado controles para garantizar que las altas, bajas y modificaciones de usuarios se gestionan de manera oportuna para reducir el riesgo de accesos no autorizados o inapropiados. RIESGO ASOCIADO No disponer de una adecuada gestión de usuarios puede conllevar accesos no autorizados a los sistemas, realizados incluso por personal no perteneciente a la organización (creación de usuarios no autorizados) o por usuarios dados de baja de la organización. PRUEBA DE DISEÑO Preguntar al responsable de sistemas por el procedimiento de gestión de usuarios. Un procedimiento de gestión de usuarios describe los pasos a seguir cuando se da de alta un usuario en el sistema, cuando se da de baja un usuario en el sistema y cuando un usuario es trasladado de posición. Para cualquiera de los procesos descritos (alta, baja o modificación de usuarios), es fundamental que el procedimiento contenga la necesidad de una petición, por parte del responsable autorizado. Esta petición debería contener: En el caso de las altas, el detalle del nuevo usuario y los permisos de acceso concretos que se le deben facilitar. Cuando sea necesario deberá incluir los equipos que necesita (ordenadores, móviles, tarjetas de acceso, etc ) En el caso de las modificaciones, el detalle de los nuevos permisos de accesos y cualquier otra variación necesaria en el equipo físicos. En el caso de las bajas, el detalle del usuario a dar de baja y la fecha a partir de la cual no deberá disponer de acceso. En este caso también se debería incluir un procedimiento para gestionar la información pendiente (por ejemplo, redireccionar todo el correo recibido al responsable jerárquico durante un tiempo) Es posible que el procedimiento no se encuentre formalizado. En estos casos se puede preguntar por la forma de realizarlo, ya que las altas de empleados son imprescindibles para que las incorporaciones puedan desempeñar sus funciones. En cuanto a las altas, es posible que la organización no disponga de peticiones formales y el responsable simplemente indique que el nuevo empleado tenga el mismo perfil que otro empleado ya existente. Es importante que el procedimiento contenga la involucración de RRHH para confirmar las altas de empleados. En cuanto a las modificaciones, en ocasiones son tratadas como una baja (en el departamento antiguo) y un alta (en el departamento nuevo). Es habitual que una organización gestione los traslados dando de alta las nuevas funciones pero sin dar de baja las antiguas, lo que conlleva que el empleado vaya acumulando las funciones de todos aquellos departamentos por los que va pasando. Guía de controles generales de sistemas de información Página 14

15 En cuanto a las bajas, es posible que la organización no las tenga en cuenta o ni siquiera las comunique. Es posible que desde RRHH se gestione la tramitación pero nadie comunique al área de sistemas que el usuario debe darse de baja en los sistemas, lo que también supone una deficiencia de control. PRUEBA DE EFICACIA OPERATIVA La población para realizar esta prueba son las altas, bajas y modificaciones que se han producido en la organización durante el período analizado y que dispongan de acceso a los sistemas de información (por ejemplo, las altas y bajas de empleados de una planta de fabricación pueden descartarse si dichos empleados no acceden al sistema). En función del número de usuarios existente, el auditor puede solicitar únicamente una muestra de usuarios, de acuerdo con la metodología de auditoría que esté aplicando, siempre teniendo en cuenta las tres poblaciones (altas, bajas y modificaciones) por separado. Se debe solicita a RRHH un listado con las altas, bajas y traslados de la organización, así como al área de sistemas un listado con todos los usuarios activos en el sistema auditado. Para las altas, se comprobará la solicitud (si la hubiera) y que sus permisos en el sistema corresponden con las especificaciones de la misma. Para las modificaciones o traslados, se comprobará la solicitud (si la hubiera) y se validará que los permisos corresponden únicamente con las nuevas funciones a desempeñar. Para las bajas, se comprobará la solicitud (si la hubiera) y se validará que el usuario ya no se encuentra entre los usuarios activos del sistema. Se debe adjuntar como evidencia toda la documentación recibida y solicitar justificación de aquellos casos en que no se disponga. Detectar usuarios activos que ya no son parte de la organización es indicativo de que se están relajando los procedimientos de gestión de usuarios. Cuando un empleado causa baja no hay ningún motivo para no bloquear su usuario en un tiempo razonable. Bloquear el usuario no acostumbra a ser una tarea costosa ni compleja, y sin embargo evita el riesgo de que dicho usuario pueda acceder, especialmente cuando se permiten accesos desde el exterior. Detectar usuarios que han sido trasladados pero que todavía conservan sus antiguos permisos también es indicativo de relajación. Estos usuarios disponen de más permisos de los necesarios y podrían incurrir en conflicto de segregación de funciones. En ambos casos se pude consultar al responsable de sistemas para comprobar si alguno de estos usuarios ha accedido a las funciones a las que ya no tiene acceso autorizado, para comprobar si el riesgo se ha materializado. Pueden existir controles compensatorios, como por ejemplo revisiones periódicas de usuarios para eliminar los que están dados de baja. Guía de controles generales de sistemas de información Página 15

16 Por último, cabe destacar que este control (y sus posibles deficiencias) es más relevante cuando afecta a cargos intermedios o superiores, así como a personal administrador de sistemas (y que por tanto, dispone de accesos menos limitados). Guía de controles generales de sistemas de información Página 16

17 SL6 Usuarios administradores Los usuarios con mayores privilegios de acceso en el sistema son utilizados únicamente por personal autorizado y de forma segura. RIESGO ASOCIADO Acceso no autorizado a la información de la organización, con el agravante de que los usuarios avanzados pueden realizar acciones más críticas que los usuarios normales (como por ejemplo crear usuarios falsos en el sistema, modificar la seguridad del sistema para no ser descubiertos, etc ) PRUEBA DE DISEÑO Preguntar al responsable de sistemas si se han definido políticas específicas para los usuarios administradores del sistema. Estas políticas deberían contemplar un cumplimiento estricto de las medidas recomendadas en los controles SL2, SL3, SL4 y SL5. Por ejemplo, en el control SL3 se recomienda que las contraseñas de los usuarios se deban modificar periódicamente, siendo adecuado un cambio cada 45 o 60 días. En el caso de los usuarios administradores se debería recomendar que se modificaran cada 45 días como máximo. Por otra parte, los sistemas suelen venir con un usuario administrador por defecto. Este usuario administrador es el que se utiliza en el momento de la instalación y posee una contraseña también por defecto. Por ejemplo, en Windows se dispone del usuario administrator, cuya contraseña siempre es la misma. En este sentido, las políticas deben recomendar que no existan usuarios administradores con contraseñas por defecto. Todo sistema necesita de un usuario administrador que tenga permisos completos sobre el mismo. Por ejemplo, en la aplicación SAP es todo aquel usuario que posea el perfil SAP ALL. Este tipo de usuarios puede acceder a todas las funciones del sistema sin limitaciones. Es por esto que se les suele llamar super usuarios (disponen de los mismos privilegios que todos los usuarios juntos), aunque también puede eliminar o crear otros usuarios y puede modificar la parametrización de seguridad del sistema. Un usuario con semejante nivel de acceso debería encontrarse muy controlado. En conclusión, el usuario administrador es necesario (e inevitable) pero sí se puede controlar. De todas las medidas incorporadas en los controles SL2, SL3, SL4 y SL5 la primera a tener en cuenta sería la de la aprobación de usuarios y permisos, es decir, las personas con derechos de administración del sistema deberían ser las mínimas imprescindibles y estar aprobadas por un responsable funcional (en este caso la dirección, dada la relevancia del acceso). En cuanto a las medidas de seguridad de contraseña, como pueden ser la complejidad y bloqueo de la misma, deberían ser más estrictas que las de usuarios normales, a menos que los usuarios normales ya dispongan para sus contraseñas medidas muy estrictas, lo que no es habitual. Guía de controles generales de sistemas de información Página 17

18 Se debe tener en cuenta que algunas medidas no son aplicables. Por ejemplo, si se bloquea la cuenta del usuario después de 5 intentos, habitualmente es el administrador el que proporciona al usuario su nueva contraseña. Pero, qué ocurre si se ha bloqueado precisamente la cuenta del administrador? O la organización dispone de un método alternativo o la medida no es aplicable. En general, las políticas relacionadas con los usuarios administradores pueden no encontrarse formalizadas o ser las mismas que las de los usuarios normales. En estos casos el auditor deberá evaluar si las medidas son suficientes también para este tipo de usuarios. Sin embargo, la modificación de las contraseñas por defecto es un aspecto que, si el sistema lo permite (no se permite en todos) es sencillo de implementar y muy efectivo. Por otra parte, no es recomendable que el usuario administrador se asigne a una persona física. Supongamos que el responsable de sistemas es la persona autorizada como administrador. En este caso debería disponer de un usuario con muchos permisos (pero no todos) y que entrase en el sistema como administrador sólo cuando necesite acceder a funciones de administrador. Esta buena práctica mejora sensiblemente la protección de este tipo de usuarios. PRUEBA DE EFICACIA OPERATIVA A partir de la lista de sistemas relevantes (sistemas operativos, aplicaciones y bases de datos), validar que las medidas de seguridad se encuentran correctamente implantadas para todos los usuarios administradores. Dado que este tipo de usuarios deberían ser muy escasos, no se recomienda probar el control mediante una muestra. Se debe adjuntar como evidencia toda la documentación recibida y solicitar justificación de aquellos casos en que no se disponga. El primer aspecto a validar es el número y adecuación de los administradores. No debería haber más de uno o dos administradores para cada sistema. Por otra parte, deberían ser asignados a personal adecuado ( es necesario que el responsable de contabilidad sea administrador? Es necesario que todo el departamento de sistemas sea administrador?). Los administradores deben ser aprobados explícitamente por la dirección y después se deben comprobar sus parámetros de seguridad ( cada cuánto cambia su contraseña? es compleja?). Puede darse el caso de organizaciones en las que se alegue que todo el departamento de sistemas debe tener acceso a un usuario administrador, para cubrir casos de vacaciones, etc. En estos casos se recomienda disponer de un usuario administrador disponible en un recinto cerrado con llave (idealmente una caja fuerte), de forma que el usuario que lo necesite pueda abrir la caja fuerte y acceder a la contraseña si está autorizado. Tras realizar la tarea de administración, deberá modificar la contraseña y dejarla en la caja fuerte de nuevo. Cuando el administrador legítimo vuelva deberá reiniciar la contraseña para que no se pueda volver a utilizar. Guía de controles generales de sistemas de información Página 18

19 SL7 Seguridad física La Organización ha implementado controles que garanticen la protección física de los servidores y equipos críticos. RIESGO ASOCIADO No disponer de medidas de protección física de los equipos críticos y servidores puede afectar a la disponibilidad de la información (como por ejemplo un incendio o una inundación) o su confidencialidad (accesos no autorizados) PRUEBA DE DISEÑO Preguntar al responsable de sistemas por los procedimientos que establecen las medidas de protección física para el CPD (centro de procesado de datos) y los centros de comunicaciones. Las medidas de protección física para el CPD pueden ser de dos tipos: Ambientales: El CPD debería disponer de mecanismos de refrigeración para no sobrecalentarse además de sistemas de detección de humos y extinción de incendios, entre otros. De Acceso: Al CPD solamente debería acceder personal autorizado, y en consecuencia debería encontrarse cerrado. Consultar también si estas medidas físicas se revisan adecuadamente para validar su adecuación (por ejemplo, los extintores deben ser revisados periódicamente) Todas las aplicaciones, sistemas operativos y recursos informáticos compartidos necesitan de equipos informáticos especializados denominados servidores. Habitualmente estos servidores se almacenan en una misma sala, para facilitar su mantenimiento (deben estar a una determinada temperatura, por ejemplo). Dicha sala se denomina CPD (Centro de Procesado de Datos). Los centros de comunicaciones hacen referencia tanto a las comunicaciones de la organización con el exterior (acceso a internet) como al cableado interno (cableado del teléfono y toma de red de cada despacho). En algunas organizaciones estos centros no se encuentran en el CPD, sino que se distribuyen a lo largo de varios puntos de la oficina (varios armarios llenos de cables). Sobre el control de acceso al CPD, lo más relevante es validar que realmente únicamente personal autorizado pueda acceder. Para conseguir esto el CPD debería encontrarse cerrado como mínimo con llave y de forma habitual con una tarjeta de acceso específica. Sobre los controles ambientales, se pueden destacar los siguientes: Control de temperatura. El CPD debe genera mucho calor y si la sala no se encuentra refrigerada (aires acondicionados, por ejemplo), las máquinas se pueden sobrecalentar y quemarse. Generalmente una sala cerrada con aire acondicionado y termostato suele ser suficiente. Guía de controles generales de sistemas de información Página 19

20 Detección y extinción de incendios. Detectores de humo en la sala y extintores. Aunque parece obvio es importante que el extintor se encuentre fuera de la sala. Algunas salas disponen de mecanismos automáticos de extinción, basados en compuestos especiales. Ubicación. Para evitar inundaciones, por ejemplo, se debería evitar que la sala del CPD se encontrara en un sótano o cerca de cañerías. También es recomendable que haya un falso techo y un falso suelo para poder pasar el cableado y proteger mejor la sala. Apagones. Todos los sistemas eléctricos tienen apagones (pequeños o más largos). Es importante que el CPD disponga de más de una fuente de alimentación diferente y que en caso de apagón general disponga de una fuente de alimentación (habitualmente para unos minutos) que le permita realizar un apagado ordenado. Limpieza. La sala del CPD no es de trabajo y no puede contener cartones, papeles ni despachos. Mucho menos objetos inflamables. PRUEBA DE EFICACIA OPERATIVA Comprobar las medidas de seguridad disponibles para los equipos críticos y servidores. Dichas medidas deben corresponderse con las descritas en los procedimientos internos correspondientes y también deben ser adecuadas. Esta prueba se realiza mediante inspección física de las salas. Se debe adjuntar como evidencia toda la documentación recibida y solicitar justificación de aquellos casos en que no se disponga. En general, las organizaciones únicamente disponen de un CPD o sala principal. Algunas pueden disponer de lo que se denomina CPD secundario, es decir, un CPD en otra ubicación que se pondría en marcha si el primero tuviese algún problema. A este nivel de profundidad de la auditoría se recomienda analizar la seguridad únicamente del CPD principal, a menos que las medidas del principal sean muy deficientes. En cuanto al control de acceso, la organización debería disponer de un listado de personas autorizadas y también de un registro de las personas que han accedido. El auditor podrá comparar ambos listados. En general únicamente puede acceder personal externo al CPD (por ejemplo, personal de limpieza) si su visita se encuentra autorizada y va acompañado de una persona autorizada. No disponer de un CPD cerrado o no disponer de un registro de accesos suele ser indicativo de carencia de control en este sentido. En cuanto a controles ambientales, el más relevante es el de la refrigeración. No es suficiente con disponer de aire acondicionado u otro mecanismo, sino también la organización debe supervisar que la temperatura no supera determinados umbrales (debe hacer frío en la sala). El mismo principio se puede aplicar al resto, es decir, no sirve de nada tener un extintor si éste no es revisado periódicamente o tener una fuente alternativa de alimentación si nunca se prueba que funcione. Este control se integra dentro de un proceso más amplio denominado continuidad, es decir, garantizar que la organización es capaz de reaccionar y recuperarse ante un desastre. En Guía de controles generales de sistemas de información Página 20

21 organizaciones pequeñas es posible que la dirección no se preocupe mucho por este tipo de controles hasta que ocurre lo inesperado. En todo caso, si la organización no dispone de medidas suficientes de protección física, debería al menos disponer de procedimientos o manuales que guíen al usuario para realizar los procesos de negocio más relevantes en ausencia de sistemas de información, al menos durante un tiempo. Guía de controles generales de sistemas de información Página 21

22 SL8 Controles Antivirus La Organización dispone de programas de protección frente a códigos maliciosos (virus, troyanos, escaneo de información, ) RIESGO ASOCIADO Ejecución de procesos automáticos no aprobados puede conllevar fraude interno o información errónea en los estados financieros. PRUEBA DE DISEÑO Habitualmente, una de las áreas de sistemas se denomina explotación porque se encarga de que siga funcionando todo lo que el usuario utiliza. Esto incluye herramientas ofimáticas, carpetas personales, correo electrónico, y por supuesto, las aplicaciones específicas, como de contabilidad o Recursos Humanos. Cuantos más procesos automatizados tiene una organización, más relevante es esta función. En cuanto a Antivirus, la organización debe disponer de un procedimiento de adquisición y actualización periódica de la herramienta antivirus (entendiendo virus en sentido amplio, es decir, malware, spyware, spam, etc ) Como prueba de diseño, se debe preguntar al responsable de sistemas de qué forma se supervisa esta función y si dispone de procedimientos escritos al respecto. Toda organización debe disponer de una herramienta antivirus actualizada. Los virus pueden entrar mediante el correo electrónico, en el USB de algún empleado o directamente a través de alguna de las conexiones de la organización. Se generan miles de virus nuevos cada día, algunos inofensivos y otros con capacidad para eliminar, modificar o comprometer toda la información de la organización. Hay procedimientos formales que pueden ayudar a que la exposición sea menor, como por ejemplo, evitar que los empleados puedan instalar aplicaciones que se han bajado de internet en el sistema, o impedir el acceso mediante lápices USB a los sistemas. De cualquier forma, una herramienta antivirus actualizada es el mejor mecanismo posible de detección y corrección de problemas de este tipo. PRUEBA DE EFICACIA OPERATIVA Se pueden distinguir, a grandes rasgos, dos tipos de herramientas antivirus. Las de correo electrónico y las de sistema. El auditor deberá comprobar que la organización dispone de una herramienta para cada uno de estos casos. También deberá comprobar y recoger evidencia de que dichas herramientas se encuentran actualizadas (y se actualizan periódicamente). Guía de controles generales de sistemas de información Página 22

23 Es muy habitual que las herramientas antivirus incluyan actualizaciones automáticas al ser adquiridas, al menos durante un período. Las herramientas de correo electrónico aplican a la aplicación de correo de los usuarios. Las de sistema aplican a las carpetas de red y su contenido. De todas formas se debe validar que el alcance de ambas herramientas es adecuado. Por ejemplo, que la herramienta de correo valide como mínimo los correos entrantes y que la herramienta de sistema valide las carpetas de red y los ficheros más relevantes regularmente. Es importante que se realicen escaneos periódicos sobre el sistema y sobre el correo (de esta forma se garantiza que no pase demasiado tiempo sin un escaneo), siempre priorizando las áreas más críticas de la organización. Guía de controles generales de sistemas de información Página 23

24 SL9 Supervisión de la Seguridad La Organización dispone de mecanismos de supervisión periódicos sobre los controles de seguridad. RIESGO ASOCIADO No disponer de una adecuada supervisión de la seguridad conlleva un empeoramiento progresivo de los controles de seguridad implantados. PRUEBA DE DISEÑO Preguntar al responsable de sistemas por la existencia de supervisión periódica sobre los controles de seguridad existentes en la organización, entre los que se incluyen: Revisión de los accesos de los usuarios al sistema por parte de sus responsables. Revisión de usuarios dados de baja pero todavía activos en el sistema. Revisión de los incidentes de seguridad registrados. Revisión de accesos al CPD (Centro de proceso de datos). Revisión de logs del sistema más relevantes. Actualización de sistemas antivirus. El objetivo de este control es garantizar que los controles de seguridad son implementados y ejecutados por una persona pero supervisados periódicamente por una persona diferente. La supervisión de los controles de seguridad se asigna al responsable de seguridad. Habitualmente organizaciones pequeñas y medianas no disponen de dicho responsable, aunque la función de supervisión de seguridad sigue siendo necesaria. Ya sea el responsable de sistemas el encargado u otra persona, es importante que se realice un seguimiento activo de todos los controles. Todos los controles a supervisar ya han sido descritos en apartados anteriores. El auditor debe evaluar según su criterio si la periodicidad y la profundidad de la supervisión realizada es suficiente y adecuada, teniendo en cuenta las incidencias obtenidas en la revisión de controles anteriores y su gravedad. Por ejemplo, en el control SL5 se tratan los usuarios activos en el sistema que ya han sido dados de baja. Si se han detectado usuarios dados de baja hace más de un año, quizá sería buena idea que la supervisión de este control fuera como mínimo anual. Si todos los usuarios dados de baja todavía permanecen activos en el sistema el auditor puede concluir que el control SL5 no se aplica adecuadamente y quizá la recomendación sería supervisar el control de forma semestral o incluso mensual. Guía de controles generales de sistemas de información Página 24

25 PRUEBA DE EFICACIA OPERATIVA Recoger evidencias de la adecuada supervisión y seguimiento de los controles de seguridad implantados en la organización. Se debe adjuntar como evidencia toda la documentación recibida y solicitar justificación de aquellos casos en que no se disponga. En ocasiones la organización puede estar sujeta a normativa específica que ya le obliga a supervisar alguno o todos los controles auditados (como por ejemplo SOX, LOPD ). En estos casos el auditor puede consultar los resultados disponibles como consecuencia de las auditorías específicas. En primer lugar, el auditor debe validar que la supervisión se ha realizado en la fecha adecuada y sobre los reportes adecuados. Una vez validada la forma, el auditor debe pasar a evaluar el contenido de los informes. Un primer criterio es comparar los hallazgos obtenidos como consecuencia de la auditoría de los anteriores aspectos de seguridad con la supervisión. Por ejemplo, si se ha detectado una persona del área de logística con acceso a información de RRHH, el auditor puede comprobar si dicha incidencia se encontraba en el informe supervisado. Si la incidencia no se encontraba en el informe supervisado probablemente hay un problema de integridad en el informe. Si la incidencia sí se encontraba en el informe, se puede consultar el seguimiento de la misma y si había un plan de acción, ya que claramente hay evidencia de que la incidencia todavía sigue existiendo a fecha de auditoría. Si no se dispone de casos para poder comparar, el auditor puede simplemente comprobar que la supervisión ha incluido un adecuado seguimiento de las incidencias, validando que se hayan solucionado de forma adecuada en un tiempo razonable. Guía de controles generales de sistemas de información Página 25

26 Controles del área de DESARROLLO PD1 Gestión de cambios La Organización ha establecido controles para garantizar que los cambios/desarrollos realizados sobre los sistemas son aprobados por los responsables del departamento al que va dirigido la modificación y probados antes de ser puestos en producción. RIESGO ASOCIADO Que se puedan realizar desarrollos no aprobados por los responsables adecuados o no probados adecuadamente puede conllevar que la organización tenga en sus sistemas aplicaciones potencialmente peligrosas desde dos puntos de vista: Aplicaciones fraudulentas, como por ejemplo, una aplicación que permita llevarse un céntimo de cada transacción contable a una cuenta específica de un usuario. Aplicaciones erróneas, como por ejemplo, una aplicación que, aunque se haya ideado con la mejor intención, bloquea todo el sistema e impide realizar el cierre contable mensual. PRUEBA DE DISEÑO En primer lugar, se debe preguntar por si hay una metodología de desarrollo. Una metodología de desarrollo es un procedimiento específico del área de sistemas que describe y detalla el proceso a seguir cuando se desea modificar o mejorar las aplicaciones de la organización. Este proceso suele contener las siguientes fases: Toma de requerimientos de usuario. Evaluación, priorización del proyecto, asignación de recursos y estudio de viabilidad. Análisis funcional y técnico. Pruebas a realizar (especialmente las pruebas de usuario) Procedimiento para poner la aplicación o cambio al alcance de todos los usuarios. Procedimiento de supervisión de que la aplicación o cambio funciona correctamente. Si no hay una metodología formal establecida, puede haber procedimientos concretos que cubran parte de los requerimientos mencionados anteriormente. Preguntar al responsable de sistemas si todas las aplicaciones o cambios han sido solicitados y aprobados por el usuario responsable (por ejemplo, el cambio asociado a la aplicación del IVA del 16% al 18% debía ser aprobado por el responsable de contabilidad) Preguntar también si las nuevas aplicaciones o cambios son probados por el área de sistemas antes de ponerlos en el entorno real (al alcance de todos los usuarios), y especialmente si son probados por el usuario que solicitó el cambio. Guía de controles generales de sistemas de información Página 26

27 Todos los cambios y modificaciones deberían ser solicitados y aprobados por su responsable correspondiente. No tiene sentido que el responsable de sistemas solicite la modificación del IVA que comentábamos anteriormente. El área de sistemas debe dar soporte, proponer soluciones, pero el último responsable de las modificaciones sobre los procesos de negocio es el responsable del área de negocio. En ocasiones puede no haber una aprobación formal, sino simplemente un mail o una llamada telefónica. El auditor debe validar especialmente que el responsable de negocio (en el ejemplo del IVA sería contabilidad) se haga responsable de dichos cambios. Lo mismo ocurre con la realización de pruebas ANTES de que la aplicación se ponga en el entorno real (al alcance de todos los usuarios). El objetivo de las pruebas es evitar que la aplicación o cambio sea perjudicial para lo que ya está funcionando bien en la organización, así como asegurar que cumple los requisitos que se pidieron de ella (con pruebas de usuario) Las pruebas pueden no documentarse formalmente, pero deberían ejecutarse. PRUEBA DE EFICACIA OPERATIVA Solicitar al responsable de sistemas un listado de todos los cambios y aplicaciones del período auditado. Si no se dispone de dicho listado, preguntar a los responsables de las áreas de negocio por las actualizaciones relevantes más importantes. No todos los cambios o aplicaciones son igual de importantes, de forma que el auditor deberá realizar un muestreo y seleccionar aquellas que considere que tienen mayor impacto en las cuentas anuales, sobre procesos de negocio (ventas, compras, etc ) o sobre información confidencial (RRHH). Sobre dicha muestra, el auditor debe solicitar la documentación disponible sobre la solicitud del cambio, la aprobación del desarrollo o cambio (no todas las peticiones de usuario son aprobadas, algunas pueden ser inviables) y las pruebas realizadas sobre el mismo. Se debe adjuntar como evidencia toda la documentación recibida y solicitar justificación de aquellos casos en que no se disponga. Es posible que los cambios o desarrollos seleccionados no dispongan de algunas de las características solicitadas (solicitud, aprobación o pruebas). En estos casos, es aconsejable determinar si estos hechos incumplen la normativa establecida en el apartado de diseño (metodología formal o procedimientos). Independientemente de ello, el auditor deberá determinar la importancia de las carencias detectadas. Es posible que se hayan realizado pruebas pero no quede documentación. Es posible que se haya aprobado el desarrollo pero no quede constancia. Al margen del defecto de forma, se recomienda que el auditor pregunte al usuario responsable de la aplicación (en el caso de nuestro ejemplo con el responsable de contabilidad) sobre si el cambio o desarrollo se implementó a tiempo y cumple con las expectativas generadas. Guía de controles generales de sistemas de información Página 27