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.

En el entorno científico-tecnológico, con un buen nombre se tienen más probabilidades de llegar a algún sitio. Piénsese en el “método de la burbuja” como algoritmo de ordenación, en la “partícula de dios” (bosón de Higgs), en la computación cuántica o en la nanotecnología. Marketing científico, podríamos llamarlo. Viene esto a cuento de que, la semana pasada, asistí a la Jornada de Inteligencia Computacional Aplicada al Negocio, organizada por el ITI y me llamó la atención los nombres tan atractivos que tienen los tipos de algoritmos de que se trata en este campo: redes neuronales, inteligencia de enjambre, computación evolutiva… son nombres que inspiran.

Una de los ponentes, Arthur Kordon, de Dow Chemical, presentó una clasificación de las diferentes ramas de la Inteligencia Computacional que me resultó bastante esclarecedora y que paso a comentar de manera muy resumida. Algunas de estas técnicas son utilizadas en los sistemas de detección y protección de seguridad de la información. Ya hablaremos de ello.

En las conferencias de enise que les comenté en la pasada entrada, celebradas los pasados 27, 28 y 29 de octubre en León, tuve la suerte de asistir a una conferencia que, como ya he comentado en un post anterior, me gustó especialmente.

Habló D. José Manuel Maza, magistrado del tribunal supremo. Una persona que emana personalidad por los cuatro costados y que dijo muchas cosas en muy poco tiempo. Entre otras cosas habló de lo lejos que están las leyes que aplican los magistrados de la realidad del momento en el que nos encontramos, y de lo atados de manos que se encuentran en muchas ocasiones con el código penal que nos ha tocado vivir.

Hizo un comentario que me llamó mucho la atención: D. José Manuel estaba un poco disgustado porque había tenido que ausentarse de su puesto en un momento en el que se iba a debatir la postura que se tenía que adoptar, en general, con los asuntos relacionados con las redes P2P y la pornografía infantil.

Son muchas las recomendaciones hechas por ITIL en su Gestión de Incidencias, todas útiles y de implantación obligatoria. Eso sí, ITIL no te las va a resolver, sino que te va a ayudar para establecer un proceso para gestionar cada una de las incidencias, aprender de ellas, ser más proactivos y reactivos, obtener mejoras de cada una de ellas y aplicarlas a la infraestructura IT que se tenga, que no es poco…

Saber reaccionar ante una incidencia es fundamental, y más aun si conlleva una pérdida de servicio. En este tipo de casos la experiencia es el rasgo más valorado para saber afrontarlas. Por mucha preparación técnica que se tenga, es difícil mantener la compostura y tener la serenidad suficiente para poder abstraerse de la presión y analizar la situación.

enise es ya un clásico, joven, pero ya un clásico. A mí me gusta. Cada año parece que reúne a más gente del sector. Casi todos somos empresas proveedoras de servicios o de productos en el ámbito de la seguridad e instituciones públicas. Casi todas en el ámbito de la seguridad de la información, aunque se hacen tímidos intentos de dar cabida a proyectos y soluciones de seguridad fuera de ella. Hemos sido 520 los asistentes y 110 empresas e instituciones han estado representadas en León para ver que se está haciendo en España en esta materia. Es un foro de encuentro, un lugar y un momento para reposar y reflexionar sobre el sector. Un momento para establecer relaciones y recoger ideas.

El tema general del encuentro ha sido la innovación tecnológica en seguridad TIC. Ha habido algo de innovación, no demasiado, porque como dijo uno de los ponentes, exagerando un poco, esto parece como en la película “El día de la marmota”: Un año más vuelvo a estar aquí, hablando de lo mismo, a los mismos….para acto seguido hacer una exposición interesante con cosas totalmente nuevas. Bueno, no deja de ser una visión que, personalmente, no comparto, puede ser que una persona, un año después, no tenga nada nuevo que presentar. Cada uno es libre de exponer lo que estima oportuno en un evento de estas características. Nosotros, desde S2 Grupo, tenemos muchas cosas que contar y les adelanto que el año que viene estaremos allí, participando, para demostrar que esto no tiene porque ser así.

En esta segunda entrada (véase la entrada anterior) sobre el Esquema Nacional de Seguridad comenzaremos revisando la finalidad del mismo, y terminaremos comentando a quién afecta, donde a buen seguro encontraremos alguna sorpresa.

Finalidad del Esquema Nacional de Seguridad

La finalidad del Esquema Nacional de Seguridad se revisó colateralmente en la entrada anterior cuando hablábamos de su origen. Repasemos.

En este blog normalmente abordamos la gestión de la seguridad desde el punto de vista TIC, desde el punto de la seguridad de la información, de los procesos de negocio, etc. Pero hay otras seguridades, como ha estado presentando Toni Villalón en sus últimos posts. Hoy quería dar unas pinceladas de cómo se gestiona la seguridad en un ámbito totalmente diferente y muy complejo: el de la navegación marítima. No es algo caprichoso; algunos integrantes de S2 Grupo estamos asistiendo a un curso de Seguridad Portuaria, en el marco de un proyecto I+D+i en el que estamos participando.

Voy a ver si soy capaz de ponerles en situación.