Procedimientos
Se realizó el procedimiento de recolección de información utilizando como principal instrumento de investigación una lista de cotejo para evaluar los controles de seguridad de las bases de datos Oracle y Microsoft SQL Server del Banco Falabella (lista de cotejo en anexo 1).
Como complemente al instrumento de investigación, se adoptó como parte del procedimiento de implementación de líneas base el ciclo de Deming de mejora continua para cumplir los objetivos que rigen la Superintendencia de Banca, Seguros y AFP (SBS):
Figura 4: Ciclo de Deming. Fuente: Elaboración propia
Adicionalmente, se muestra el flujo de proceso para la aplicación de controles de seguridad de Oracle y Microsoft SQL Server:
37
Figura 5. Flujo de proceso para la aplicación de líneas base. Fuente: Elaboración propia
Método de análisis
Para obtener la confiabilidad de los datos hallados a través de la lista de cotejo
correspondiente, se hizo uso del software estadístico “SPSS versión 22”. Los datos fueron ingresados en el software para realizar el cálculo del coeficiente de KR-20 (Kuder-Richardson).
38
Figura 6. Elementos de la lista de cotejo para la evaluación de lineamientos base de seguridad de base de datos Oracle. Fuente: SPSS Versión 22
Luego procedimos ingresar los datos obtenidos en la lista de cotejo correspondiente a lineamientos base de seguridad de Oracle:
Figura 7. Ingreso de resultados de la lista de cotejo aplicada a la seguridad de Oracle. Fuente: SPSS Versión 22 Para el caso puntual del coeficiente de confiabilidad vinculado a la homogeneidad o consistencia interna, se dispone del coeficiente (alpha), propuesto por Lee J. Cronbach (1916- 2001) en el año 1951. Se ha demostrado que el coeficiente de Cronbach representa una generalización de las fórmulas KR-20 y KR-21 de consistencia interna, desarrolladas en 1937
39
por Kuder y Richardson (Kerlin249 Confiabilidad y coeficiente Alpha de Cronbach ger y Lee, 2002).
En base a la teoría expuesta en el párrafo anterior, se procede a calcular el coeficiente de Cronbatch:
Figura 8. Coeficiente de Alfa de Cronbach Fuente: SPSS Versión 22
Se procedió a realizar el mismo procedimiento para el cálculo del coeficiente de Alfa de Cronbach con respecto a los resultados de la lista de cotejo aplicada a la seguridad de base de datos Microsoft SQL Server:
40
Microsoft SQL Server. Fuente: SPSS Versión 22
Figura 10. Ingreso de resultados de la lista de cotejo aplicada a la seguridad de base de datos Microsoft SQL Server. Fuente: SPSS Versión 22
Figura 11. Coeficiente de Alfa de Cronbach. Fuente: SPSS Versión 22
Los resultados obtenidos para la confiabilidad de los datos de la lista de cotejo de la seguridad de base de datos Oracle fue de 0.784 y con respecto a la lista de cotejo de la seguridad de base de datos Microsoft SQL Server fue de 0.722. Para ambos resultados se considera valores aceptables asegurando una consistencia de los resultados correspondientes previamente hallados.
41
Coeficiente Alfa > .9 → Bueno Coeficiente Alfa > .7 → Aceptable Coeficiente Alfa > .6 → Cuestionable Coeficiente Alfa > .5 → Pobre
Coeficiente Alfa < .5 → Inaceptable
RESULTADOS
La evaluación de lineamientos base de seguridad de base de datos fue realizada bajo las siguientes configuraciones de seguridad prioritarios:
Oracle:
A- Instalación y parches
B- Seguridad de la red de Oracle – Listener
C- Políticas y procedimientos de auditoria de base de datos D- Configuración de seguridad de parámetros de instancia E- Restricciones de inicio de sesión
F- Restricciones de acceso
Microsoft SQL Server:
A- Instalación y parches
B- Reducción del área de superficie C- Autenticación y autorización D- Políticas de contraseña E- Auditoria y registro
42
Los resultados de la evaluación han sido clasificados de acuerdo con el siguiente criterio:
Tabla 6
Criterio de evaluación
Resultado Descripción
Implementado
Configuración de seguridad completamente implementado en el grupo de base de datos de acuerdo con el estándar correspondiente de CIS Security Benchmarks.
No implementado
Configuración de seguridad no implementado en el grupo de base de datos de acuerdo con el estándar correspondiente de CIS Security Benchmarks.
Nota. Fuente: Elaboración propia
Tabla 7
Resultados de evaluación de configuraciones de seguridad de base de datos
Base de
datos Motor Versión Plataforma Implementado
No
implementado Total
PIFPR Oracle 10.2.0.4.0 Unix AIX 26 10 36
P11001 Oracle 12.1.0.2.0 Linux Red Hat 31 5 36
EXTRANET Oracle 11.2.0.3.0 Linux Red Hat 30 6 36
CMR206 Microsoft SQL Server 2000 Windows 2008 EE SP2 10 9 19 SVR92088 Microsoft SQL Server 2005 Windows 2003 EE SP2 13 6 19 SVR0418 Microsoft SQL Server 2008 Windows 2008 ES SP1 15 4 19
43
Figura 12. Gráfico de resultados de configuraciones de seguridad de PIFPR. Fuente: Elaboración propia
Interpretación de resultados:
PIFPR, base de datos Oracle versión 10.2.0.4.0 se encuentra bajo una infraestructura Oracle RAC 10g (Real Application Cluster) sobre una plataforma Unix AIX. El 72 % de controles de seguridad fueron aplicados satisfactoriamente mientras que el 28 % de controles no fueron aplicados debido al siguiente sustento:
- Ítem 1.1 (actualización de Oracle): Por políticas del negocio, no se realizará upgrade a la versión más reciente ya que no forma parte del alcance de aplicación de líneas base. - Ítem 2.3 (SECURE_CONTROL), 2.4 (SECURE_REGISTER), 4.8
(SEC_CASE_SENSITIVE_LOGON) y 4.9 (SEC_MAX_FAILED_LOGINATTEMPTS): parámetro no disponible para la versión 10.2.0.4.0.
- Todos los ítems de la sección 5 (Restricciones de inicio de sesión):el área de seguridad de la información del Banco Falabella tiene que evaluar los perfiles candidatos a la aplicación de los controles correspondientes.
44
Figura 13. Gráfico de resultados de configuraciones de seguridad de EXTRANET. Fuente: Elaboración propia
Interpretación de resultados:
EXTRANET, base de datos Oracle versión 11.2.0.3.0 se encuentra bajo una sobre una plataforma Linux Red Hat. El 83 % de controles de seguridad fueron aplicados satisfactoriamente mientras que el 17 % de controles no fueron aplicados debido al siguiente sustento:
- Ítem 1.1 (actualización de Oracle): Por políticas del negocio, no se realizará upgrade a la versión más reciente ya que no forma parte del alcance de aplicación de líneas base. - Todos los ítems de la sección 5 (Restricciones de inicio de sesión):el área de seguridad
de la información del Banco Falabella tiene que evaluar los perfiles candidatos a la aplicación de los controles correspondientes.
Figura 14. Gráfico de resultados de configuraciones de seguridad de P11001. Fuente: Elaboración propia
Interpretación de resultados:
P11001, base de datos Oracle versión 12.1.0.2.0 se encuentra bajo una sobre una plataforma Linux Red Hat. El 86 % de controles de seguridad fueron aplicados satisfactoriamente mientras que el 14 % de controles no fueron aplicados debido al siguiente sustento:
45
- Todos los ítems de la sección 5 (Restricciones de inicio de sesión):el área de seguridad de la información del Banco Falabella tiene que evaluar los perfiles candidatos a la aplicación de los controles correspondientes.
Figura 15. Gráfico de resultados de configuraciones de seguridad de CMR206. Fuente: Elaboración propia
Interpretación de resultados:
CMR206, servidor SQL Server 2000 donde residen las bases de datos DMCANALES, DMCMR, DWREPORTS y ODSBF sobre una plataforma Windows 2008 EE SP2. El 53 % de controles de seguridad fueron aplicados satisfactoriamente mientras que el 47 % de controles no fueron aplicados debido al siguiente sustento:
- Ítem 1.1 (actualización del sistema): Por políticas del negocio, no se aplicará parches a versiones sin soporte ni realizar upgrade ya que no forma parte del alcance de aplicación de líneas base.
- Ítem 2.1 (AD HOC DISTRIBUTED QUERIES), 2.2 (COMMON LANGUAGE RUNTIME), 2.3 (DEDICATED ADMIN CONNECTION), 2.5 (TRUSTWORTHY), 4.2 (Caducidad de la contraseña), 4.3 (Complejidad de la contraseña): parámetro no disponible para la versión 2000 de SQL Server.
- ítem 2.7 (puertos no estándar): se mantuvo el puerto estándar 1433, el cambio de puerto impactaría las conexiones de todas las aplicaciones.
- ítem 3.1 (Autenticación SQL Server): no fue posible cambiar la autenticación a Windows Only ya que impactaría las conexiones que no cuenten con un usuario de dominio Windows (SQL Server Authentication).
46
Figura 16. Gráfico de resultados de configuraciones de seguridad de SVR92088. Fuente: Elaboración propia
Interpretación de resultados:
SVR92088, servidor SQL Server 2005 donde reside la base de datos CREDITOVENCPR sobre una plataforma Windows 2003 EE SP2. El 68 % de controles de seguridad fueron aplicados satisfactoriamente mientras que el 32 % de controles no fueron aplicados debido al siguiente sustento:
- Ítem 1.1 (actualización del sistema): Por políticas del negocio, no se aplicará parches a versiones sin soporte ni realizar upgrade ya que no forma parte del alcance de aplicación de líneas base.
- ítem 1.2 (servidor dedicado): se observó que se encontraba instalado el cliente Oracle 9.2; sin embargo, no se desinstalo ya que el servidor SQL Server cuenta con link servers conectándose a bases de datos remotas Oracle.
- ítem 2.7 (puertos no estándar): se mantuvo el puerto estándar 1433, el cambio de puerto impactaría las conexiones de todas las aplicaciones.
- ítem 3.1 (Autenticación SQL Server): no fue posible cambiar la autenticación a Windows Only ya que impactaría las conexiones que no cuenten con un usuario de dominio Windows (SQL Server Authentication).
- ítem 4.2 (Caducidad de la contraseña): no fue posible aplicar el control ya que forzaría la indisponibilidad de los procesos cada cierto tiempo por el cambio de contraseña para los usuarios de aplicación.
- ítem 4.3 (Complejidad de la contraseña): no fue posible aplicar el control ya que ocasionaría errores de autenticación a todos los procesos que se conecten a la base de datos.
47
Figura 17. Gráfico de resultados de configuraciones de seguridad de SVR0418. Fuente: Elaboración propia Interpretación de resultados:
SVR0418, servidor SQL Server 2008 donde reside la base de datos SX_BCOFALABELLA_PERU_PAC sobre una plataforma Windows 2008 ES SP1. El 79 % de controles de seguridad fueron aplicados satisfactoriamente mientras que el 21 % de controles no fueron aplicados debido al siguiente sustento:
- ítem 2.7 (puertos no estándar): se mantuvo el puerto estándar 1433, el cambio de puerto impactaría las conexiones de todas las aplicaciones.
- ítem 3.1 (Autenticación SQL Server): no fue posible cambiar la autenticación a Windows Only ya que impactaría las conexiones que no cuenten con un usuario de dominio Windows (SQL Server Authentication).
- ítem 4.2 (Caducidad de la contraseña): no fue posible aplicar el control ya que forzaría la indisponibilidad de los procesos cada cierto tiempo por el cambio de contraseña para los usuarios de aplicación.
- ítem 4.3 (Complejidad de la contraseña): no fue posible aplicar el control ya que ocasionaría errores de autenticación a todos los procesos que se conecten a la base de datos.
48
DISCUSIÓN
Dentro de las conclusiones de Encalada (2015) en su tesis de maestría “Guía de auditoria para la evaluación del control interno de seguridad de la información en la universidad católica de Cuenca basada en Cobit 5” señala que con la guía de auditoria se pudieron identificar oportunidades de mejora y se determinaron iniciativas de seguridad de la información. Así mismo, indica que, como resultado de la aplicación de la guía de auditoria, la universidad católica de Cuenca cuenta con un diagnóstico de control interno con sus respectivas recomendaciones bajo el criterio de Cobit 5 que aportarán a mejorar la seguridad de la información. Ambas tesis se centran bajo marcos internacionales reconocidos como buenas prácticas para el control de la seguridad de la información. El presente trabajo será de aporte para tener un modelo eficaz de controles de seguridad de base de datos bajo los estándares internacionales de buenas prácticas.
En el trabajo realizado por Gómez (2013) en el trabajo de investigación “Metodología para la realización de una auditoria a la seguridad de las bases de datos” señala que se concluyó satisfactoriamente la elaboración de una metodología o esquema de gestión de auditoria que cubre los elementos relevantes en materia de seguridad física y lógica aplicables a las bases de datos como un medio de orientar y facilitar la labor del auditor de tecnología de la información. El trabajo presente, al haber usado como principal instrumento de investigación una lista de cotejo para le evaluación de lineamientos base de seguridad de base de datos, aporta como metodología para poder auditar la seguridad de las bases de datos bajo los estándares globales de buenas prácticas establecidos por CIS Security Benchmarks.
En el trabajo realizado por Soto (2013) en el informe de suficiencia “Implementación de una solución de auditoria y seguridad de base de datos en una entidad financiera” señala que la implementación de una solución para la auditoria y seguridad permitió obtener la autorización de la Superintendencia de Banca, Seguros y AFP para la utilización del método estándar alternativo lo que permitió tener una reducción importante en los requerimientos de patrimonio efectivo. Ambos trabajos tienen objetivos puntuales de estar alineado con las necesidades del negocio bajo regímenes específicos de entes reguladores; por lo tanto, para el caso presentado del trabajo de investigación, la organización tiene la necesidad de estar alineado a lo que rige la SBS y por ende al cumplimiento permanente de las normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS).
49
CONCLUSIONES
Concluido el estudio realizado de la aplicación de lineamientos base de seguridad de base de datos Oracle y Microsoft SQL Server en la entidad bancaria correspondiente, se concluyó satisfactoriamente la elaboración de una metodología o esquema de configuraciones de seguridad de base de datos aplicables a las diferentes versiones como un medio para orientar a las empresas que se vean en la necesidad de incrementar el nivel de seguridad y facilitar una labor de auditoria correspondiente.
Se elaboró un marco conceptual para cada configuración de seguridad expuesta en una lista de cotejo que permite al encargado de aplicar los lineamientos conocer en primera instancia los conceptos básicos y fundamento del cambio a realizar. Este marco conceptual, es un medio de consulta rápido para el auditor o administrador de base de datos.
Es importante resaltar que todos los cambios hechos en las plataformas de bases de datos correspondientes han sido aplicados en primera instancia en ambientes de desarrollo y calidad para luego ser aplicados en ambientes de producción. Cada control de seguridad debe tener su procedimiento de reversa en caso sea necesario por afectación a las aplicaciones.
Todas las configuraciones aplicadas están bajo los criterios de las mejores prácticas establecidas por Center for Internet Security (CIS); sin embargo, es importante concientizar al personal de la organización sobre la importancia de la seguridad de la información.
Es importante resaltar que las recomendaciones acerca de las configuraciones de seguridad de base de datos no necesariamente deben representar la única solución a implementar ya que existen soluciones alternas que demandan menos tiempo.
RECOMENDACIONES
Es recomendable que los lineamientos de seguridad de base de datos expuestos en el presente documento sean puestos en práctica de manera integral por todas las empresas, es importante que se documente los resultados obtenidos antes y después de la aplicación de controles para facilitar el análisis, ajuste y mejoras de la metodología.
El análisis de impacto es fundamental para los controles correspondientes, no todos los controles en su totalidad serán viables aplicar. Se debe analizar el impacto a nivel de funcionalidad de la aplicación y disponibilidad de servicio; por lo tanto, para certificar los cambios a realizar deben pasar en primera instancia por un ambiente de desarrollo para luego ser
50
certificado por al ambiente de calidad. Con la metodología descrita reduciremos el impacto negativo en la indisponibilidad de servicios y alteraciones en la funcionalidad de las aplicaciones.
Es necesario que el proceso de aplicación y control de líneas base sea constante; por lo tanto, es importante que todos los componentes del entorno cumplan con los estándares de seguridad en todo momento, hay que controlar que las nuevas bases de datos a crear cuenten como primera configuración la aplicación de líneas base.
Los estándares de seguridad CIS Benchmarks deben ser aplicados por un especialista de base de datos, es recomendable para evitar una mala configuración de los parámetros correspondientes que impacten en la disponibilidad de servicio.
51
REFERENCIAS
Aragón A. (2016). Implementación de controles de seguridad en activos informáticos (Tesis de maestría). Recuperada de http://148.204.210.201/tesis/1457540416192TesisAlejandroA.pdf
BIS (2016). Sobre BIS. Recuperada de http://www.bsigroup.com/es-ES/Sobre-BSI/
Center for Internet Security (2015). Oracle Database 11g R2 Benchmark V 2.2. Recuperada de https://www.cisecurity.org/benchmark/oracle_database/
Center for Internet Security (2017). Oracle Database 12c Benchmark V 1.0. Recuperada de https://www.cisecurity.org/benchmark/oracle_database/
Center for Internet Security (2016). Microsoft SQL Server 2012. Recuperada de https://www.cisecurity.org/benchmark/microsoft_sql_server/
Cobit 5 (2012). Cobit 5 y la seguridad de la información. Recuperada de http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx
Encalada (2015). Guía de auditoria para la evaluación del control interno de seguridad de la informaciónen la Universidad Católica de Cuenca basada en Cobit 5 (Tesis de maestría). Recuperada del repositorio Institucional de la Universidad de las Fuerzas Armadas ESPE de http://repositorio.espe.edu.ec/xmlui/bitstream/handle/21000/11578/T-ESPE-
049537.pdf?sequence=1&isAllowed=y
Fidias, G. (2012). El proyecto de investigación (6ta edición).
Gómez (2013). Metodología para la realización de una auditoria a la seguridad de las bases de datos (Tesis de maestría). Recuperada del repositorio Institucional de la Universidad de Costa Rica de
http://www.kerwa.ucr.ac.cr/bitstream/handle/10669/27819/PROYECTO_FINAL.pdf?sequence=1 &isAllowed=y
Hernández Et. Al. (2010). Metodología de la investigación (5ta edición).
Hernández Sampieri (2014). Metodología de la investigación (6ta edición).
HHS (2016). Office for Civil Rights - Health Information Privacy. Recuperada de http://www.hhs.gov/hipaa/index.html
52
ISACA (2019). Hardening. Recuperada de
https://www.isaca.org/Pages/Glossary.aspx?tid=2195&char=S
ISO 27000 (2016). El portal de ISO 27000 en español. Recuperada de http://www.iso27000.es/iso27000.html
Microsoft SQL Server (2017). Información general sobre la seguridad de SQL Server.
Recuperada de https://docs.microsoft.com/es-es/dotnet/framework/data/adonet/sql/overview-of- sql-server-security
Oracle (2011). Seguridad y cumplimiento rentable de Oracle Database. Recuperada de
https://www.oracle.com/technetwork/es/database/enterprise-edition/documentation/seguridad-y- cumplimiento-11gr2-2247594-esa.pdf
Orellana (2015). Elaboración del hardening de una base de datos SQL Server en una empresa procesadora de tarjetas de crédito (Tesis de maestría). Recuperada del repositorio Dspace de http://www.dspace.espol.edu.ec/xmlui/handle/123456789/31507
PCI Security Standards Council (2016). Normas de seguridad de datos PCI. Recuperada de https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2es-LA.pdf
SBS (2013). 6523-2013 Reglamento de tarjetas de crédito y débito. Recuperada de https://intranet2.sbs.gob.pe/dv_int_cn/718/v3.0/Adjuntos/6523-2013.pdf
Soto (2013). Implementación de una solución de auditoria y seguridad de base de datos en una entidad financiera (Tesis de pregrado). Recuperada de
53
ANEXOS
ANEXO 01 – LISTA DE COTEJO PARA LA EVALUACIÓN