Ante todo mucha calma

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.

[Read more…]

enise: III Encuentro Nacional de la Industria de la Seguridad en España

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í.

Bromas aparte, 180 han sido los ponentes. Tal vez demasiados porque no daba tiempo a que contasen mínimamente lo que estaban haciendo. Muchas conferencias; unas interesantes y otras prescindibles, sobre todo cuando el ponente se dedicaba a “contar su libro”; aunque se les había dicho explícitamente que no era un espacio en el que tuviese sentido hacer publicidad de sus empresas o productos, la verdad es que en algunas ocasiones se hacía caso omiso a esta recomendación. En mi opinión, “craso error” porque el efecto que se consigue en los asistentes es el contrario del que pretende. Al hacer esto parece que no tengan nada interesante que contar en un espacio en el que teóricamente se debe hablar de innovación tecnológica en seguridad TIC.

Echo en falta, por parte de la organización, y lo digo como crítica constructiva, una evaluación de los ponentes por parte de los asistentes que sirva de base para filtrar, en futuros “enises”, las conferencias y los conferenciantes y, tal vez, un filtrado temático por parte del equipo organizador. Por el contrario, la logística del equipo de INTECO espectacular. Una organización que en mi opinión no merece crítica alguna. ¡¡Enhorabuena a todo el equipo de Inteco!!

Personalmente me parecieron muy interesantes, en general, los puntos de vista de miembros de las fuerzas y cuerpos de seguridad del estado, de las fiscalías representadas y de magistrados que también participaron; todo un acierto por parte de INTECO. No es habitual encontrar a estas personas, con un papel tan importante en el proceso de la seguridad, opinando sobre pruebas, leyes, procedimientos, tecnologías, etc. Mi conclusión al respecto es un poco desalentadora: vivimos en mundos distantes, aunque gracias a personas como las que tuvimos la suerte de escuchar en las conferencias es posible que consigamos construir puentes entre ambos mundos.

Me llamaron mucho la atención las mini-conferencias de D. José Manuel Maza, magistrado del tribunal supremo y de D. Jorge Bermúdez, miembro de la Fiscalía provincial de Guipúzcoa. Desde el punto de vista de la conferencia en sí, ambas fueron en dos palabras “im-presionantes”. En primer lugar por la capacidad de síntesis y facilidad de exposición, y en segundo lugar por la claridad con la que presentaban asuntos delicados; aunque decían ser legos en la materia, no tenía desperdicio nada de lo que decían al respecto. Les recomiendo que si en alguna conferencia leen estos nombres como ponentes, acudan a escucharlos, merece la pena.

Universidad, Instituciones e Industria estaban también representadas en el encuentro. Tuvimos la oportunidad de asistir a un fugaz y amargo debate entre Universidad e Industria protagonizado por D. Gianluca D’Antonio, Presidente de ISMS Forum y CISO de FCC, con el catedrático de la Universidad Carlos III de Madrid, D. Arturo Ribagorda, en el que la Industria en general, representada por Gianluca, se quejaba de lo divergente del camino que está recorriendo la Universidad, alejada de los intereses reales de la sociedad y de la industria, al menos en la materia que nos ocupa. La verdad es que, como miembros de la industria de la seguridad, nos sentimos muy identificados con las palabras expresadas por el Presidente de ISMS Forum. A nosotros, en Valencia, nos cuesta mucho encontrar grupos de investigación dentro de las universidades que estén desarrollando su actividad en estos campos. Si alguno de los lectores conoce algún equipo de investigación en alguna de las universidades de la Comunidad Valenciana con ganas de participar en proyectos de innovación e incluso de I+D con aplicación práctica, le agradeceríamos nos lo hiciese saber con un comentario a este post o enviando un correo a info@s2grupo.es. Le estaríamos eternamente agradecidos.

