Uno de los problemas a los que nos enfrentamos en organizaciones con una complejidad de red media o alta es la gestión de los permisos que implican a elementos de comunicaciones (switches, cortafuegos, routers, etc.); me gustaría esbozar algunas de las cosas hay que tener en consideración para que la gestión sea posible.

Primero de todo, ante la solicitud de una petición de acceso desde un servidor a otro por parte de algún responsable técnico de algún proyecto TIC de la compañía, hay que tener en consideración dos tipos de aspectos bien diferenciados:

• Aspectos funcionales: Si alguien solicita por ejemplo acceso al puerto de Oracle de un servidor de BBDD, lo primero que hay que evaluar es si desde el punto de vista de negocio, ese permiso debe de ser concedido. Este tipo de accesos deben ser validados por un responsable o autorizador funcional, que puede o no coincidir con el propietario del activo dentro de la organización. Es muy habitual que por agilidad en las gestiones, compañerismo mal entendido, o ausencia de procedimientos formales, este punto se pase por alto y se pase a los aspectos técnicos directamente, sin entrar a considerar la conveniencia de la solicitud desde el punto de vista del negocio.
• Aspectos técnicos: Una vez la autorización funcional ha sido concedida, hay que revisar los aspectos técnicos de los permisos solicitados, para detectar sus implicaciones técnicas sobre otros servicios, el perímetro de la red, problemas de seguridad, etc. Algunas de las cuestiones son: ¿la red origen esta controlada por la organización, o es una dirección externa ajena sobre la que no tenemos información? ¿El protocolo utilizado para la conexión es seguro? ¿Va cifrado? ¿Implica este acceso abrir accesos con redes no confiables? ¿Afectan a la DMZ? ¿Es posible utilizar soluciones alternativas? En cualquier caso, la recomendación es que si el cambio es de cierta relevancia, tiene que haber una auditoria, tanto de caja blanca como de caja negra; esto debería ser obligatorio para cualquier acceso externo a la red corporativa, como por ejemplo el de un nuevo proveedor.

Para la construcción de la topología de una red de caja negra se emplean herramientas como Traceroute; seguro que la conocen. Esta herramienta emplea el campo TTL o tiempo de vida de la cabecera IP para averiguar por qué dispositivos de red pasan los paquetes hasta llegar al host destino.

La aplicación manda 3 paquetes con TTL valor 1 hacia la máquina objetivo; cuando estos paquetes llegan al primer dispositivo intermedio, éste decrementa el TTL en 1, pasando a valer 0, y es descartado notificándonos mediante un paquete ICMP tipo 11 Time Exceeded. La siguiente vez se enviará con TTL valor 2, posteriormente con valor 3… así hasta llegar a la máquina destino, la cual no contestará con el Time Exceeded.

Lo más importante para una auditoría de seguridad son los últimos saltos que nos permitirán obtener la topología de la red que se está auditando. Ahora bien, seguramente nos habrá ocurrido que en ocasiones los resultados obtenidos no son los correctos puesto que llegado a un firewall de la red no conseguimos poder avanzar hasta el host; incluso dependiendo del programa que empleemos los resultados son distintos. Esto es debido a combinación de las reglas de filtrado de los firewalls y los protocolos empleados por cada programa “traceroute”.

Corre el año 2006, si no recuerdo mal, y empieza la revolución en las redes domésticas de acceso a internet. La mayoría de las nuevas instalaciones de internet domésticas pasan de utilizar el “obsoleto” cable para “innovar” en la tecnología WIFI. Se acabaron los cables, ya no tocará pelear porque éste tiene que atravesar toda la casa para llegar a una única habitación, y por fin mi portátil será… ¡¡¡portátil!!!

Por supuesto, estas redes supusieron un nuevo eslabón en la cadena de la seguridad informática y un nuevo filón para los atacantes. Su seguridad evolucionó desde redes sin contraseña, a redes con clave WEP, WPA, WPA2 hasta la actualidad en la que la configuración más segura recomendable es WPA2-PSK+AES. No voy a explicar aquí cada una de las siglas, ya que queda claro que para eso está disponible cualquier buscador, aunque voy a poner fácil una de las búsquedas: WEP

