• Artículo

Archivos del escritorioSeguridad frente a Cumplimiento

Wes Miller

Como profesional de la TI, puede enfrentarse a objetivos que deben complementarse pero que, a menudo, compiten entre sí. La seguridad y el cumplimiento son dos de este tipo de objetivos de la organización, en los que el logro de uno debe mejorar el otro. Sin embargo, esto no es generalmente el caso. Mi intención con este artículo es proporcionarle

información general acerca de por qué la seguridad no siempre significa cumplir con las iniciativas exigidas y de por qué satisfacer el cumplimiento con frecuencia no significa garantizar la seguridad, o por lo menos obtener el nivel de seguridad que debería si el cumplimiento realmente se identificase con la seguridad.

La seguridad no es una casilla

Recursos de SDL

Generalmente, el cumplimiento implica unos requisitos (personas, procesos, infraestructura, tecnología, etc.) que se imponen en una organización, sector, empresa o producto desde fuera. A veces, el cumplimiento tiene que ver con estándares promulgados desde el sector en sí, como por ejemplo, el Payment Card Industry Data Security Standard (PCI-DSS). Idealmente, se trata de iniciativas que se alinean con la manera en que ya funciona la organización, al menos hasta cierto punto. A medida que prolifera la adopción de un estándar, comprueba que ya no puede hacer caso omiso, especialmente, para tener éxito en los negocios. Finalmente, deberá actuar y sacar el mayor partido posible.

Es el otro tipo de cumplimiento que suele causar más problemas. Me refiero a las iniciativas que establece el gobierno, como por ejemplo, Insurance Portability and Accountability Act y Sarbanes-Oxley, donde las decisiones acerca de la implementación y los plazos rara vez se realizan por voluntad propia.

El punto clave que se debe comprender acerca del cumplimiento de las normas es que a menudo implica un enfoque de "arriba hacia abajo". Suele haber una plantilla establecida donde se define la iniciativa, y debe mirar los productos y procesos e intentar averiguar cómo pueden cuadrar con la plantilla predefinida que recibe. Debe ser consciente, además de la intención de la iniciativa de cumplimiento, ya que tal vez sea más importante, de las posibles consecuencias legales o financieras de su no aplicación o de su aplicación incorrecta (si las hay).

Si bien podemos estar de acuerdo con la intención de muchas iniciativas de cumplimiento, la implementación suele ser difícil y puede no satisfacer el objetivo deseado. Además, lamentablemente, muchas de ellas no tienen fuerza (es decir, no hay consecuencias legales o financieras directas que se pueden imponer por la aplicación incorrecta).

Puedo decir que, como paciente médico, no soy capaz de describir completamente la ventaja neta de HIPAA para mí. Lo que sí puedo decir es que hay mucho más papeleo cuando voy a un médico. Incluso puede haber consecuencias involuntarias. ¿Ha intentado alguna vez enviar información médica importante de un médico o agencia a otro? Si no hay permiso por escrito, no podrá hacerlo, independientemente de lo urgente que se necesite la información.

Lo que intento decir es que, en muchos sentidos, algunas iniciativas de cumplimiento se convierten en iniciativas tipo casilla. Es decir, diseña o modifica el proceso o producto solamente para cumplir la iniciativa de cumplimiento. A menudo le pregunto a mi hijo de tres años, ¿crees que eso es una buena idea?"

La seguridad, por otro lado, es una iniciativa ascendente (cuando se realiza correctamente). Independientemente de si diseña un producto de software o la arquitectura para la nueva red de la organización, el concepto clave que debe recordar es "medir dos veces y cortar una". Al diseñar la arquitectura del producto, por ejemplo, del mismo modo que un buen paso inicial describiría la comunicación, la localización, las versiones, etc., también debería describir los elementos de seguridad que se deben generar en la aplicación desde el principio (y que debería seguir investigando y ajustando a lo largo del desarrollo).

Si trabaja con una aplicación o arquitectura heredadas (que seguramente es la mayoría de los casos), es igualmente importante realizar la clase de revisión exhaustiva acerca de la seguridad que, a menudo, menciono en este artículo. Si no comprende el funcionamiento de algún elemento, ¿cómo podría comprender su grado de seguridad? Para obtener más información acerca del ciclo de vida de desarrollo de seguridad (SDL) de Microsoft®, consulte la barra lateral "Recursos de SDL".

Imagen general

Recuerdo que, durante el inicio de mi vida profesional, me enseñaron que la seguridad no significa simplemente la implementación de cifrado, listas de control de acceso (ACL) o TLS, o la infraestructura de claves públicas (PKI). La verdadera seguridad significa comprender el panorama completo: comprender por qué se abandona o, incluso, nunca se admitió una versión específica de un protocolo determinado; por qué un mecanismo nuevo detiene los ataques intermediarios; cómo puede ser la implementación de la segunda versión del producto más segura que la versión 1, incluso si esta última era mucho más rápida. También es necesario comprender cómo encajan todas las piezas de la infraestructura entre sí.

