Blog de Seguridad de la Información de S2 Grupo
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.
No sé si han tenido alguna vez la oportunidad de ver alguna reproducción a tamaño real de alguna de las carabelas que partieron en busca de las Indias Orientales…a mí me pone la carne de gallina pensar en las condiciones de habitabilidad de esas naves, en un trayecto sin duración prefijada, navegando con las estrellas, a merced de los vientos, sin un destino claro….ya ni hablemos de condiciones de seguridad en la navegación. Evidentemente tomarían sus medidas de seguridad, pero no existían tratados internacionales ni estándares de referencia.
No soy ningún experto en la materia, supongo que desde el siglo XV se habrán escrito tratados que han intentado sentar ciertas bases al respecto, pero el punto de inflexión que hizo al mundo plantearse la necesidad de regular el tráfico marítimo fue el histórico incidente del Titanic en 1912 (si tienen un momento, denle un vistazo a este interesante enlace). Más de 1.500 víctimas, el impacto social de su hundimiento,… pero fíjense en un par de datos.
A bordo había 2.200 personas, entre pasaje y tripulación. Sin embargo, los botes de salvamento sólo tenían capacidad para algo menos de 1.200 personas. Partimos ya de un evidente mal dimensionamiento de la capacidad de los botes. Pero es que además, aquella fatídica noche muchos de los 20 botes disponibles no se llenaron a su máxima capacidad, lo que trajo como consecuencia que sólo hubiese 711 supervivientes. Casi 500 personas más podrían haberse salvado si el Titanic hubiese dispuesto de un adecuado plan de protección (obviando el hecho de que si hubiese existido dicho plan, la capacidad de los botes de salvamento habría sido mayor).
Este histórico incidente provocó la creación de la Organización Marítima Internacional (OMI), dependiente de Naciones Unidas. La OMI está estructurada en comités, algunos de los cuales —el Comité de Seguridad Marítima y el Comité de Protección del Entorno Marítimo— han ido publicando regulaciones como el Convenio MARPOL (Maritime Polution) que regula la gestión medioambiental de los diferentes tipos de residuos que generan los barcos, o el SOLAS (Safety Of Life At Sea), una de las primeras acciones que abordó la OMI tras el naufragio del Titanic.
Desde su publicación en 1914, los diferentes capítulos del SOLAS han ido sufriendo diferentes modificaciones y actualizaciones (enmiendas es el término técnico utilizado). De entre ellas voy a destacar dos: el código IMDG -que regula el transporte marítimo de mercancías peligrosas- y el código ISPS.
El código internacional ISPS, ó PBIP en español (Protección de los Buques y de las Instalaciones Portuarias) es una enmienda del convenio SOLAS publicada en 2002 por la OMI. ¿Y saben cuál es el origen de su creación? Los atentados terroristas del 11S de 2001 en EEUU.
Y quizás ustedes se preguntarán: pero si los ataques del 11S se realizaron con aviones, ¿por qué ese afán en regularizar el tránsito marítimo? Tiene una explicación. A raíz de los atentados, que pillaron desprevenidos tanto a la sociedad como a los servicios secretos norteamericanos, se dieron cuenta de algunos detalles sorprendentes:
Pero también se dieron cuenta de que si intentaban incrementar el control sobre los contenedores que entraban por ejemplo en el puerto de Nueva York, además del coste económico que implicaría —mejora de la seguridad general de las instalaciones portuarias— y del número de inspectores que habría que seleccionar, habría otra importante consecuencia: el puerto se convertiría en un auténtico cuello de botella, en el quedarían literalmente atascadas las mercancías, con el perjuicio que ello tendría para el comercio y las empresas.
Solución: trasladar virtualmente sus fronteras al país de origen de un contenedor que tenga como destino los EEUU. Es decir, pasar la patata caliente del control preventivo al país de origen, con todo lo que ello implica.
Y como los EEUU son los que marcan las reglas del juego esto provocó que la modificación del SOLAS que trajo como resultado el PBIB se “convirtiera en ley” en el ámbito europeo con el Reglamento CE 725/2004, además de otras iniciativas norteamericanas por las que había que pasar “sí o sí” para poder comerciar con este país, como la iniciativa CSI (nooooo…..nada que ver con Grissom y sus chicos), la Container Security Initiative, que desplaza a funcionarios de aduanas norteamericanos a algunos de los puertos más importantes del mundo, o MEGAPORT, con controles de radioactividad. Y existen más regulaciones posteriores, pero ya les he mareado bastante.
Se han dado cuenta, ¿no? Hemos hablado de seguridad de las personas, de la seguridad de los propios buques, de la gestión de la seguridad de mercancías peligrosas, de la seguridad de la navegación, de la seguridad del tránsito comercial, de seguridad medioambiental, de lucha antiterrorista….
Imaginen todo lo que esto implica para puertos como el de Valencia, Algeciras o Barcelona —punteros en el tráfico comercial con EEUU y el resto del mundo— desde el punto de vista de las inversiones económicas y desde la coordinación entre los diferentes estamentos que intervienen. Además de las empresas privadas consignatarias, transitarias, transportistas, etc., en España, las grandes protagonistas son las Autoridades Portuarias, dependientes del Ministerio de Fomento, que cuenta con sus respectivas policías portuarias, que además deben coordinarse con la Guardia Civil, las autoridades locales, autonómicas, etc.
En definitiva, un importante reto a afrontar, con planes de protección para los buques, para las instalaciones portuarias, para los propios puertos, con organismos internacionales que regulan y auditan…y todo “por culpa” del Titanic.
Para finalizar nuestra serie sobre seguridad en las eléctricas (véase [1][2]), y dado que como ya adelantamos en nuestro primer post el área que hemos llamado “de empresa” no va a ser objeto de un artículo específico —a fin de cuentas, en este caso se comparten casi todos los elementos de seguridad con organizaciones de cualquier otro sector—, vamos a hablar hoy del área funcional de control y los aspectos de seguridad más destacables en la misma.
El área de control está formada por una red de centros con un objetivo muy específico: el control —como su nombre indica— de la calidad de la energía y del tráfico de la misma, en cualquier punto de la cadena, desde las centrales de producción hasta nuestras casas (realmente, no hasta nuestras casas tal cual, pero casi). Aquí, sin duda, los activos más relevantes —aparte de las personas, que siempre son lo más importante— son por un lado los elementos tecnológicos de control y por otro la información que estos elementos manejan, y por tanto la principal amenaza es el sabotaje, tanto físico (atentados o vandalismo contra los centros de control) como lógico (ataques a los sistemas de control, intrusiones…).
No hay que olvidar que las eléctricas son un sector considerado como Infraestructura Crítica Nacional, y por tanto son un objetivo prioritario no sólo de terroristas, sino también de servicios de inteligencia de países enemigos (o amigos); evidentemente, ningún servicio secreto ejecutaría —al menos directamente— un ataque terrorista contra los centros de control de la energía eléctrica de un país amigo, ya que en caso de verse descubiertos, el hecho podría tener una gran repercusión internacional, pero en el caso de ataques cibernéticos la cosa cambia: a cualquier país le interesa obtener la información relativa al sector eléctrico de su vecino y, si existiera la posibilidad de, en caso de conflicto, poder tomar el control de los centros, pues mucho mejor, ¿no? Y todo esto sin posibilidad de ser descubiertos, ya que el ataque telemático siempre será remoto, y si alguien nos acusa, bastará con negarlo… evidentemente, algo muy apetecible para todos, y por tanto algo a tener muy encuenta a la hora de hablar de los centros de control del sector eléctrico.
Aunque un ataque de estas características dirigido a nuestros centros de control no parece especialmente probable, ya se han dado casos de “intentonas” similares dirigidas a los Estados Unidos; por ejemplo, aquí tenéis un enlace de una noticia que apareció en el WSJ. Probablemente, para ellos sea una amenaza más de las muchas que sufren, pero siempre algo a tener en cuenta. Muy en cuenta, si consideramos que en USA existe desde hace tiempo un ISAC específico para este sector, el ES-ISAC, encargado del intercambio de información referente a la seguridad del sector (física, lógica…) tanto entre eléctricas como con el gobierno, administraciones locales, grupos de interés, etc.
Como hemos dicho, la amenaza lógica al control eléctrico en España no es algo, de momento, preocupante (o eso dicen). Pero si hablamos con cualquier director, responsable, técnico… de seguridad de una eléctrica, nos puede dar datos acerca del volumen de ciberataques que las empresas del sector sufren a diario, sin consecuencias pero con algo más que intencionalidad, desde países no-amigos (no les llamaremos “enemigos”). Asusta, ¿verdad?
(Fotografía por Pyrenne en Photobucket)
Cuando uno lleva mucho tiempo relacionado con entornos de monitorización y aspectos relacionados, tanto a nivel técnico como de gestión, acaba viendo sistemas susceptibles de ser monitorizados por todas partes (y las implicaciones derivadas). Verán porqué les digo esto.
En mi empresa, S2 Grupo, tenemos una máquina de vending, ya saben, de esas que sirven botes de refrescos, rosquilletas y chocolatinas varias. Ya conocen la estructura: la máquina tiene varios estantes, uno encima del otro, y cada estante está formado por varias filas con diferentes productos; similar a la de la imagen. El problema es que algunos compañeros hemos observado que existe un significativo margen de mejora que podría ser aprovechado mediante un sistema de monitorización y control del consumo de los productos. En realidad, no es que exista margen, sino que parece que no existe ningún tipo de gestión racional del consumo de los clientes. Veamos cuáles son los problemas:
En definitiva, lo que tenemos es una máquina de vending con productos que no se compran, otros que apenas se compran, otros que se venden con facilidad pero no son repuestos, y otros cuyo número de filas es muy inferior al deseado por el consumo que tienen. No me negarán que si fuesen ustedes el gerente de la empresa distribuidora, no es una perspectiva desalentadora.
Hay varias soluciones, de diferente nivel de complejidad técnica, que podríamos aplicar a este caso (y que sin duda algunos proveedores ya están aplicando):
Esto es, sin entrar en demasiados detalles, alguna de las mejoras que podrían plantearse en este caso con un poco de monitorización y control de las instalaciones; les diría que es posible que la empresa que nos suministra los productos esté haciéndolo, pero francamente, todo apunta a que no es así, porque de serlo, yo tendría mi Kinder Bueno, que es lo que importa. A nivel técnico, no se requiere mucho si nos decantamos inicialmente por la opción más simple. Organizativamente, sí, es algo más complejo; implica un nivel nada despreciable de gestión, coordinación, análisis y seguimiento, tanto con reponedores, clientes, proveedores y demás, incluyendo el departamento comercial; nadie dijo que fuese a ser cantar y coser. Tampoco hay que obviar el hecho de que puedan existir contratos con determinados proveedores que nos obliguen a dedicar un porcentaje fijo de espacio en la máquina a sus productos; la viabilidad y rentabilidad de dicha ocupación debería ser también analizada. Por último, otra variable importante es el margen de beneficio por producto, que debería ser estudiado y puesto en contraste con su volumen de ventas; un margen pequeño puede ser rentable en productos consumidos masivamente, pero da igual si el margen es muy elevado, si no vendemos ni una Fanta (bueno, sí, una: en el solsticio de verano).
Quizá les parezca que una máquina llena únicamente de Kit-Kat, Coca-Cola y Kinder Bueno (por simplificar las cosas) es… “un poco triste”. Que en la variedad está el gusto, y cosas así. Pero en realidad no. Lo que es triste es que un cliente quiera un Kinder Bueno a media tarde y encuentre que en su lugar, hay unas galletas con sabor vayaustedasaberqué que desde luego él no va a comerse. Eso es realmente lo triste, porque él se queda sin su chocolate y ellos sin su dinero.
Acabo. Les aseguro que el margen de rentabilidad de “nuestra” máquina de vending existe, y presiento que no es despreciable. Lo que significa, en pocas palabras, que alguien está perdiendo dinero (y no soy yo, que si por no he sido bastante obvio, estoy deseoso de gastármelo en Kinder Bueno). Me atrevería a decir que en todas las empresas existen aspectos como este, susceptibles de mejora, pero que por inmovilidad, falta de iniciativa/innovación/análisis, o aspectos culturales, no se ponen en marcha. Ahí es donde entra BAM, de lo que esta entrada podría considerarse un ejemplo aplicado —y algo tonto, no lo niego.
(Por supuesto, admito la posibilidad de que nuestro proveedor haya valorado lo que les comentaba previamente, y tras analizarlo, lo haya descartado… pero de nuevo, no lo creo).
Este post pretende ser la primera entrada de lo que será una serie relacionada con el futuro Esquema Nacional de Seguridad.
La idea con esta serie es informar sobre el Esquema Nacional de Seguridad: su origen, a quién afecta tanto directa como indirectamente, los puntos destacables, y cómo afectan estos aspectos a los diferentes actores involucrados. A lo largo de las distintas entradas profundizaremos más en los puntos del Esquema Nacional de Seguridad que entendamos más relevantes, siempre con la idea de que se produzca información útil y eminentemente práctica. Como introducción, en esta primera entrada hablaremos del origen del Esquema Nacional de Seguridad, para lo que se hace imprescindible hablar de la Ley 11/2007. Si desean echarle un vistazo al primer borrador, del pasado 15 de julio, lo tienen disponible desde la página del Consejo Superior de Administración Electrónica.
Origen del Esquema Nacional de Seguridad. La Ley 11/2007
Como muchos de nuestros lectores ya conocerán, este próximo Diciembre entra en vigor la Ley 11/2007. De manera muy resumida podemos decir que esta ley viene a dar derechos a los ciudadanos para comunicar electrónicamente con las Administraciones Públicas (en adelante AAPP). Por ejemplo, obtener un certificado de empadronamiento o gestionar mis cuentas con Hacienda deberá ser factible y sencillo desde Internet. Los ejemplos son innumerables, y todos aportan beneficios para el ciudadano.
Vemos pues que, en un plano teórico esta ley, en su esencia, ayudará a que paulatinamente las AAPP sean cada vez más agiles y eficientes, lo que repercutirá en que los ciudadanos nos beneficiemos de esta eficiencia. Hasta aquí la teoría: la eficiencia al asalto de las AAPP.
La realidad es algo diferente a lo que el plano teórico pretende, principalmente porque los recursos son los que son. Aún así, es de esperar que con el paso de los meses (o más bien los años en algunos casos, esperemos que no muchos) las AAPP terminen encontrado los recursos, al mismo tiempo que los ciudadanos comenzamos a hacer uso de los derechos que esta ley nos otorga. Es decir, a medio-largo plazo esta ley (de nuevo, en su esencia) será muy positiva para todos; no cabe duda de ello. Los ciudadanos podremos gestionar de forma diligente las tramitaciones que necesitemos realizar, y al mismo tiempo las AAPP podrán atender las peticiones ciudadanas ejercidas electrónicamente de forma mucho más eficiente (adiós a las ventanillas y a los “vuelva usted mañana”).
Llegados a este punto, ya tenemos una ley que, en el medio plazo, entendemos como muy positiva para todos, en tanto en cuanto nos permite gestionar con las AAPP desde el sofá de casa. ¿Perfecto? Aun no.
Existe una implicación más en lo que a esta ley se refiere, que es la base del Esquema Nacional de Seguridad. El hecho de que los principales servicios que ofrece una organización como la AP —la mayor organización del Estado Español— sean de carácter electrónico hará que la dependencia de las tecnologías de la información y las comunicaciones sea significativamente mayor que hoy en día, hasta el punto de que esa dependencia sea simplemente absoluta.
Es decir: sin TIC, no habrá Administración Pública.
En ese futurible bastante cercano (años, no decenios) se deberá tener presente, al mismo nivel que la funcionalidad, la seguridad con la que se presten dichos servicios, requisito imprescindible que debe nacer con la propia funcionalidad y no abordarse a posteriori como un agregado más. Sin esta seguridad no lograremos que el ciudadano sienta la confianza necesaria para utilizar su DNI electrónico, para dar de alta sus datos en el Ministerio de turno, introducir pines, etc. Sin confianza, no hay relación electrónica posible y esta confianza debe venir dada por la Seguridad en mayúsculas, con la securización holística de los activos que dan soporte a los servicios definidos por la Ley 11/2007.
Este es el origen del Esquema Nacional de Seguridad: Securizar los activos que la AP necesita para funcionar ahora y en el futuro, establecer un marco de referencia al que mirar cuando la AP quiera dar contenido al verbo securizar. De esta manera la propia Ley 11/2007 define en su artículo 42.2 el Esquema Nacional de Seguridad:
Antes de terminar, una aclaración: cuando decimos Seguridad en mayúsculas, cuando utilizamos el inexistente verbo securizar, estamos hablando de muchas cosas: estamos hablando de responsabilidad, de globalidad, de gestión, de políticas, de controles, etc. En definitiva, estamos hablando de lo que las normas internacionales dicen de Seguridad.
En futuras entradas de esta serie comentaremos a quién afecta el Esquema Nacional de Seguridad, así como sus principales contenidos. Los detalles y las opiniones los desgranaremos más adelante.
La tecla mágica es una interrupción que permite comunicarse con el kernel en situaciones de inestabilidad en una máquina Linux, que viene habilitada por defecto en la gran mayoría de kernels precompilados de las distribuciones actuales. En caso de que compilemos el núcleo a mano, la opción “Magic SysRq Key” se encuentra en el menú “Kernel Hacking”. En el fichero de configuración del kernel recibe el nombre de CONFIG_MAGIC_SYSRQ por lo que realizando un “grep” de éste veremos si la hemos habilitado (debe aparecer CONFIG_MAGIC_SYSRQ=Y).
No es un secreto para nadie que una parte importante de los problemas de seguridad de los sistemas de información tiene su origen en defectos de las aplicaciones que éstos ejecutan. Tampoco lo es que estos defectos, que se manifiestan en forma de vulnerabilidades, se introducen en el software durante su proceso de desarrollo. Lo que a día de hoy no es algo aún suficientemente conocido, es la solución a este problema.
Históricamente, la industria del software ha funcionado usando una dinámica de liberar al mercado productos con un escaso nivel de madurez y se ha ocupado sobre la marcha de corregir los defectos que fueran apareciendo (véase el enfoque de Berkeley frente al del MIT en la entrada de Javier Vela al respecto, ¿Peor es mejor?). La situación actual es algo distinta ya que la capacidad del entorno de encontrar y explotar vulnerabilidades es muy elevada. Por tanto, liberar una aplicación al mercado, especialmente si está destinada a ofrecer servicios al público a través de Internet, sin haber tomado un mínimo de medidas para evitar la aparición de vulnerabilidades, es sin lugar a dudas una invitación al desastre.
La presión por cumplir con el calendario y el presupuesto de proyecto y la exigencia de los usuarios por disponer de nuevas funcionalidades, provocan con frecuencia que la seguridad no esté precisamente en la parte alta de la lista de prioridades de los equipos de desarrollo. Además, la eliminación de vulnerabilidades se suele entender como una tarea de la que alguien se encarga en la fase de testeo al final del ciclo de desarrollo, cuando la fase de programación ha concluido.
Sin embargo, el énfasis que desde distintas organizaciones se está haciendo por incorporar la seguridad al ciclo de desarrollo de software, así como iniciativas en esta línea de grandes corporaciones productoras de software, parece indicar que las tendencias están cambiando. Muchos pensamos hoy que todas las fases del proceso de desarrollo deberían compartir un objetivo: garantizar la seguridad del software.
A pesar de todo, es bastante común que en organizaciones que producen software, no exista ninguna incorporación formal de medidas de seguridad al ciclo de desarrollo. Los motivos son diversos: falta de presupuesto, de concienciación, de conocimiento… La realidad es que en la mayoría de los casos el software se valora fundamentalmente por la funcionalidad que implementa y la calidad del código raramente se considera; hasta que ocurre lo que nadie tuvo en cuenta…
La existencia de defectos de seguridad es hoy por hoy algo inevitable, sin embargo, la incorporación de una serie de medidas al proceso de desarrollo de software, permite reducir el riesgo a unos niveles aceptables. Con este objetivo se puede actuar en distintos puntos del proceso aplicando cada medida en el momento adecuado:
Análisis de requisitos
Resolver problemas de seguridad en un sistema en producción suele ser un proceso muy costoso y en ocasiones, con un alto impacto en el negocio e incluso en la imagen de la organización que ofrece el producto o servicio. Por este motivo, es importante tener en cuenta los controles necesarios para evitar su aparición desde fases tempranas del proceso, considerando los requisitos de seguridad como parte del análisis junto con los requisitos funcionales.
Es importante además no olvidar la consideración de aspectos de conformidad legal que incluyan en el catálogo de requisitos las obligaciones introducidas por regulaciones como la LOPD o la SOX entre otras.
Diseño
El diseño debe considerar aspectos como la reducción al mínimo de la interfaz atacable, así como su protección mediante la introducción de patrones y soluciones adecuadas para evitar la aparición de vulnerabilidades conocidas. En este punto es referencia obligada alguna de las guías existentes (las recomendaciones de OWASP por ejemplo) que recogen las vulnerabilidades más frecuentes junto con medidas técnicas para evitar su aparición.
Análisis de riegos (Casos de abuso y Modelado de amenazas)
Es frecuente que los analistas especifiquen los requisitos describiendo el comportamiento de un sistema “cuando todo va bien”. Esto suele llevar a una visión funcional del sistema basada en la asunción de que no va a ser objeto de abusos intencionados. Nada más lejos de la realidad, si el sistema va a ser usado, con toda seguridad se abusará de él (voluntaria a involuntariamente). El modelado de amenazas se realiza para determinar si el diseño propuesto mitiga los riesgos identificados y permite a los diseñadores ponerse en el papel del atacante:
De esta forma las amenazas se identifican y se priorizan. A continuación se comprueba si la amenaza se mitiga mediante la implantación de un control. Si esto no es posible, se cambia el diseño o se asume el riesgo (idealmente, en función del risk appetite definido formalmente por la organización).
Análisis estático de código
En el pasado, el análisis de código se realizaba únicamente de forma manual. Era un proceso que daba buenos resultados cuando lo realizaba un experto, pero suponía un coste muy elevado. Hoy disponemos de herramientas de análisis estático que son capaces de identificar una buena parte de los errores de código por un coste mucho menor que el de un análisis manual.
El uso de estas herramientas es óptimo cuando todos los módulos que componen el software están completos e integrados. El análisis estático se debería realizar como mínimo en cada integración y siempre antes de liberar una nueva versión.
Testeo (o auditoria) de seguridad
Sería estupendo que el análisis estático fuese capaz de identificar todas las vulnerabilidades existentes en el software, pero desgraciadamente esto no es así. Por este motivo es necesaria la introducción de métodos dinámicos de testeo que interactúen con la aplicación como lo haría un atacante (Penetration Testing).
El testeo de seguridad es similar al testeo funcional del software con la diferencia de que en este caso se busca que la aplicación funcione de formas para las que no ha sido diseñada. El testeo funcional acaba (idealmente) cuando cada “feature” ha sido testeada, sin embargo, no es fácil identificar todas las cosas que una aplicación no debería hacer. Por este motivo es importante seguir una aproximación priorizada en la que se puede tomar como criterio la priorización realizada en el modelado de amenazas.
Existen varias herramientas que permiten la automatización del Penn Testing, pero de nuevo en este caso, será necesario contar con las manos de un experto para testear aquellos aspectos que no es posible automatizar.
¿Cómo empezar?
La incorporación de todas estas medidas, especialmente cuando se parte de una situación de poca cultura de seguridad, puede resultar algo abrumadora. Aunque el objetivo final debe ser que el proceso de desarrollo se enriquezca con todas las aportaciones descritas, no es imprescindible que se adopten todas desde el principio para obtener mejoras significativas en la seguridad del software producido.
La modificación del proceso se puede plantear como un proceso de mejora continua, empezando por aquellas medidas que requieren un esfuerzo y nivel de conocimiento y especialización moderado, para ir incorporando el resto según la experiencia y el know-how de la organización vaya creciendo.
Teniendo en cuenta que, especialmente en este caso, algo es mejor que nada, algunas de las medidas presentadas pueden ser adoptadas inicialmente asumiendo un coste reducido y con un retorno importante. El análisis de requisitos de seguridad puede ser la primera de ellas, garantizando así una toma de consciencia de los aspectos de seguridad a implementar. Por otro lado, la implantación de herramientas de análisis estático desde un principio, permite evitar un cantidad importante de errores y potenciales vulnerabilidades con una inversión muy contenida.
En este post se han presentado algunas medidas que tienen que ver directamente con el proceso de producción de software, pero existen algunas más que aplican al entorno de soporte del proceso (separación de entornos, seguridad de los repositorios de información, control de configuración, etc), pero eso da para otra entrada y lo trataremos en una próxima ocasión. Como siempre, pasen un buen fin de semana.
(Fuente de la imagen: OWASP)
Para hoy, tenemos un par de breves cuestiones relacionadas tangencialmente con la Seguridad de la Información.
En primer lugar, me gustaría presentarles el blog Spring Art Work, un blog mantenido principalmente por nuestro compañero Néstor Tarín, en el que tratará de cuestiones propias de desarrollo en el uso de frameworks —principalmente Spring, tal y como indica su nombre— utilizados para el desarrollo de aplicaciones (java y .Net) de manera cómoda, sencilla y correcta. Se trata de un blog técnico que incluirá artículos de distintos niveles de dificultad, y puede ser útil para comprender conceptualmente el uso de los frameworks presentados desde un perfil no técnico. Inicialmente su periodicidad será semanal, pero probablemente se incrementará a medida que el blog vaya cogiendo velocidad.
En segundo lugar, si llevan algún tiempo siguiendo el blog, sabrán que de un tiempo a esta parte hemos incrementado la frecuencia de publicación hasta hacerla diaria, exceptuando los fines de semana y algún día suelto que la inventiva está por los suelos. No obstante, teniendo en cuenta la relativa densidad de algunas entradas, tenemos cierta curiosidad por saber cuál sería la frecuencia de publicación ideal para nuestros lectores; si estamos llegando, nos quedamos cortos o nos pasamos. De ahí que hayamos creado la encuesta que les muestro debajo.
Mañana continuaremos con la programación habitual.
Continuando con la seguridad del sector eléctrico que iniciamos el pasado lunes, vamos a comentar hoy aspectos relativos a la seguridad en la producción de energía, sobre todo en las áreas funcionales nuclear, térmica e hidráulica; el área funcional de energías renovables (por ejemplo, parques solares o eólicos) sufre menos amenazas y de menor impacto, siendo quizás el robo el mayor de los problemas a los que se enfrentan estos parques, cuya probabilidad se multiplica por su ubicación en lugares relativamente aislados.
Quizás las amenazas de mayor impacto en la producción eléctrica son las relativas a accidentes (fuego, fugas, explosiones…) y las relativas a terrorismo (bombas —físicas o lógicas, pero especialmente las primeras—, ataques con munición pesada, sabotajes…); en el caso nuclear es tal la preocupación general por el correcto funcionamiento de las centrales, debido a las implicaciones de un incidente, que existen normas nacionales e internacionales para garantizar su seguridad a diferentes niveles. En el caso de España, se considera poco probable un ataque de gran magnitud hacia una central nuclear por parte de ETA —sobre todo porque no resulta fácil para la organización terrorista hacer estallar un artefacto de magnitud sin poner en peligro la vida de sus miembros, y además porque un ataque indiscriminado de esa magnitud podría generar una movilización sin precedentes de repulsa social hacia la banda—; no obstante, las centrales nucleares sí que pueden convertirse en objetivo del terrorismo islámico, además de ser un objetivo prioritario en conflictos bélicos con otros países.
Aunque la seguridad de la información es crucial en todas las áreas funcionales de la producción eléctrica, desde la nuclear hasta las energías renovables, es especialmente en el caso de la producción nuclear donde la protección de la información es crucial, sobre todo su confidencialidad: todos los países están interesados en obtener información nuclear, especialmente de ensayos, del resto del mundo, y están dispuestos a gastarse mucho dinero para obtener estos datos. Y esto aplica tanto a los soportes digitales como al soporte papel, y por supuesto también al soporte “cerebro”: es especialmente importante controlar el conocimiento que ciertas personas pueden tener sobre el proceso, las instalaciones, etc., así como blindar —contractual, económica, legalmente…— su vinculación con la empresa hasta cierto punto.
Como amenazas particulares en la producción hidráulica, nos encontramos ante las catástrofes naturales (rayos, inundaciones, desprendimientos…) a las que, por la ubicación física de las centrales, éstas se encuentran expuestas; es menos habitual el ataque terrorista, ya que aunque se trata de ubicaciones perfectas para el ataque (aisladas y de difícil acceso, no vigiladas…), la repercusión que tendría el mismo no sería muy elevada salvo en el caso de voladura completa de la presa, para lo cual se necesitarían grandes cantidades de explosivos. En estos casos, se añade también la amenaza de robo, ya que no suele haber personal en muchas centrales, y mucho menos personal de seguridad, por lo que los materiales de la central se convierten en un objetivo fácil para los ladrones (sobre todo el cobre).
Para finalizar es necesario hacer referencia, sobre todo en el caso de la producción nuclear, y en menor medida, en la producción térmica, a las amenazas relativas a vandalismo y revueltas, por la polémica que sobre todo el uso de la energía nuclear siempre genera: manifestaciones, actos vandálicos… que por lo general no se materializarán en problemas de gran impacto, pero sí que pueden dañar elementos estructurales de protección —típicamente, del perímetro— o incluso paralizar la producción durante un tiempo indeterminado: intrusiones por parte de activistas, bloqueo del paso de mercancías o personas, etc.
Con poco que hayan seguido este blog, sabrán que no hacemos un uso comercial de éste, primero porque no nos gusta, segundo porque existe contenido mucho más interesante, tercero porque no es ese el propósito de un blog, y por último porque eso supondría ahogarlo irremediablemente. Dicho esto, no obstante, en este caso nos disculparán si hacemos una excepción, que en mi opinión está justificada.
S2 Grupo ha iniciado un ciclo de conferencias y cursos especializados en la línea del trabajo que desarrolla, y en este sentido, para el próximo mes de diciembre (concretamente, 14, 15, y 16 de diciembre) hemos organizado, en colaboración con New Horizons (actualmente Tecnofor), el segundo curso de formación especializada en ITIL e ISO 20000 con certificación APM GROUP opcional al finalizar la acción formativa. El curso consta de un módulo de Introducción al código de buenas prácticas ITIL, una revisión a la norma internacional ISO/IEC 20000 y un caso práctico de Gestión de Incidencias basado en lo sucedido en el Apollo XIII.
A diferencia de la mayor parte de los cursos, para los que es necesario desplazarse a Barcelona o Madrid, éste se impartirá en las nuevas instalaciones de S2 Grupo en Valencia (C/ Ramiro de Maeztu), lo que supone un ahorro considerable en desplazamiento y alojamiento para aquellas personas o empresas cercanas a Valencia y que estén interesadas en asistir a un curso de este tipo. Los cursos se imparten en grupos reducidos para poder sacar el máximo provecho.
Pueden obtener más información de los anexos que se incluyen a continuación, mandando un correo a formacion [en] s2grupo.es, o llamando al 96 3110300. Mañana retomaremos la programación habitual.
Más información: [Información del curso] [ITILv2] [ISO 20000] [Caso práctico: Apollo 13]
En enero realizaremos un curso de similares características basado en ISO 27001, del que les daremos detalles más adelante. No obstante, si podrían estar interesados y desean información sobre éste, ya conocen los datos de contacto.