Desde hace unos años utilizamos a diario billetes de euro. Aunque todos los expertos coinciden en que falsificar estos billetes es difícil, seguramente por nuestras manos ha pasado, sin nosotros saberlo, algún que otro billete falso, imitaciones en muchos casos tan perfectas que únicamente prestando mucha atención -o siendo un experto- podríamos haberlas detectado. Los billetes más falsificados han sido los de 20 y 50 euros (en especial los primeros), aunque con la crisis se empiezan a falsificar también billetes más pequeños, y por tanto más fáciles de “colocar”.

Vamos a comentar en este post algunas de las medidas de seguridad de los billetes de euro que a diario circulan por Europa; y para empezar, es necesario hablar del papel del billete de euro. Está compuesto principalmente de fibras de algodón, material con una alta resistencia física, y por tanto de larga duración; este algodón es tratado para obtener una pasta a la que se añaden medidas de seguridad adicionales (fibrillas, colorante, etc.). A simple vista, podemos observar que este papel presenta carteo (el sonido característico del papel moneda), y pasando el dedo o la uña por el billete podemos notar que la tinta es más o menos gruesa en función de la zona del billete; esta última medida de seguridad es debida a la impresión calcográfica del billete en su anverso, técnica de imprenta costosa (no suele ser habitual para el falsificador disponer de una prensa con esta tecnología) que proporciona al billete un relieve característico de hasta 0,14 mm. de altura

Esta es una pregunta que suele surgir con frecuencia en organizaciones que ya tienen uno o más sistemas de gestión implantados, y abordan un proyecto de implantación de SGSI. ¿Integramos, o los “llevamos por separado”? Nuestra experiencia nos dice que hay enfoques muy diversos a la hora de enfrentarse a esta pregunta.

Algunos clientes tienen claro desde el principio que quieren que su SGSI esté integrado con el Sistema de Gestión que ya tienen implantado, otros que prefieren mantenerlos independientes, y otros que aunque parten de un planteamiento definido, resistencias dentro de la organización (los responsables de los sistemas de gestión ya implantados, en ocasiones) o la detección de sinergias aprovechables les hacen cambiar de opinión. Tengo que decir que nosotros, como S2 Grupo, siempre recomendamos integrar el SGSI con cualquier Sistema de Gestión que se encuentre ya implantado, y ahora veremos porqué.

Es (para nosotros) obvio que de la integración de varios Sistemas de Gestión se obtienen muchos beneficios, y prueba de ello en la propia ISO 27001, en relación a un Sistema de Gestión de Calidad y un Sistema de Gestión Medioambiental, se indica que:

Dentro de la serie dedicada a seguridad sectorial, vamos a tratar hoy brevemente aspectos de seguridad en hoteles y establecimientos similares. El principal reto al que nos enfrentamos al hablar de seguridad en hoteles es el propio negocio del sector: la continua fluctuación de viajeros que entran, salen o se alojan en el hotel, 24 horas al día y 365 días al año. Este enorme trasiego de personas define unas amenazas características a la seguridad hotelera: por un lado, las que afectan a la integridad de las personas que hay en el hotel (tanto huéspedes como trabajadores), y por otro las que afectan a la información asociada a los viajeros: protección de datos de carácter personal, medidas antiterroristas… No hablaremos de otra amenaza común, pero aparentemente asumida por todas las cadenas hoteleras: el hurto de pequeños objetos (toallas, pilas, ceniceros…) en la habitaciones por parte de los propios huéspedes.

Desde el punto de vista de las amenazas contra la integridad de las personas, sin duda en los hoteles la principal de ellas es el incendio; si en cualquier ubicación un incendio es preocupante, lo es más todavía en los hoteles, debido a tres características de estos centros: el desconocimiento por parte de los huéspedes de las instalaciones y vías de evacuación, la cantidad de personas que puede haber durmiendo en el momento de producirse un incendio y, por último, las dimensiones globales del hotel y por tanto la cantidad de personas en su interior. Para minimizar riesgos relativos a incendios, en todos los hoteles existen vías de evacuación diseñadas y señalizadas según normativa, así como indicaciones de las mismas en las habitaciones del hotel. Es más que recomendable, al llegar a la habitación, pegarle un vistazo a estas indicaciones y hacernos una idea de qué deberíamos hacer en caso de incendio; como se suele decir, nunca pasa nada, pero cuando pasa es el peor momento para ponernos a leer las indicaciones, buscar las salidas de emergencia, etc.

