Llegamos a ustedes gracias a:



Reportajes y análisis

¿Problemas con el cumplimiento de la seguridad?

[29/01/2014] Las reglas destinadas a proteger la seguridad y privacidad de las organizaciones e individuos, son bien intencionadas. Pero a veces, estas reglas, o la manera en la que se interpretan, pueden ser una verdadera molestia -hasta pueden contribuir a hacer que la seguridad sea más débil.
Aquí hay algunos ejemplos -proporcionados por ejecutivos y analistas de la seguridad- de reglas o estándares de cumplimiento internos y externos que son potencialmente problemáticos, y cómo pueden ser abordados para que no causen problemas cuando su finalidad es aportar soluciones.
Cifrado y HIPAA
Muchas organizaciones y ejecutivos de la seguridad tienen la equivocada impresión de que el cumplimiento del Health Insurance Portability and Accountability Act (HIPAA) requiere cifrado, y esto, en realidad, puede conducir a problemas de seguridad, señala Paul Proctor, vicepresidente y analista distinguido de Gartner Inc.
De hecho, HIPPA requiere el uso apropiado del cifrado, que es un estándar bastante diferente y puede significar una diferencia de millones de dólares, agrega Proctor. Aparte del exceso de gasto de tiempo y energía en el cifrado, el malentendido relacionado con HIPAA, puede tener un impacto negativo en ciertos procesos de negocio, afectar el rendimiento de las aplicaciones, e incluso causar que los usuarios pasen por alto ciertos controles, porque les fastidia la seguridad, añade.
Decisiones como el exceso de cifrado de los datos tienden a tener un efecto dominó, del cual la reducción de seguridad es solo uno, anota Proctor. La respuesta es desarrollar un proceso de gestión de riesgos que permita una consideración cuidadosa de lo que debería hacer para cumplir con las regulaciones. Las organizaciones pueden tomar decisiones equivocadas si no tiene un proceso formal de gestión de riesgos -y la mayoría no lo tiene.
Archivos PDF protegidos con contraseña
A veces el entorno regulatorio cuenta con empresas que gastan dinero en herramientas que no son efectivas, y hace que la vida de los clientes sea más complicada. Cuando Tony Hildesheim, ahora vicepresidente senior de TI en Redwood Credit Union, trabajaba en otra organización, las reglas internas ordenaban que la información de las cuentas no podía ser impresa en ningún documento.
Esto también requería que si mandaba información de algún cliente, tenía que estar en un documento PDF protegido por una contraseña, señala Hildesheim.
Esto causó varios problemas. Muchas instituciones financieras truncaron el número de cuenta para que el número completo no fuera impreso en ningún material, comenta Hildesheim. Sin un número de cuenta presente en un pedazo de papel, es difícil ayudar al cliente, muchos de los cuales no se acuerdan su número de cuenta.
La otra cuestión es que con la solución de escaneo del correo electrónico de la compañía, se hacía muy difícil escanear el PDF protegido por una contraseña. Por lo tanto, la medida de seguridad que pusimos en marcha para asegurar que ningún dato [como números de tarjetas de crédito] sea enviado por correo electrónico desde la compañía, se volvió inútil, porque el sistema no pudo entrar a los PDF, comenta Hildesheim. Tuvimos que cambiar el procedimiento, capacitar al personal y luchar contra el departamento de auditoría.
Las regulaciones o reglas son a menudo escritas en respuesta a un riesgo muy específico o percibido que puede existir o ya no existir, que tienen otras mitigaciones o cuya probabilidad es tan remota que no es una amenaza, señala Hildesheim.
Escaneado de virus demasiado entusiasta
Muchos años atrás, Proctor y otro analista de Gartner estaba visitando una gran cooperativa de crédito para discutir una estrategia de seguridad. La firma acababa de experimentar un ataque de virus informático cuando un usuario decidió conectar una computadora infectada a la red corporativa e inadvertidamente propagar el virus.
Así que crearon una regla o norma que decía que cada máquina que entra a la organización desde fuera, tenía que pasar por un análisis completo para ver si tenía virus, comenta Proctor. Esto se hacía en la mesa de seguridad y tomaba dos horas por cada máquina. Cuando llegamos para nuestra reunión, no pudimos entrar por todos los retrasos. La reunión fue cancelada a causa de esta tonta decisión, y quien sabe cuántas piezas del negocio fueron afectadas por esta regla.
Probablemente tuvo un impacto negativo en la situación de la seguridad de la organización por todo el resentimiento hacia la seguridad, anota Proctor. La solución, nuevamente, es pensar detenidamente en cómo los estándares y las normas de cumplimiento deben ser implementadas y su impacto potencial en todos los aspectos del negocio.
Puntuación o clasificación de vulnerabilidad y PCI
El requisito estándar PCI para un escaneo limpio es una carga enorme para las empresas, señala Adrian Sanabria, analista de seguridad senior en 451 Research. Desvía el enfoque de un trabajo más efectivo en la reducción de riesgos, y fomenta una peligrosa falsa sensación de seguridad, agrega. Versiones anteriores de los estándares de seguridad PCI requerían que los negocios demostraran que todas esas vulnerabilidades clasificadas entre la puntuación CVSS 4.0 o más alta podían ser resueltas, añade Sanabria. Este es un proceso muy grande de trabajo intensivo, que da muy poco de seguridad a cambio.
La cuestión clave aquí es la falta de eficacia de la puntuación de la vulnerabilidad, señala Sanabria. La puntuación o calificación automática dada a una vulnerabilidad -siempre y cuando no sea un falso positivo- es a menudo muy inexacta, agrega. Es simplemente la mejor estimación sin un poco de trabajo extra para tener en cuenta el contexto particular de cada organización. La gran mayoría de los esfuerzos se hacen para arreglar las vulnerabilidades que no son una amenaza e ignorar potencialmente aquellas que podrían ser críticas, pero fueron clasificadas bajo el rango en el PCI.
Muchas veces, las organizaciones más grandes tienen una persona que se dedica exclusivamente a coordinar tareas y obtener escaneos limpios, señala Sanabria. Ese es el tiempo de una persona dedicado a una pequeña fracción del PCI, agrega. Las nuevas versiones del PCI han tratado de corregir este problema mediante la implementación de un nuevo requisito en el que cada organización aplica rankings personalizados para cada vulnerabilidad que los afecta. Ahora, estas organizaciones van a tener que hacer que una segunda persona se dedique a la tarea de gestión de las vulnerabilidades.
Las copias de seguridad de los datos cifrados
Un esfuerzo de cumplimiento que hace que una situación difícil sea aún más difícil es el requisito de copias de seguridad cifradas. Hildesheim sabe de compañías que requieren mantener esas copias de seguridad de los datos.
Esto suena como una precaución razonable si está almacenando sus cintas de copias de seguridad en un almacén público, señala Hildesheim. Pero considere que la gestión o dirección y la probabilidad de que en siete años a partir de hoy, el cifrado sea capaz de ser descifrado. No importa que la contraseña o clave tenga que ser almacenada en algún lugar seguro y catalogado. El algoritmo del cifrado o el software, van a tener que estar de tal forma que puedan descifrar los datos.
Esto es aún más confuso cuando los reguladores requieren que las copias de seguridad de los datos sean cifradas, aunque estén almacenadas en una bóveda de almacenamiento controlada a la que solo su empresa tiene acceso, anota Hildesheim. Una de las respuestas que muchos reguladores quieren ver en su lugar son las copias de seguridad electrónicas cifradas, señala. Esto suena bien, hasta que uno se da cuenta que la mayoría están almacenados en un almacenamiento local o de fuera, los cuales se encuentran en un entorno compartido, o nube.
Muchas regulaciones internacionales
Para las compañías que ofrecen sus servicios principalmente a través de la nube, como Saba, proveedor de soluciones de gestión o dirección del talento y aprendizaje, la necesidad de cumplir con una serie de regulaciones federales y de industria, puede crear complejidades que dificultan y entorpecen la seguridad.
Saba cumple con normas como la ISO27001; los requisitos de privacidad como Safe Harbor, EU Directive y otros requisitos geográficos de privacidad; Life Science Validation Environments; FISMA, etc., señala Randy Barr, director de seguridad y de información.
Algunas de estas regulaciones son más estrictas que otras y crean desafíos que son importantes para abordar, con el fin de proporcionar seguridad adecuada, añade Barr.
Por ejemplo, algunos requieren que los empleados trabajen en los Estados Unidos o tengan la ciudadanía americana. Es difícil hacer y mantener un seguimiento de las personas que trabajan fuera, y tener que hacer eso para algunos de los grupos dentro de su compañía puede ser un reto, agrega Barr. Si Saba no estaba preparado para ese tipo de regulaciones, nuestra habilidad o capacidad de proporcionar seguridad en todos los ámbitos, estaría en peligro. Es importante que todos los departamentos se tomen el tiempo de entender los programas de seguridad con los que nos hemos comunicado, en vez de solamente revisar los requisitos de cumplimiento y decir que deben ser cumplidos.
Saba es capaz de cumplir con todos los requisitos de seguridad de los clientes, señala Barr, pero no sin una gran cantidad de esfuerzo adicional, debido a los requisitos de cumplimiento sumamente complejos. Está trabajando con la Cloud Security Alliance para encontrar más maneras efectivas de cumplir con los estándares sin agotar los recursos. Además, ha formado un Saba Security Counsil o consejo de seguridad para proporcionar un foro basado en el consenso para apoyar el programa de seguridad de Saba. Las discusiones sobre el cumplimiento de las regulaciones o de la normativa, son discutidas en estas reuniones trimestrales, señala Barr.
Las regulaciones ISO y Roadblocks
Las regulaciones ISO/IEC 15408 que requieran las pruebas Common Criteria pueden dificultar o entorpecer la seguridad, señala Robert Schadey, CISO y director de los servicios de infraestructura en 1901 Group, un proveedor de servicios de gestión de TI.
Las reglas generales y especificaciones de Common Criteria desarrolladas para la evaluación de la seguridad de un producto, aseguran o garantizan que los estándares de seguridad sean aceptados y las pruebas estén en su lugar, añade Schadey. En la mayoría de los casos, Common Criteria valida los reclamos de las características de seguridad de los vendedores con una evaluación de las amenazas potenciales, agrega.
Sin embargo, la longitud total del tiempo para las pruebas y costos ha provocado un bloqueo u obstrucción de la mayor parte de la industria, señala Schadey. Nuestro enfoque ha cambiado y ahora proporciona un enfoque basado en servicios para nuestros clientes federales. Los servicios son entregados a través de entornos de alojamiento dinámico, por lo que la capa de infraestructura puede no estar bajo el control del cliente.
Esto puede hacer que sea difícil asegurar que la meta o propósito de las medidas de seguridad de Common Criteria estén en su lugar sin analizar la implementación de nube de cada vendedor contra los requisitos funcionales de seguridad (SFR) de Common Critera y sin identificar las brechas de seguridad para determinar si el proveedor de nube es aceptable, añade Schadey.
La pérdida de control en la capa de infraestructura puede causar problemas de seguridad, agrega. La otra cuestión que dificulta la seguridad es el marco de tiempo que toma probar los productos y tenerlos disponibles para que sean seleccionados de la lista de productos de Common Criteria.
Bob Violino, CSO (EE.UU.)