Desde el punto de vista institucional tuvimos también la suerte de escuchar, entre otros, a D. Miguel Ángel Amutio, hablando en nombre del Ministerio de la Presidencia de “su” Esquema Nacional de Seguridad, e incluso pudimos comentar con él, después en la comida, los avatares del mismo. Siempre es un placer escuchar a una persona tan serena y docta como él hablando de algo que nos va a afectar a todos directa o indirectamente. Nótese que lo de “su” ENS lo digo en tono de broma ya que durante la comida protestaba precisamente por el hecho de que algunas personas se referían en esos términos al ENS, mientras que él defendía que detrás del mismo hay mucha gente trabajando y aportando su conocimiento y buen hacer. Por lo que nos contó en su charla parece que tenemos el ENS a la vuelta de la esquina con todo lo que esto conlleva (véase las últimas entradas de Sergio sobre el ENS: [1][2]).

Las entidades de clasificación y certificación tuvieron también sus espacios en las jornadas. D. Carlos Manuel Fernández, Responsable de la Certificación de Sistemas de Gestión de la Seguridad de Información de Aenor, compartió con los asistentes la hoja de ruta de la entidad en aspectos relacionados con las Tecnologías de la Información y Comunicaciones en general y con la Seguridad en particular.

En definitiva y por no extenderme más de la cuenta, creo que enise es, para los que de una u otra forma conformamos la industria de la seguridad en España, una cita anual obligada. También creo, y lo lanzo como reto a los organizadores, que se podría utilizar este encuentro como un catalizador de la concienciación en materia de seguridad en toda España y que precisamente por este motivo debería plantearse la necesidad de que enise fuese un evento itinerante, al margen de que la sede de INTECO, entidad que tan bien lo organiza, sea León.

Lanzo este reto a enise y a sus organizadores de INTECO y me brindo, desde S2 Grupo, a apoyar y a ayudar a INTECO a organizar este evento en Valencia el próximo año.

En definitiva, nuestra más sincera enhorabuena por el éxito del evento al Director General de INTECO, D. Víctor Manuel Izquierdo y a todo su equipo que tan de cerca han seguido el desarrollo del encuentro. Queda en el aire ese ofrecimiento…

Por cierto, coincido plenamente en las palabras de Víctor Manuel Izquierdo en la sesión inaugural: “La innovación es un imperativo categórico en materia de Seguridad”. Seguiremos contando algunas cosas de lo que en este encuentro aconteció.

(Tienen algunas de las ponencias en la página del enise: [Día 27][Día 28][Día 29])

El Esquema Nacional de Seguridad (II)

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.

[Read more…]

Titanic

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:

  • El 95% de las mercancías que entraban o salían del país se introducía mediante transporte transoceánico.
  • Las aduanas norteamericanas sólo inspeccionaban el 2% de los 16 millones de contenedores que llegaban cada año. Apenas había ningún tipo de control respecto al 98% restante.

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.

Seguridad sectorial (V): eléctricas. Control

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)

