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?...
© 2002 Antonio Villalón Huerta
