Politicas de seguridad de sistemas informaticos1 kiara osorio
1. ALUMNA: KIARA YERALDINE OSORIO DIOSES POLÍTICAS DE SEGURIDAD PARA SISTEMAS INFORMATICOS . ISTP. CAP. FAP JOSÉ ABELARDO QUIÑONEZ GONZÁLES
2.
3.
4.
5.
6.
7.
8.
Notas del editor
A continuación cito las preguntas que intento responder en esta ponencia. Aclaro que mucho es obvio, quizás sólo le estoy dando otro enfoque.
1. La confidencialidad, ofrece un nivel alto de la confianza de que los datos, los objetos o los recursos no son expuestos a sujetos no autorizados. 2. La integridad es el principio que retienen los objetos, respecto a su veracidad y que sólo son modificados intencionadamente por sujetos autorizados. 3. La disponibilidad es el principio de que a los sujetos autorizados les es concedido el acceso oportuno e ininterrumpido a los objetos. La consecuencia más importante es que la combinación de esta triada es específica para cada contexto, es decir, NO es universal, por ejemplo, para un banco el nivel de secrecía es mayor que para una universidad. A esto se le llaman los requerimientos de seguridad, es decir, siempre es buscar un balance entre apertura y secrecía.
Una política de seguridad es un "enunciado específico sobre lo que está y lo que no está permitido“. Luego entonces, una política de seguridad es una ley, norma o regla dentro del ámbito de competencia de la organización. Lo importante en la elaboración de las políticas de seguridad es quién debe definirlas: el área de negocios o el área de TI. Obviamente, debe ser el área de negocio, pero en conjunto con el área de seguridad de TI. Las políticas de seguridad, siempre deben alinearse de tal forma que el negocio opere con un nivel de seguridad aceptable.
Los mecanismos de seguridad refuerzan el cumplimiento de las políticas de seguridad; su objetivo es asegurar que el sistema o la empresa, nunca pase a un estado de "lo no permitido". Hay dos tipos de mecanismos: técnicos y operativos (a veces llamados procedimientos). Los mecanismos técnicos son aquellos que utilizan la tecnología en hardware, software o una combinación de ambos para reforzar las políticas de seguridad. Un ejemplo de un mecanismo técnico, es la tecnología anti spammer que se usa en los servidores de correo electrónico, que filtra y elimina correos potencialmente amenazantes, de acuerdo a los criterios implantados, pero que también puede elimina mensajes seguros equivocadamente elegidos. Otro ejemplo de mecanismos técnicos son los algoritmos criptográficos que “ensobretan” documentos y vuelven ininteligibles los mensajes y los canales de comunicación a los sujetos no autorizados. Este tipo de mecanismos tiene sus ventajas, limitaciones y su ámbito de aplicación, que debe balancearse lo más apropiadamente al contexto de aplicación. Lo único seguro de los mecanismos técnicos es que no son infalibles, es decir, ninguno es seguro al 100% por sí mismos, mucho menos al combinarse con los mecanismos operativos. Otra causa de falla o de inseguridad de los mecanismos técnicos de seguridad son los errores de programación o vulnerabilidades o exploits, que dicho sea de paso, son muy comunes. Los mecanismos operativos o procedimientos son aquellas políticas que prescriben los pasos, tareas o procedimientos que deben llevarse a cabo para cumplir una política de seguridad. Por ejemplo, la capacitación a todos los niveles de la organización, sobre las medidas de seguridad, dependiendo del rol. Por lo general, los mecanismos técnicos sucumben a los operativos, o mejor dicho, los primeros complementan los segundos. En conclusión, debe buscarse un equilibrio complementario entre los mecanismos disponibles de tal forma que sea como en el refrán que reza que “ni tanto que queme al santo, ni tanto que no lo alumbre”. No quiero que esto desaliente a mis queridos hackers en progreso que asisten y/o se están capacitando en esta conferencia, sino más bien, deseo que se tome conciencia de que, si bien la seguridad es algo que “ni debe ignorarse”, “ni tomarse a la ligera”, no existe un mecanismo, metodología, procedimiento o tecnología que permita mantener los recursos informáticos, seguros al cien por ciento.
Hay evidencias constantes de que, d e manera universal, las políticas organizacionales y las de seguridad, como un caso de éstas, se violan "a conveniencia" en distintos grados, prácticamente en todos los niveles jerárquicos, y en todas las organizaciones, sean éstas públicas o privadas. Por ejemplo, cuando, por aplicar una política informática, el correo gratuito del director es inaccesible y éste toma el teléfono y le ordena a su jefe de sistemas que le permitan usar su correo gratuito, o que le dejen ver sus películas porno, algo nada raro. Además, recuérdese que “el jefe siempre tiene la razón” (y el profe igual). Obviamente, nunca va a haber un oficio, un memo o alguna otra evidencia que haga constancia de la orden y que demuestre que la política de seguridad ha sido deliberadamente violada. Otro caso, en otro ámbito es cuando ¿un profesor promete regalar calificación a cambio del silencio de sus alumnos ante sus faltas y deficiencias académicas? Otro ejemplo que me gusta emplear, por lo ilustrativo, es el comportamiento del señor Waternoose, personaje de la película Monsters Inc que engaña a algunos de sus empleados y se confabula con otros para violar las políticas organizacionales, por sus intereses personales en claro detrimento de la empresa. Este fenómeno, que a todas luces, es una falla de las políticas de seguridad, es una causa organizacional en sentido estricto, es decir, es una propiedad organizacional intrínseca a la organización o a la empresa como sistema social o socio-técnico (cómo se le quiera ver) y no debiera verse como un problema de mal comportamiento de los individuos. Este comportamiento organizacional debe distinguirse de la violación deliberada e intencionalmente dañina de sabotaje o resistencia. Aclarando, ¿por qué argumento que es una causa organizacional? Porque seguramente hay aspectos del negocio que no se pueden cubrir con los recursos de la empresa. Obviamente, los caprichos personales saldrían de esta clasificación. Aunque si consideramos “el poder” de quienes ostentan un puesto, sabremos que siempre se utiliza para fines organizacionales y personales, de manera casi indistinta. Así que no podemos asumir una actitud ingenua e ignorarlo.
La auditoría de seguridad informática se traduce a la verificación de la congruencia entre los requerimientos de seguridad, las políticas de seguridad y los mecanismos de seguridad. Para ello conviene considerar las siguientes conclusiones: 1. En principio, hay que considerar que la violación de las políticas y procedimientos es universal y no importa el tamaño (micro, chica, mediana o grande) o tipo de organización (pública o privada). Las principales causas identificadas son las organizacionales, lo que se acentúa cuando las necesidades operativas del negocio así lo demandan, sobretodo ante las excepciones. Algunas de las violaciones, salidas, rodeos, evasivas o resistencias a las normas son intencionales y conocidas y hasta toleradas a conveniencia en la organización. Por ejemplo, se tolera el uso de software “pirata” como sistemas operativos y software gráfico cuando no hay presupuesto; se tolera el software no autorizado como software libre u open source software cuando no hay presupuesto; y se toleran servicios no autorizados cuando los propios son deficiente tales como el correo gratuito y el chat. Lo anterior, en sentido estricto se convierte en una simulación gobernada por reglas no escritas. 2. La dualidad formal-informal es universal y se aplica a muchos ámbitos de la vida cotidiana y a la seguridad informática, por supuesto. Las principales implicaciones prácticas son que debemos estar concientes de ello, en principio de que es imposible, en la práctica, llegar a un cien por ciento de congruencia entre lo formal y los informal. En segundo lugar, los manuales de organización o de políticas de seguridad, en específico, nunca reflejarán el estado actual. Lo anterior lleva a tener que considerar que únicamente un porcentaje de lo normado puede ser congruente y por lo tanto, estrictamente normado hasta un cierto grado de certeza y que el resto nunca podrá serlo, mucho menos las excepciones o casos de estados de emergencia. Por lo anterior, la recomendación práctica sería ampliar el alcance de la seguridad a la integración de lo no formal y considerar un margen de tolerancia tal, que permita crear políticas e implantar mecanismos de seguridad prácticos y efectivos, gradualmente en un proceso de mejora. Adicionalmente está el costo que representa documentar la congruencia diaria. Por último, es claro que los mecanismos punitivos o represivos, aplicados ante la detección de diferencias entre lo formal y lo informal, a fin de cuentas resultan inútiles, pues siempre se encontrarán mecanismos de resistencia como la simulación o simplemente, mecanismos prácticos que destraben las normas equivocadas como el uso del correo gratuito. Esto también pone en duda la utilidad de los “departamentos de planeación” que pretenden poseer el conocimiento de los procesos, tal como lo prescribe la Administración Científica (Scientific Management) de Taylor que puede convertirse en una traba para las empresas posmodernas. 3. La ambigüedad del lenguaje tiene muchas consecuencias serias, tanto en la definición y como en la interpretación de la normatividad o las reglas o políticas. No es raro encontrar a dos auditores que opinen de manera encontrada sobre el mismo texto. Para ejemplificar, se tiene un caso extremo en los procesos judiciales, donde hay muchos casos públicamente conocidos a pesar de la “objetividad” de la evidencia. La ambigüedad lingüística es la razón del juego judicial en un ciclo semejante al siguiente: demanda – > defensa –> sentencia –> apelación –> ratificación o rectificación de la sentencia –> apelación en otro juzgado de otro nivel, donde el ciclo se repite. También se encuentra que en la especificación de la normatividad (que será auditada), frecuentemente se usan recursos lingüísticos que la vuelven ambigua deliberadamente. Por ejemplo, se usan adverbios y adjetivos tales como “hasta”, “máximo” o “mínimo” para definir algún límite de alguna métrica, de tal forma que permita medir un tope y no un rango estricto. 4. Adicionalmente, se supone que el trabajo del auditor y él mismo es “objetivo”, es decir, que sus inspecciones son una actividad humana y él está libre de intereses, emociones, sentimientos, valoraciones morales, etc. Esto, hoy en día, ante la crisis del positivismo lógico como corriente filosófica de la ciencia o del conocimiento, es caduco pues ha sido demostrado que claramente es imposible. Puede decirse que la ontología y epistemología positivista hoy en día, está en crisis, lo que equivale a la necesidad de incluir la subjetividad y lo simbólico como complementariedad de lo objetivo. Lo anterior, vuelve más relativa la importancia de las evidencias documentales (físicas y/o electrónicas), por ejemplo, en una auditoría de seguridad informática o en un análisis forense informático. La recomendación práctica es que la subjetividad no debe ignorarse, sino por el contrario, debe integrarse al proceso de auditoría para poder juzgar de manera más acertada las “desviaciones” respecto a lo normado y hacer recomendaciones más pertinentes. 5. Por último, me interesa destacar la simulación, el perfomance o actuación como fenómeno social asociado a la necesidad organizacional de aprobar la auditoría, tal como lo demuestra la teoría del “performance social”. No es poco frecuente el hecho de que cuanto una auditoría se lleva a cabo, a todos los participantes se les “instruye” (informalmente) qué decir, qué no decir, cómo actuar, cómo llenar los formatos y qué responder a las preguntas capciosas de los auditores. Tampoco es poco frecuente que “se compre” el resultado positivo de la evaluación. Claramente, cuando esto es así, la legitimidad de la auditoría es nula, a pesar de haberla “pasado” y de contar con “el certificado” o el “papelito”. Lo anterior demuestra en la práctica, quizá la poca utilidad que puede tener la auditoría en sí misma.