BAM, o las bondades de la monitorización (un ejemplo tonto).

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 primer lugar, aunque en la empresa tenemos dispensadores de agua mineral, la máquina en cuestión dispone de dos filas con botellas de agua mineral. A pesar de las indicaciones que se han dado de que nunca, nadie, por ninguna razón comprará una botella, ahí siguen. Es decir, hay productos que aunque nadie consuma, se mantienen. Como suele decirse, me lo expliquen.
  • Soy un adicto al Kinder Bueno, lo reconozco. Un Kit-Kat sirve de reemplazo decente, pero no es lo mismo. En cualquier caso, esos significa que esos dos productos se agotan con mucha más rapidez que la mayoría del resto de productos de la máquina. A pesar de ello, cuando la fila de mi producto favoritoTM se agota, en lugar de volver a poner Kinder Bueno, es reemplazado por otro (Kit-Kat en el mejor de los casos, pero no siempre). En este caso, lo que tenemos son dos problemas: no hay un seguimiento de los productos que más se consumen, y a causa de ello éstos se sustituyen por otros de consumo inferior, interrumpiendo tanto el componente de fidelización (i.e. la costumbre voy a la máquina a por algo), como desaprovechando el beneficio potencial de la instalación.
  • En tercer lugar, hay productos que durante los meses que la máquina ha estado instalada apenas han sido consumidos, y cuya fila se agota mucho más lentamente que la de los productos más habituales. Por poner un ejemplo concreto, poca gente bebe Fanta Naranja/Limón. No me pregunten porqué; la gente tiene gustos particulares. En el otro lado, la Coca-Cola se agota a unas velocidades de vértigo. Sin embargo, ahí siguen esas filas desaprovechadas (a pesar de los esfuerzos del personal de Administración por intentar hacer entender al reponedor de la máquina lo que es lógico). Sí, quizá a alguien le apetezca beberse una Fanta en el solsticio de verano, pero qué c***, esto no es un asunto de igualdad de oportunidades; es un simple refresco. Seguro que la Coca Cola le va bien, y si no que beba agua o que beba Fanta más a menudo (discúlpenme los amantes ocasionales de los refrescos de naranja y limón).

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):

  • En primer lugar, realizar un control estricto del consumo de la máquina. Retirar los productos que no se consumen o apenas se consumen, incrementar el espacio dedicado a productos que se agotan rápidamente, y escuchar a los clientes (podría plantearse preguntar a la organización donde la máquina se instala un conjunto de productos inicial, a completar por la empresa de vending). La cuestión aquí es que nadie compra una botella de agua mineral por 50 céntimos si tiene botellas de 30 litros gratis distribuidas por la empresa. Nadie en absoluto. Véase el problema de las discográficas para más detalles de porqué la gente no quiere pagar por algo que tiene gratis (dejemos de lado los detalles, ya que está claro que la ADSL no es gratuita).
  • Por supuesto, llegar a un conjunto de productos semi-óptimo en términos de consumo lleva un tiempo, aunque el proceso podría acelerarse si se consultase a los clientes, y durante los dos primeros meses las visitas del reponedor fuesen semanales, en lugar de quincenales o cada tres semanas. Eso facilitaría que una vez alcanzado un nivel de estabilidad, las visitas pudieran pasar a ser mensuales.
  • Monitorización del consumo de la máquina. Hay varias opciones para realizar esto. Por supuesto, un sistema autónomo que de manera periódica remitiese vía módem GSM la ocupación de la máquina a central sería lo mejor; eso optimizaría los viajes de los reponedores. No obstante, eso implicaría al fabricante de las máquinas (aunque no estoy familiarizado con el estado del arte de este tipo de máquinas, seguro que ya existen modelos que disponen de esta funcionalidad), y quizá aumentaría el tiempo de amortización de la instalación al incrementar el coste (aunque reduciría los desplazamientos de los reponedores, por lo que sería necesario estudiarlo en profundidad). La segunda opción podría ser una pistola RFID donde el reponedor apunta los consumos realizados desde la última visita, y los descarga al llegar a central. Por último, tenemos el caso más simple: lápiz y papel, y los datos pasados manualmente al llegar a central; un fastidio, pero tecnológicamente barato de adquirir y mantener.
  • ¿Qué hacemos con los datos obtenidos? Muy sencillo. Para cada una de las máquinas que gestionamos, detección de productos cuyo porcentaje de consumo es inferior o superior a unos umbrales predeterminados, líneas de tendencia, y rentabilidad por instalación. A partir de ahí, cada reponedor podría disponer de una planificación semanal detallada y semi-automátizada de dónde y cuándo ir, así como qué llevar. Llevando el ejemplo un poco más allá, podría ser interesante, en función de la dispersión y volumen de instalaciones, incluir temas de investigación operativa en la que optimizásemos las rutas de los reponedores.

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).

El Esquema Nacional de Seguridad (I)

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:

«42.2. El Esquema Nacional de Seguridad tiene por objeto establecer la política de seguridad en la utilización de medios electrónicos en el ámbito de la presente Ley, y está constituido por los principios básicos y requisitos mínimos que permitan una protección adecuada de la información.»

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.

Anécdotas del kernel de Linux: SysMagic

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).

[Read more…]

Incorporando la seguridad al proceso de desarrollo de software

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:

  • ¿Qué partes del sistema son más fáciles de comprometer?
  • ¿Cuál es el impacto?

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)

Spring Art Work

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.

[poll id=”17″]

Mañana continuaremos con la programación habitual.