Por otro lado, el cumplimiento implica asegurarse de que la tecnología y la infraestructura creada cumplen determinados criterios. Algunas iniciativas, como por ejemplo, el Payment Card Industry Data Security Standard (PCI-DSS) o el North American Electric Reliability Council (NERC), están bien dirigidas y, probablemente, acabarán impulsando un auténtico cambio en la seguridad. Pero, al final, con el gran número de opciones de "iniciativas de cumplimiento" que deben encajar con los proyectos propios y el número limitado de recursos disponibles, las iniciativas de seguridad pierden terreno.

Hace mucho tiempo que la seguridad es el hijastro del desarrollo de software. Seguramente muchos lectores han formado parte de una organización en la que seguridad era algo que se postergaba continuamente. Bueno, las iniciativas de cumplimiento no desaparecerán porque esa actitud de que la seguridad puede esperar, no funciona y nunca lo hará.

Muy bien

Hace poco, cambié de trabajo. Ahora trabajo para una nueva empresa aquí en Austin, Tejas, que se dedica a crear una tecnología de listas blancas (whitelisting) de aplicaciones similar a la tecnología creada en Winternals con el producto Protection Manager. Una tema de conversación interesante con los clientes es hasta qué punto creen que sus tecnologías actuales son seguras, o bien, más concretamente, qué grado de seguridad creen que tiene el conjunto de tecnologías que usan en su infraestructura. Si bien es muy probable que la mayoría de ellas sean seguras y no tengan vulnerabilidades de seguridad, la conclusión más frecuente y que me da un poco de miedo es que un sistema es "suficientemente seguro".

Las iniciativas de cumplimiento son extrañas, tiene la opción de cumplirlas o no cumplirlas. La responsabilidad cae en sus manos. El costo de no cumplir una iniciativa suele ser una multa, una penalización o la eliminación de una organización. Por lo general, no es suficiente garantizar que las cosas realmente cambian.

En el caso de una iniciativa de mandato nacional, a menudo me encuentro con una actitud del tipo "suficiente como para complacer al auditor" o la voluntad de seguir adelante sin establecer ningún marco de cumplimiento debido a que la legislación aplicable (tal como HIPAA) no financia adecuadamente el cumplimiento; lo que significa que es mucho más económico conducir sin seguro y enfrentarse posteriormente a las consecuencias.

La seguridad suele enfrentarse al mismo obstáculo, pero, en mi opinión, al menos es más concreto. Si, como desarrollador o implementador, indica a la administración que no incluir la sección X en las especificaciones aumentará significativamente la vulnerabilidad del producto, al menos podrá decir tras la entrega del producto o la finalización de la implementación que ya lo había advertido. Con las iniciativas de cumplimiento, mi experiencia es que cumplimiento suele realizarse precipitadamente, con el presupuesto más ajustado posible. El objetivo es simplemente cumplir los requisitos mínimos establecidos por la iniciativa, es decir, cumplir la iniciativa al pie de la letra, pero sin tener en cuenta el espíritu de ésta, en mi opinión.

Establecer la posición

Recursos de seguridad y cumplimiento

Aunque pueda resultar idealista de mi parte decir que debe hacer su producto y su organización lo más seguros posibles, la realidad es que la mayoría de las iniciativas de cumplimiento es un compromiso que procede de una ingeniería inadecuada o, más probablemente, de la autocomplacencia. Vivimos en un mundo en el que "suficientemente bueno" es, lamentablemente, suficientemente bueno. Sin embargo, en el mundo de la seguridad "suficientemente bueno" raramente es recomendable. Los profesionales de la TI de todo el mundo pueden aceptar completamente las iniciativas de cumplimiento e intentar de cumplirlas tanto en espíritu como en implementación. Sin embargo, deben asegurarse de que la infraestructura aplicada no tiene el máximo nivel de seguridad posible, sino el nivel de seguridad que debe tener. Dicho de otro modo, debe cumplir a través de una verdadera seguridad y no solamente estar en conformidad con la iniciativa.

Es importante detenerse y mirar la tecnología que se está creando, tanto si se trata de software comercial o de un conjunto de tecnologías que desee integrar en un sistema de mayor tamaño. Nunca me canso de enfatizar la importancia de comprender las piezas entrelazadas del sistema, cómo funcionan en conjunto y las amenazas más importantes a las que se enfrenta el sistema.

En función del sector en el que trabaje, las diferentes iniciativas de cumplimiento pueden ser importantes para su trabajo. Tal vez se encuentre con ellas en la vida cotidiana o solamente al diseñar nuevos proyectos o tecnologías. O bien, quizás sean sólo una parte del trabajo que realiza durante las revisiones o las auditorías de cumplimiento diseñadas específicamente. Da igual. No creo que las iniciativas de cumplimiento deban pasarse por alto, pero les animo a que desafíen el statu quo y a que, en lugar de trabajar exclusivamente para cumplir las iniciativas de cumplimiento de las que sean responsables, realicen una revisión completa de la seguridad con el fin de comprender totalmente la tecnología y modelarla cuando realicen la revisión de cumplimiento.

