Seguritecnia 341

II Jornadas de Seguridad en Entidades Financieras 71 SEGURITECNIA Mayo 2008 bricantes, a la hora de comunicar por IP, se ven ahora obli- gadas a montar diferentes equipos de recepción. Es más, si una CRA trabaja con diferentes entidades que emplean el mismo sistema y debido a que las señales son recibidas a través de un router específico para cada una de ellas, ten- drá que montar tantos equipos como entidades atienda, de modo que sus redes no se mezclen. Sólo en el caso de las CRA que son propiedad de la pro- pia entidad financiera y que, normalmente, emplean un único sistema para todas sus oficinas, este problema no existe. Si, adelantándonos al presente, tuviéramos que especifi- car una receptora IP universal, básicamente exigiríamos:  Capacidad para albergar varias tarjetas Ethernet y, por tanto, para recibir infor- mación de diferentes redes, respetando su independencia. Esto evitaría a la CRA el empleo de un equipo distinto por en- tidad.  Recepción automática de los diferen- tes formatos y en distintos protocolos IP (normalmente, UDP/IP y TCP/IP).  Gestión de los tests periódicos, tanto si éstos son emprendidos por los equi- pos instalados en las oficinas como si es la propia receptora quien los establece y realiza ( polling ).  Control horario de los citados tests, con generación de omisiones individuales ante la falta de un cierto número (pro- gramable en cada caso) de estas señales.  Control horario para omisiones masi- vas, ante la aparición de un elevado número de faltas de tests debido a posibles caídas parciales de la red (pérdida de uno o más nodos de comunicación, fallo o sabotaje de líneas de fibra óptica, etc.).  Capacidad para organizar grupos de equipos que pue- dan generar las citadas omisiones masivas, incluso capa- cidad para crearlos de forma automática ante la aparición de un fallo de este tipo, no clasificado previamente.  Gestión de los citados controles horarios mediante base de datos que permita, de forma fácil, la gestión integral de los abonados (altas, bajas, modificaciones, etc.), tanto a nivel individual como colectivo (por ejemplo, modifica- ción de un dato que afecte a todo un grupo de abonados). Y todo esto es sólo relativo a la recepción de señales. Todavía no hemos hablado nada sobre bidireccionalidad, verificación de alarmas, actualización automática de sis- temas y otros aspectos no menos importantes que IP nos puede solucionar de forma altamente eficiente. Pero de ello hablaremos más adelante. es así todavía y no sabemos por cuanto tiempo, porque hay que tener claras las enormes diferencias que existen entre ambos métodos de comunicación, RTB e IP, a pesar de su, en principio, idéntica capacidad informativa por paquete enviado. Para empezar, la diferencia más notable está en el vo- lumen total de envío de información manejado por uno y otro procedimiento y, en especial, en lo relativo a las seña- les de test periódico. Por RTB y heredado de la época en la que las llamadas tenían un coste significativo, aunque también debido a la limitada capacidad de aceptación de señales por esta vía por parte de las CRA (elevado tiempo necesario para cada comunicación), raramente un test tiene un período inferior a un día. Es más corriente una semana e incluso un mes. Por IP, las cosas cambian dramáticamente y es ésta una de las bazas principales de este tipo de comunicación a favor del elevado ni- vel de seguridad que proporcionan frente al sabotaje de la vía de comunicación: los tests pueden efectuarse cada pocos minutos, lo que permite tener supervisados los sistemas prácticamente en tiempo real. Esto significa que el volumen de infor- mación que ha de procesarse en la CRA es abrumadoramente superior. ¡Un día tiene 1.440 minutos! Lo que antes resultaba sencillo ahora es un problema porque, difícilmente, el soft- ware de gestión de la CRA que antes gestio- naba perfectamente el volumen de señales de test recibidas por RTB, puede ahora enfrentarse a este nuevo nivel y, además, y estrechamente ligado a esto, está la posibilidad de una caída parcial de la red que afecte si- multáneamente a un elevado número de abonados, bas- tante más probable que por RTB. Es por todo esto que la receptora IP no puede ser un ele- mento funcionalmente equivalente a la receptora RTB, siempre transparente a todo tipo de señales. La receptora IP, tanto si adopta la estructura de un equipo físico dedicado como si se trata de un ordenador en el que corre un software , ha de desempeñar funciones de filtro de este tipo de señales de modo que, al software de gestión de la CRA, sea el que sea, no lo sobrecargue en ningún caso. Es este un factor primordial, ya que no obliga a la CRA a efec- tuar un costoso cambio de su sistema de gestión. ¿Qué productos necesita el mercado para solucionar estos problemas? Considerando que la mayoría de las CRA que atienden a la Banca son públicas y que han de trabajar con diferentes fa-