Habiendo recorrido en entradas anteriores (véase I y II) aspectos del Esquema Nacional de Seguridad como su origen, su ámbito, su finalidad y los actores involucrados, en esta tercera entrada relacionada con esta temática veremos, aunque de momento sea por encima, los contenidos prácticos del mismo.

Resumen de contenidos del Esquema Nacional de Seguridad

Los puntos destacados a continuación pretenden ser los conceptos más importantes que introduce, desde mi punto de vista, el Esquema Nacional de Seguridad. Incluimos los artículos donde se alude al concepto descrito, pero tengamos presente que alguna de estas ideas se recoge no solo en un artículo concreto, sino a lo largo de todo el documento.

(La entrada de hoy es la quinta colaboración de Francisco Benet, que como ya les hemos comentado anteriormente es un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Para empezar, todo este ‘embrollo’ debe comenzar, cómo no, con la generación de una política, que esté en consonancia con la Política de Clasificación de la Información (ver estas dos entradas sobre el tema). Hay que destacar que un aspecto crítico en todo este jaleo es el aspecto legal, ya que el documento en sí mismo puede tener unos aspectos legales importantes que constituyen el principal handicap (y que veremos más adelante).

Por tanto, en la definición de dicha política esta altamente implicado el departamento legal, tanto para definir los periodos de retención, como para poder traducir todos los requerimientos legales en la definición del par categoría del documento-período de retención. Otros participantes deberán ser Dirección y el Responsable de Seguridad, como responsables y encargados de implantar y hacer cumplir dicha política (aunque la figura puede ser otra). Otro de los principales problemas que no debemos olvidar es la destrucción de la información no necesaria; esto deberá estar plasmado en la política.

Dentro de los posts dedicados a la seguridad en las eléctricas (que a su vez se engloba en la serie de Seguridad Sectorial, que todos seguís atentamente en este blog :), toca el turno de los aspectos relativos al transporte, transformación y distribución de la energía para hacerla llegar al usuario final (véase entradas anteriores: [Introducción][Producción][Control]).

El transporte de energía eléctrica se realiza desde las centrales productoras, que hemos comentado en un anterior post, hasta las centrales de transformación, donde se modifican las características para distribuir la energía hasta el usuario final. En esta etapa de transporte se utilizan líneas de alta tensión, con una distribución geográfica muy extensa, lo que ya de entrada implica varios riesgos considerables: por un lado, los relativos a la falta de vigilancia de las líneas (robos, hurtos, sabotajes…) y por otro los relativos a las amenazas naturales (desde tomentas eléctricas hasta desprendimientos que puedan comprometer la línea). El primero de estos grupos no suele ser habitual, a pesar de que las condiciones —por ejemplo, el aislamiento— lo favorezcan, debido por un lado debido a la peligrosidad de las instalaciones (¿quién se atreve a meter mano en una torreta de alta tensión?) y por otro a la escasa repercusión que estos actos tendrían a nivel social: si se produce un ataque a una línea que la deja inutilizada, se distribuiría energía desde otra central. En lo que respecta a amenazas naturales, las instalaciones implicadas en el transporte suelen ser robustas, incorporando desde protecciones contra rayos hasta elementos estructurales frente a avalanchas, por lo que sólo fallarían en el caso de problemas de relativa magnitud.

Muchas veces hemos oído el termino bastión o bastionar un servidor en una red DMZ. Este término es empleado cuando a una configuración por defecto de una instalación en un servidor se le realizan modificaciones para fortalecer la seguridad del sistema. A muchos de ustedes les vendrá a la mente Bastille en entornos RedHat.

Dichas modificaciones suelen estructurarse comúnmente en tres etapas:

• La primera etapa se centra en cerrar los puertos de aquellos servicios que escuchan por defecto y que no se requieren para las necesidades solicitadas para dicho servidor.
• La segunda etapa consiste en fortalecer la configuración de los servicios que si se necesitan mediante la restricción de los usuarios que pueden acceder a los servicios, restricción de ordenes que pueden realizar, control y filtrado de los datos que se le envían al servidor (XSS, SQL injection, etc), política de actualizaciones…
• La tercera etapa se centra en instalar el servidor en la red DMZ, la cual dispone de un firewall que restringe el acceso de las máquinas externas hacia la DMZ.