ISACA Journal
Volume 5, 2,017 

Translated Articles 

Auditoría básica de SI: Haciendo más con menos 

Ian Cooke, CISA, CRISC, CGEIT, COBIT Assessor and Implementer, CFE, CPTE, DipFM, ITIL Foundation, Six Sigma Green Belt 

El Instituto de Auditores Internos (IIA) define la auditoría interna como una actividad de aseguramiento y consultoría objetiva e independiente diseñada para agregar valor y mejorar las operaciones de una empresa.1 Sin embargo, en muchas organizaciones, la auditoría interna es percibida como un costo impuesto (necesario) para asegurar el cumplimiento de regulaciones tales como la Ley de Responsabilidad y Transferibilidad de Seguros Médicos (HIPAA en sus siglas en inglés), la Ley Sarbanes-Oxley del 2002, la Directiva de Protección de Datos de la Unión Europea o el Estándar de Seguridad de Datos para la Industria de Tarjetas de Crédito/Débito (PCI DSS). Este enfoque en los costos a menudo hace que se mantenga al mínimo el personal de auditoría. Incluso en empresas con una visión de la auditoria interna más progresista, a menudo no es posible encontrar personas con las habilidades adecuadas. No obstante, se espera que el auditor de TI entienda de tecnologías innovadoras, entienda sobre nuevas regulaciones y asegure una cobertura adecuada al universo de auditoría incluyendo las nuevas aplicaciones. Entonces, ¿cómo puede la auditoría de TI seguir agregando valor? ¿Cómo podemos hacer más con menos?

Establecer un esquema de clasificación de datos

ISACA define la seguridad de la información como algo que “asegura que la información de la empresa esté protegida contra la divulgación a usuarios no autorizados (confidencialidad), a modificación inadecuada (integridad) y el acceso a la información cuando es solicitado (disponibilidad)”.2 Esto, por lo tanto, hace sentido (y de hecho es común) clasificar los datos de acuerdo con estas necesidades. Una guía corta y bien escrita sobre la clasificación de los datos es la Publicación de Estándares de Procesamiento de Información Federal de Estados Unidos3 (FIPS PUB 199 en su sigla en inglés) para la Clasificación de Seguridad de Información Federal y Sistemas de Información. En la figura 1 se muestra un esquema de ejemplo de clasificación de datos.

Clasificar las aplicaciones

El siguiente paso es clasificar las aplicaciones basadas en los datos que ellas procesan. En efecto, se quiere confirmar sí cada sistema procesa datos que son confidenciales o sujetos a reglas de integridad o disponibilidad. La mejor manera de hacer esto es diseñar un cuestionario y preguntarle al dueño del negocio de cada aplicación. Estas preguntas deben ser relevantes para la empresa. En la figura 2 se muestran ejemplos de preguntas.

Los encuestados deben ser advertidos de que para cada pregunta a la que respondan “si”, deben indicar el grado de impacto: alto, medio o bajo. Estas calificaciones, a su vez, deben tener una ponderación numérica. La puntuación global puede ser utilizada para clasificar las aplicaciones (figura 3). Una vez más, las puntuaciones deben ser establecidas sobre la base de las necesidades de la empresa y el número de preguntas.

Al final del proceso, se debe tener una lista de todas las aplicaciones de la empresa, cada una de ellas clasificada como alta, media o baja en términos de confidencialidad, integridad y disponibilidad. Estas clasificaciones deben ser usadas para decidir qué controles aplicar. Cuanto mayor sea la clasificación de la aplicación, más importantes para la empresa son los controles. Por lo tanto, tiene sentido invertir más tiempo protegiendo o, de hecho, auditando estas aplicaciones que aquellas que tienen una menor clasificación. Además, la clasificación establecerá los tipos de controles. Por ejemplo, la aplicación que tenga la clasificación más alta para confidencialidad, puede requerir que se utilice encriptación mientras que una aplicación cuya clasificación más alta sea la disponibilidad puede requerir clústeres o algún tipo de conmutación para cubrir una falla. Por supuesto que es posible también que una aplicación pueda ser clasificada como alta en las tres categorías.

