Español | English
rss facebook linkedin Twitter

Regulaciones, estándares, controles y procedimientos

Cuando se habla de seguridad de los sistemas de información, podemos hacerlo desde dos puntos de vista muy distintos. Seguro que muchos de nosotros podríamos dedicar horas enteras a discutir sobre temas tan apasionantes como la criptografía asimétrica, los antivirus, los cortafuegos, el phishing, el SPAM, la seguridad Wifi, las vulnerabilidades de XSS, etc. Sin embargo, no es menos cierto que a una alta proporción también les aburre oír hablar de conceptos como gobierno de la seguridad, conformidad, gestión de riesgos, regulaciones, estándares y marcos de control, políticas, procedimientos de seguridad, etc. Parece que estos términos están reservados únicamente a consultores y directivos. Sin embargo, en mi opinión creo que resultan un mal necesario; quien los conoce adquiere una visión global de la seguridad de la información, y además nos proporcionan herramientas y conocimientos para transmitir el verdadero valor de ésta, algo esencial cuando se quiere vender seguridad.

Estoy seguro de que tanto quienes hayan quedado convencidos con los argumentos anteriores, como quienes seguís pensando que todo esto no deja de ser un rollo macabeo, más tarde o más temprano os enfrentaréis a estos conceptos, especialmente si os dedicáis profesionalmente a la seguridad. Ya a nivel personal, he de decir que me ha tocado lidiar con ellos y en muchos casos considero que pueden además llegar a ser ambiguos y confusos. Por eso creo que puede ser interesante poner mi granito de arena y explicar lo mejor que sé alguno de ellos. En este caso, el post va a ir de lo que ya adelanta el título: regulaciones, estándares, controles, políticas y procedimientos.

Últimamente está de moda la palabra inglesa compliance, que en castellano se traduce normalmente por conformidad. La conformidad básicamente consiste en ser fiel a y cumplir con un estándar o regulación, y además poder demostrar este cumplimiento. Pero, ¿qué es un estándar y qué es una regulación? ¿Son lo mismo, existen diferencias, quién los define?

El concepto de regulación, que normalmente se traduce del inglés regulation, hace referencia en general al control mediante reglas y/o restricciones. Son ejemplos de regulaciones las leyes impulsadas por un gobierno, las normas de conducta de la sociedad, o el propio mercado (actividad de los agentes económicos). Particularizando al mundo de la seguridad de los sistemas de información, las regulaciones pueden ser leyes relacionadas con este ámbito como es el caso de la LOPD o la LSSI en España, o la Sarbanes-Oxley Act (SOX) en los Estados Unidos de Norteamérica. También pueden ser regulaciones los mandatos que puedan ser emitidos por un grupo o asociación de empresas dentro de un sector de actividad económico. Un ejemplo de este caso es la Payment Card Industry (PCI), responsable de regulaciones de seguridad que afectan a cualquier empresa que procese, guarde o envíe datos del titular de una tarjeta de pago. Esta asociación fue fundada por American Express, Discover Financial Services, JCB, MasterCard Worldwide, y Visa International.

Las regulaciones son poco específicas en general y no entran en los detalles de qué es lo que se debe hacer exactamente. Por ejemplo, en el artículo 9 del Título II de la LOPD enuncia lo siguiente:

"El responsable del fichero, […], deberán adoptar las medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los datos de carácter personal y eviten su alteración, pérdida, tratamiento o acceso no autorizado, […]"

Es necesario por tanto algo que ayude a cumplir con las regulaciones y que proporcione unas pautas de cómo hacerlo. Este algo se conoce en el argot por estándar o marco de control, resultado de una traducción literal de los términos en inglés standard y framework. Ambos términos suelen utilizarse indistintamente. Los estándares y marcos de control definen los objetivos de control, es decir, las pautas a seguir para alcanzar los objetivos de una regulación. Un ejemplo de objetivo de control puede ser el AC-19 del NIST 800-53, que indica, entre otras cosas que:

"La organización ha de establecer restricciones en el uso de todos los dispositivos móviles (portátiles, móviles, PDA, etc.) bajo su control y debe además dar orientación sobre cómo hacerlo (como por ejemplo, actualizar el sistema antivirus o deshabilitar la conexión wireless)".

Ejemplos de estándares y marcos de control son COSO, COBIT, ISO 27000, ITIL y NIST 800-53.

Una compañía que quiere cumplir los objetivos de control de un estándar o marco de control, lo que hace es desarrollar una batería de controles. Los controles esbozan una manera de afrontar el objetivo de control. Es decir, definen los detalles de cómo conseguir el objetivo de control. Por ejemplo, si el objetivo de control es "revisar las solicitudes de nuevas cuentas de usuario", el control podría ser "las solicitudes de nuevas cuentas de usuario deben ser revisadas y aprobadas antes de que se cree la cuenta correspondiente, de tal manera que se asegure que solo los usuarios autorizados tienen acceso a los sistemas críticos". Es importante destacar que los controles no definen la implementación técnica, pero sirven a un auditor para verificar si se satisface el objetivo de control.

La batería de controles antes mencionada no solo tiene el objetivo de cumplir con los objetivos de control de un estándar o marco de control, sino que también busca satisfacer aquellos objetivos de seguridad específicos que la empresa está interesada en alcanzar, y que no están cubiertos explícitamente por el estándar al que se acoge. Estos objetivos suelen formar parte del plan de seguridad de la compañía.

Los controles, una vez definidos han de ser implementados, monitorizados y si es caso, actualizados. Esto se hace a través de las políticas y los procedimientos. Como ya se ha mencionado anteriormente, los controles no definen cómo ha de ser la implementación técnica. De esto se encargan las políticas, documentos que describen con un alto grado de detalle este aspecto. Los procedimientos son documentos que complementan a las políticas indicando por ejemplo los responsables, los pasos y demás aspectos que ayudan a poner en marcha lo que se indica en las mismas.

Para terminar, veamos un ejemplo completo de lo explicado anteriormente. Permitidme la pequeña licencia de introducir aquí el tema de la seguridad de los sistemas SCADA.

Imaginemos una empresa de gas que se propone como objetivo de seguridad específico reducir el riesgo de accesos no autorizados a sus redes de control, donde se realiza el control de supervisión y la monitorización del estado de los gaseoductos. Existen multitud de controles que pueden ayudar a lograr este objetivo: establecer un sistema de control de accesos físico de doble factor a cada centro de control, deshabilitar la conexión a Internet de cada centro (si ésta existe), etc. Centrémonos en uno particular: la segregación adecuada de la red de control de la red corporativa. La política en este caso podría estipular que ha de emplearse un cortafuegos que aísle ambas zonas, incluyendo la definición de una DMZ en la que residiría el servidor Histórico. Puede incluso entrar en detalles más técnicos como las características del cortafuegos: inspección de paquetes para Modbus, factor de forma adecuado al sector industrial, etc. El documento de procedimiento indicaría que el responsable de llevar a cabo la instalación ha de ser personal de sistemas con la supervisión del ingeniero de control competente. Además podrá indicar la obligatoriedad de cargar, con carácter previo a la instalación, una configuración que establezca como política por defecto ACCEPT ALL, evitando así que durante la implementación del control se interrumpan las comunicaciones y por tanto se garantice la operación 24x7.


Elyoenai Egozcue

S21sec labs


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login