Seguridad en Unix y redes - El "Área de Seguridad"

Casi cualquier mediana o pequeña empresa posee actualmente lo que se viene a llamar el `Área de Seguridad', formada pocas veces a partir de gente que haya sido incorporada a la plantilla a tal efecto, y muchas a partir del reciclaje de personal de otras áreas de la corporación, típicamente las de Sistemas o Comunicaciones. En este punto vamos a hablar brevemente de este área y su posición corporativa, haciendo referencia tanto a sus funciones teóricas como a sus problemas de definición dentro del organigrama de la organización.

---

>Cuál es la función de este área? Realmente, mientras que todo el personal sabe cual es el cometido de la gente de Desarrollo, Sistemas o Bases de Datos, el del área de Seguridad no suele estar definido de una forma clara: al tratarse en muchos casos, como acabamos de comentar, de personal `reciclado' de otras áreas, se trabaja mucho en aspectos de seguridad - para eso se suele crear, evidentemente -, pero también se acaba realizando funciones que corresponden a otras áreas; esto es especialmente preocupante con respecto a Sistemas, ya que en muchas ocasiones el personal de Seguridad trabaja `demasiado cerca' de esta otra área, llegando a realizar tareas puramente relacionadas con Sistemas, como la gestión de los cortafuegos (no nos referimos a la definición de políticas ni nada parecido, sino únicamente al manejo del mismo). Y si a esto le añadimos que a muchos de los que nos dedicamos a este mundo nos gusta también todo lo relacionado con sistemas - sobre todo si son Unix :-) -, pues llegamos a una situación en la que nadie pone pegas a hacer un trabajo que no le corresponde, con lo cual se vicia el área de Seguridad centrándose únicamente en aspectos técnicos pero descuidando otros que son igual o más importantes. Por si esto fuera poco, existe una serie de funciones en conflicto a la hora de gestionar la seguridad corporativa, típicamente la del administrador de seguridad frente a la del administrador de sistemas, de bases de datos, o incluso frente al operador de sistemas y los desarrolladores.

---

Teóricamente, el área de Seguridad ha de estar correctamente definida y ser independiente de cualquier otra de la compañía, y por supuesto de la dirección de la misma: aunque en la práctica sea casi imposible conseguirlo, no podemos definir una política de obligado cumplimiento para todos los trabajadores excepto para nuestros jefes. Evidentemente, ha de contar con el apoyo total de la dirección de la entidad, que debe estudiar, aprobar y respaldar permanentemente, y de forma anticipada, las decisiones de seguridad que el área decida llevar a cabo (siempre dentro de unos límites, está claro...).

---

El trabajo del área debe ser más normativo que técnico: no podemos dedicar al personal de la misma a cambiar contraseñas de usuarios o a gestionar (entendido por `manejar') los cortafuegos corporativos, sino que el área de Seguridad debe definir políticas e implantar mecanismos que obliguen a su cumplimiento, o cuanto menos que avisen a quien corresponda en caso de que una norma no se cumpla. Técnicamente esto no es siempre posible, ya que ni todos los sistemas ni todas las aplicaciones utilizadas tienen porqué ofrecer mecanismos que nos ayuden en nuestra seguridad, pero cuando lo sea es función del área bien su implantación o bien su auditoría (si es implantado por otro área). Si una determinada aplicación no soporta las exigencias definidas en la política de seguridad, pero aún así es imprescindible su uso, el área de Seguridad debe recordar que el cumplimiento de la normativa es igualmente obligatorio; al oir esto, mucha gente puede poner el grito en el cielo: en realidad, si el programa no cumple las especificaciones del área de Seguridad, lo lógico sería prohibir su uso, pero funcionalmente esto no es siempre (realmente, casi nunca) posible: no tenemos más que pensar en una aplicación corporativa que venga gestionando desde hace años las incidencias de la organización, y que evidentemente la dirección no va a sustituir por otra `sólo' por que el área de Seguridad lo indique. Si nuestra política marca que la longitud de clave mínima es de seis caracteres, pero esta aplicación - recordemos, vital para el buen funcionamiento de la organización - acepta contraseñas de cuatro, el usuario no debe poner estas claves tan cortas por mucho que la aplicación las acepte; si lo hace está violando la política de seguridad definida, y el hecho de que el programa le deje hacerlo no es ninguna excusa. La política es en este sentido algo similar al código de circulación: no debemos sobrepasar los límites de velocidad, aunque las caracteríticas mecánicas de nuestro coche nos permitan hacerlo y aunque no siempre tengamos un policia detrás que nos esté vigilando.

---

Aparte de la definición de políticas y la implantación (o al menos la auditoría) de mecanismos, es tarea del área de Seguridad la realización de análisis de riesgos; aunque el primero sea con diferencia el más costoso, una vez hecho este el resto no suele implicar mucha dificultad. Por supuesto, todo esto ha de ser contínuo en el tiempo - para entender porqué, no tenemos más que fijarnos en lo rápido que cambia cualquier aspecto relacionado con las nuevas tecnologías - y permanente realimentado, de forma que la política de seguridad puede modificar el análisis de riesgos y viceversa. Asociados a los riesgos se definen planes de contingencia para recuperar el servicio en caso de que se materialice un problema determinado; esta documentación ha de ser perfectamente conocida por todo el personal al que involucra, y debe contemplar desde los riesgos más bajos hasta los de nivel más elevado o incluso las catástrofes: >qué pasaría si mañana nuestro CPD se incendia o el edificio se derrumba?, >cuánto tardaríamos en recuperar el servicio?, >sabría cada persona qué hacer en este caso?...