Establecer el criterio

El concepto del criterio se discutió en la columna anterior.4 Para resumir, se define como “criterio” a las normas y referencias utilizadas para medir y presentar el objeto de la materia y contra los cuales un auditor de SI los evaluará.5 Un auditor de TI agregará más valor si el criterio utilizado es el mismo ya establecido por la empresa. Si estas normas aún no han sido definidas, incluyendo el documento que define los controles de línea de base requeridos para todas las aplicaciones—como un “estándar de aplicaciones”, es altamente recomendable auditar las funciones responsables de la segunda línea6 y requerir que ellas sean establecidas tan pronto como sea posible. Este documento debe ser acordado con las funciones de la primera línea y posteriormente revisado por auditoría interna.

Auditar los mismos estándares definidos, además de agregar más valor, también resultará en una menor fricción con los auditados, evitando el viejo argumento de “Nosotros no aplicamos este estándar aquí”. Además, si los auditados están familiarizados con la norma son mucho más propensos a cumplirla.

Realizar una autoevaluación de control basada en los criterios

ISACA define la autoevaluación de controles (CSA) como una evaluación de los controles realizados por el personal de la unidad o las unidades involucradas. Es una técnica de gestión que asegura a los accionistas, clientes y otras partes interesadas, que el sistema de control interno de la organización es confiable.7

Dado que la empresa ahora cuenta con un estándar de aplicación definido, y está buscando aumentar la seguridad proporcionada por la auditoría interna, tiene sentido construir un cuestionario de Autoevaluacíon de Control (CSA) basado en la norma.

CSA debe requerir que el auditado responda preguntas sobre el estándar de aplicación, proporcionando una puntuación porcentual para cada respuesta (cuanto mayor sea la puntuación, más satisfecho estará el entrevistado con el control en cuestión). Además, cada pregunta deberá ser registrada como una línea de base (es decir, todas las aplicaciones requieren esto) o ser relacionadas con la confidencialidad, disponibilidad o integridad.

Esto debería resultar en una lista de aplicaciones con puntuaciones porcentuales para cada una de las áreas de seguridad (figura 4).

Auditar la brecha

La brecha resultante entre un puntaje perfecto (100 por ciento) y el puntaje real puede ser pequeña en términos numéricos, pero podría representar un riesgo significativo para la empresa. Por ejemplo, la Aplicación C puede haber sido clasificada como alta para la confidencialidad, y el 22 por ciento no parece ser una deficiencia excesivamente grande, pero podría representar fallas en controles importantes como el uso de un protocolo de cifrado obsoleto. Por lo tanto, es importante que se evalúe esta brecha. Esto podría ser hecho por auditoría interna realizando una auditoría corta, precisa y enfocada en el (los) control (es) de la pregunta del cuestionario. Las recomendaciones (si las hay) deben ser hechas y hacer el seguimiento8 en la forma tradicional. La confirmación de la implementación de estas recomendaciones debería, por supuesto, resultar en un mayor puntaje la próxima vez que las aplicaciones pasen por el proceso de CSA.

Informar al comité de auditoria

Cuando varias aplicaciones han pasado por el proceso de CSA, una buena práctica sería informar los resultados de éste al comité de auditoría. Esto proporciona transparencia y permite al auditor de TI dar una opinión sobre el ambiente de control general. Además, a medida que el CSA es repetido, las puntuaciones pueden ser rastreadas o seguidas, mostrando puntuaciones mejoradas a medida que los controles son implementados y los riesgos mitigados, o reducir las puntuaciones a medida que aumenta el riesgo emergente.

Auditar anualmente un porcentaje de las aplicaciones

Siempre hay un riesgo en el CSA que los resultados sean inexactos, o que con el tiempo los auditados se vuelvan un poco complacientes. Esto puede repercutir en resultados de un CSA que no sea confiable. Para contrarrestar esto, recomiendo realizar una auditoría completa sobre un porcentaje definido de las aplicaciones sobre una base anual. Esto debería ayudar a mantener un CSA honesto.