No tiene nada que perder.

Al final, los castigos por no cumplir una iniciativa de cumplimiento pueden parecer ambiguos. La falta de cumplimiento puede hacer se produzca la misma situación que intenta evitar la iniciativa. Las consecuencias pueden parecer imprecisas o lejanas, pero son reales. Además, puede no se trate de consecuencias individuales. Debe ser pragmático, pero tenga siempre en cuenta las situaciones más complicadas.

Al mirar el mismo espacio desde el punto de vista de la seguridad, la amenaza resulta evidente y, lo que es más importante, debe ser capaz de identificar inmediatamente el posible costo de dejar la vulnerabilidad abierta.

Muchas personas con las que he hablado acerca de este tema han acentuado el hecho de que las iniciativas de cumplimiento suelen dejarse de lado, ya que, a menudo, dejan mucho a la interpretación. Sin embargo, esto no debería aplicarse a ninguna omisión de seguridad tras haber realizado una revisión de la seguridad. Las amenazas inmediatas de seguridad omitida deben ser claramente visibles. Si no lo son, es recomendable recapacitar acerca de las personas implicadas en las revisiones de seguridad. Puede que no cuente con miembros clave en el equipo que puedan ayudarle a detectar los problemas reales de la solución.

Círculo vicioso

En el artículo del año pasado acerca de la seguridad, hablé acerca de cómo evitar la pérdida de datos (technet.microsoft.com/magazine/cc162325). Un año después, un mayor número de sistemas se han puesto en peligro, se ha perdido un mayor número de equipos portátiles sin cifrar y una mayor cantidad de información personal se ha puesto en manos potencialmente dudosas. Resulta difícil saber si se ha producido algún progreso. ¿Por qué no hemos avanzado? A menudo, los proyectos van con retrasos, tienen presupuestos muy limitados con recursos que no dan más de sí y se intenta ofrecer demasiadas características dentro de un período demasiado corto.

Por desgracia, este tipo de entorno conduce a uno en el que realizar la menor cantidad de trabajo posible se convierte en lo normal. Esa no es la forma de garantizar la seguridad o el cumplimiento de una solución, ni que ésta no afecte negativamente el tiempo o los costos del proyecto.

Personalmente, creo firmemente que

  1. no debería crear una solución si no está dispuesto a garantizar su seguridad.
  2. Cada vez que se agreguen nuevas características, se debe diseñar la seguridad antes de comenzar.
  3. Si la organización no está dispuesta a integrar la seguridad como parte del proceso de ingeniería, debería preguntarse cuáles son los objetivos generales de la empresa u organización.

Las organizaciones tienen cada vez más datos personales acerca de los clientes o socios para los que deben garantizar la seguridad. Es lamentable que vivamos en un mundo en el que, con demasiada frecuencia, la seguridad no es la norma y los empleados no se sienten capaces de cuestionar la dedicación de la organización en cuanto a la seguridad.

El fracaso real de la seguridad (no del cumplimiento) pasa a ser a menudo el desencadenador que indica que ha llegado la hora de proteger el sistema y que el seguro contra el robo de identidad se ha convertido en una táctica estándar de responsabilidad para tranquilizar a clientes, estudiantes, pacientes y empleados cuyos datos personales (y probablemente su bienestar financiero) han entrado en peligro.

A todos se nos exige hacer demasiado, a menudo a cambio de una recompensa muy pequeña y, generalmente, en muy poco tiempo. Pero es nuestra responsabilidad como profesionales de la TI cuestionar por qué la seguridad no es el enfoque clave, por qué, por lo general, la administración sólo se acuerda de la seguridad ante iniciativas de cumplimiento o, lo que es más probable, ante una infracción de la seguridad y sus verdaderas amenazas legales, ya sean reales o potenciales (que podrían desprestigiar a la organización o ponerla en peligro).

Acepte el desafío

Principalmente, les invito a desafiar el statu quo. Si solamente se le solicita que satisfaga los objetivos del cumplimiento, intente asegurarse de que, al hacerlo, no pierde el tiempo en satisfacer el concepto que alguien tiene de seguridad. En lugar de eso, asegúrese de que el objetivo es garantizar la seguridad del sistema y, al mismo tiempo, definir una cantidad suficiente del proceso o de la infraestructura como para satisfacer la iniciativa del cumplimiento. Para obtener más información acerca de este tema, consulte la barra lateral Recursos de seguridad y cumplimiento.

En resumen, recuerde que, por lo general, el cumplimiento no es un camino a la seguridad. No obstante, si se implementa y se instrumenta la seguridad correctamente, a menudo, puede acabar siendo un camino al cumplimiento.

Wes Miller es jefe de productos técnicos senior en CoreTrace (www.CoreTrace.com), con base en Austin, Texas. Anteriormente, trabajó en Winternals Software y como administrador de programas en Microsoft. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.