Conclusión

La clasificación de las aplicaciones por su confidencialidad, integridad y disponibilidad permite que un auditor de TI asegure que los recursos limitados estén dirigidos a los factores de riesgo adecuados en el momento correcto. Además, la ejecución de los CSA—bajo los criterios acordados, aumenta la cobertura de aseguramiento y ayuda a asegurar que las tres líneas de defensa estén yendo en la misma dirección. Finalmente, el reportar los resultados al comité de auditoría aumentará la transparencia y permitirá que el auditor de TI emita una opinión sobre el ambiente general de control. En conjunto, todos estos elementos agregarán valor real a la empresa.

Nota del autor

El autor desea reconocer a Frank Ennis y Paul Rochford, CISA, CRISC, CISSP, CISSP-ISSAP, por su contribución a muchos de los conceptos utilizados en este artículo.

Notas finales

1 The Institute of Internal Auditors, About Internal Auditing, https://global.theiia.org/about/about-internal-auditing/pages/about-internal-auditing.aspx
2 ISACA, COBIT 5 for Information Security, USA, 2012, p.19, www.isaca.org/COBIT/Pages/Information-Security-Product-Page.aspx
3 National Institute of Standards and Technology Computer Security Division, Standards for Security Categorization of Federal Information and Information Systems, Federal Information Processing Standards (FIPS) Publication 199, USA, February 2004, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf
4 Cooke, I.; “Audit Programs,” ISACA Journal, vol. 4, 2017, www.isaca.org/Journal/archives/Pages/default.aspx
5 ISACA, Information Technology Assurance Framework (ITAF), www.isaca.org/Knowledge-Center/ITAF-IS-Assurance-Audit-/IS-Audit-and-Assurance/Pages/ObjectivesScopeandAuthorityofITAudit.aspx
6 Chartered Institute of Internal Auditors, Governance of Risk: Three lines of Defence, https://www.iia.org.uk/resources/audit-committees/governance-of-risk-three-lines-of-defence/
7 ISACA, CISA Review Manual 26th Edition, USA, 2016
8 Cooke, I.; “Enhancing the Audit Follow-up Process Using COBIT 5,” ISACA Journal, vol. 6, 2016, www.isaca.org/Journal/archives/Pages/default.aspx

Ian Cooke, CISA, CRISC, CGEIT, COBIT Assessor and Implementer, CFE, CPTE, DipFM, ITIL Foundation, Six Sigma Green Belt
Es el gerente de auditoría de TI del grupo de An Post (la Oficina de Correos Irlandesa con sede en Dublín, Irlanda) y tiene 30 años de experiencia en todos los aspectos de los sistemas de información. Cooke ha cooperado en varios comités de ISACA, y es un miembro actual del Grupo de Trabajo de Desarrollo de Elementos para el Examen CGEIT de ISACA. Él es el líder de la comunidad de las Bases de Datos de Oracle y SQL Server, y de las Herramientas y Técnicas de Auditoría en el Centro de Conocimiento de ISACA. Cooke ayudó en las actualizaciones del Manual de Revisión de CISA para las prácticas de trabajo del 2016, y fue un experto en la materia para el Curso de Revisión en Línea de CISA de ISACA. Ha sido galardonado con el Premio Common Body of Knowledge John W. Lainhart IV 2017, por sus contribuciones al desarrollo y mejora de las publicaciones de ISACA y de los módulos de capacitación para la certificación. Cooke acepta comentarios o sugerencias de sus artículos por correo electrónico en Ian_J_Cook@hotmail.com, Twitter (@COOKEI), o en el tópico de Herramientas y Técnicas de Auditoría del Centro de Conocimientos de ISACA. Las opiniones expresadas en esta columna son suyas y no representan necesariamente las opiniones de An Post.

 

Add Comments

Recent Comments

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to the originality of authors’ content.