Esta tarde los compañeros de AVADISE organizan, en la Universidad Politécnica de Valencia, una jornada sobre la Ley de Seguridad Privada (Ley 5/2014, de 4 de abril de 2014): la nueva LSP. Vamos a participar en una mesa redonda junto a representantes del SEPROSE (Guardia Civil) y la UCSP (Cuerpo Nacional de Policía) a la que han invitado a diferentes representantes de la Seguridad Privada, en el sentido más amplio de ésta. Y este amplio sentido incluye, por supuesto, la ciberseguridad, seguridad informática, seguridad de la información… o como ahora le llamemos a “esto”.

La nueva LSP se publicó hace algo más de dos meses y en ella se hace referencia directa a los servicios de seguridad informática (en muchos blogs de seguridad se habló del tema en su momento); el Reglamento de Desarrollo regulará ciertos ámbitos de nuestra actividad, lo cual a priori, al menos bajo mi punto de vista, es muy interesante (otra cosa será lo que el Reglamento depare en su momento, que ya discutiremos).

La anterior LSP data de 1992; 22 añitos han pasado entre una y otra, periodo que desde un punto de vista legal no es nada (ahí tenemos la Ley de Enjuiciamiento Criminal, con alguna revisión pero que data de 1882 -sí, 1882-) pero que, en seguridad, es una eternidad. A principios de los 90 no sabíamos lo que era el phishing, el grooming, el timo nigeriano ni nada de eso -al menos no con esos nombres-; no teníamos media casa conectada a Internet (con suerte un módem que encendíamos por la noche con miedo a la factura telefónica para tirar a una BBS o a algún dialup de estrangis); no teníamos móviles, ni tabletas, ni USB ni nada parecido. Parece claro que las cosas han cambiado bastante, y la legislación tiene que ir adaptándose a ello, a los nuevos delitos -o a los delitos clásicos cometidos con nuevos medios- y, especialmente, a los nuevos roles en el mundo de la seguridad.

Y es que no es de recibo que para vigilar el perímetro físico de una fábrica de cerámica se requiera un determinado perfil y para auditar las tripas de la tecnología sobre la que se basa una central nuclear no se pida nada oficial. No se trata de comenzar de nuevo el flame de si esto lo puede/debe hacer un Ingeniero Informático, un CISA, un CPP, un Director de Seguridad Privada o un tipo de Cuenca que se tiene que llamar Paco. Se trata de que alguien con la suficiente autoridad determine de una u otra forma quién puede hacerlo y bajo qué circunstancias (y con qué responsabilidades, que muchas veces nos gusta olvidarnos de este tema) y a partir de ahí discutiremos.

Sé que el CCN está trabajando ya en un esquema de acreditación de personas para definir roles de trabajo en el ámbito de la seguridad, al margen de certificaciones generalmente estadounidenses que nos pueden gustar más o menos, pero no son “nuestras”. Desconozco los detalles y el estado de esta iniciativa, también interesante (si alguien los sabe, se agradecerán ;), y por supuesto no sé si la LSP tratará de aprovechar este trabajo -no lo sé, pero lo intuyo-. En cualquier caso, tendremos que estar atentos a ambas líneas, porque provienen justamente de dos de los actores que bajo mi punto de vista deben marcar las pautas de ciberseguridad en España, cada uno en su ámbito de actuación, por encima de empresas, asociaciones, grupos de interés y demás (escuchando la opinión de éstos, por supuesto, pero con independencia).

Esperaremos a ver qué nos depara el Reglamento de Desarrollo; aprovechando que esta tarde estará por la jornada Esteban Gándara, Comisario Jefe de la UCSP y uno de los padres de la criatura, pediré pistas sobre el rol de la seguridad informática en ese nuevo Reglamento. Seguro que da para algún post más :)

La verdad es que el post del día uno de abril quedó algo descafeinado… La versión inicial era más gore, sin referencias a si hoy no fuera el día que es, con noticias de periódicos de verdad (La Nueva España y La Voz de Asturias eran los elegidos) e incluso con alguna foto de una vaca con el estómago reventado, que eso siempre ayuda a comprender el problema. Pero por una cuestión o por otra se descafeinó y se veía a la legua que era un hoax (quizás también influyó en esto la serie de posts anteriores ;) Eso sí, se movió bastante por redes sociales, y parece que resultó interesante o al menos le pareció curioso a más de uno; hasta los de @48bits hicieron alguna referencia a las vacas en Twitter ;)

Si no lo hubiéramos descafeinado tanto, habría sido más creíble; el objetivo era hacer un bulo para el día uno de abril tocando, en primer lugar, la fibra sensible (una vaca con el estómago reventado como que llama la atención) y después metiendo diferentes técnicas de persuasión de las que habíamos visto. Algunas de ellas:

• Acercamiento al mundo real, citando fabricantes “de verdad”, tanto de PLC como integradores, poniendo unas coordenadas reales, en una zona conocida y que además coincide con la que hemos especificado al principio, zona norte de España. Y capturas “tocadas” de sistemas SCADA.
• Autoridad: nuestro amigo imaginario lleva muchos años en esto de la tecnología y además dirige el ámbito de ciberseguridad en explotaciones agropecuarias, vamos, que a priori no es un recién llegado y sabe de lo que habla…
• Experiencia, objetivo de los primeros párrafos: sabemos de animales. Sabemos matar animales, sabemos que una vaca muere si hace lo que decimos y con esto hacemos creer que en zonas de España es habitual la explotación aislada -realmente, creo que no es así, aunque sí que es normal tener las vacas en la montaña sin vigilancia humana directa, sueltas-. Por cierto, lo de las vacas que revientan, según tengo entendido es si comen determinada hierba que luego fermenta en el estómago… creo, tampoco es que me haya preocupado mucho…
• Respaldo de terceros, con la publicación de las noticias en dos medios independientes de SAW (aunque, como hemos dicho, inventados).
• Sugestión, acabando con el mensaje “si yo fuese un ganadero, me preocuparía” (vale, metemos lo de “y no fuera hoy el día que es”, para dar una pista, pero podríamos haberlo eliminado).

Evidentemente no se trata de hacer un hoax aplicando todas las técnicas de persuasión a la vez, como ya dijimos, sino de seleccionar varias e incluirlas en el bulo para darle realismo y conseguir que la gente lo reenvíe, hable de él o similares. No sé si lo hemos conseguido, aunque a primera vista sí que parece una historia coherente, ¿no? Ojo, coherente para un profano en la materia, no para un experto en seguridad, en sistemas de control, en explotaciones agropecuarias o en temas similares…

Si hubiéramos sido más crudos, seguro que se lo habría creído más gente. No obstante, a pesar de ser obviamente un hoax, sí que hubo alguno que picó; me han llegado comentarios del tipo “oye, y eso lo habéis denunciado” o un whatsapp de un amigo diciéndome literalmente lo de “Toni, tío, dime que lo de las vacas no es verdad”. En fin, que hay gente pa to :) Eso sí, ¿podría ser real? Por supuesto, no lo vamos a probar, aunque matar cien vacas creo que no es lo peor que nos puede pasar con los sistemas de control conectados a Internet…

P.D. Perdón por no responder a los comentarios del post de las vacas, pero mejor no dar señales de vida en el momento para decir si es un hoax o no…

Hace unas semanas quedamos unos antiguos amigos para tomar unas cervezas en Madrid; viejos conocidos con los que en su momento compartí muchas noches conectado, y de los cuales algunos seguimos aún hoy trabajando en temas de seguridad. Con unas copas todo es más distendido, y hablando con Javi (nombre ficticio, of course) sobre cómo cambia todo con los años y las vueltas que da la vida, me estuvo contando cosas que, sinceramente, me dejaron un poco fuera de juego.

Y es que lo que estaba investigando en su trabajo (dirige la parte de seguridad de una empresa de automatización agrónoma) era cómo “ciberproteger” al ganado, porque matar animales por Internet es técnicamente posible aprovechando granjas conectadas a la red; esto lo habían investigado… y lo estaban probando. Por supuesto, le pedí que escribiera un post para SAW, de forma anónima, y lo que me remitió me dejó más fuera de juego todavía que lo que me contó esa noche… Ahí va, juzguen ustedes mismos…

—-

Matar a un animal en el ámbito físico es fácil, sobre todo los que no están sometidos a un control humano directo: si me acerco a un rebaño de ovejas con el pastor delante e intento degollar a una de ellas, seguramente el buen hombre o sus mastines acabarán conmigo… Si hago eso mismo en alta montaña, donde el ganado puede pasar días sin vigilancia humana —y si no están los mastines cerca, dicho sea de paso— la oveja no tiene nada que hacer. Es habitual, en zonas frías del norte de España (me vienen a la cabeza la zona oeste de Zamora y de León, el este de Galicia, la Cordillera Cantábrica…), dejar el ganado en las montañas durante días —semanas si la nieve impide subir a visitarlo—; aunque hace años los animales campaban a sus anchas, en la actualidad lo más normal es confinarlos en corrales donde, de manera automática, se les suministra agua y alimento, y además se les protege físicamente con cámaras y alarmas (el robo de ganado está a la orden del día). Evidentemente, estos sistemas de seguridad o de abastecimiento son completamente autónomos, e incluso se alimentan con energía solar para no depender de generadores de gasóleo. La duda que un técnico se plantea es… ¿habrá entornos de abastecimiento manejados por sistemas de control industrial… y conectados a Internet? Veremos que sí :)

Pero, ¿qué tiene que ver esto con la seguridad? Muy sencillo; hay animales que comen mientras tienen hambre, dejando de hacerlo una vez están saciados aunque tengan comida a su alrededor —por ejemplo, los gatos—, mientras que otros son capaces de comer hasta reventar, como muchas razas de perro. Un término medio son las vacas: el ganado vacuno pasta habitualmente de forma tranquila, pero si tiene hambre es capaz de hincharse demasiado (y eso sabemos que sienta mal). Si tenemos un rebaño sin comer ni beber durante un par de días y posteriormente les dejamos pastar, comerán mucho más de lo que deben. Y si ese alimento es grano, no hierba, y encima no les damos agua hasta que no han comido, sucede una cosa curiosa: la vaca comerá mucho grano porque tiene hambre, lo que incrementará su sed. Si cuando haya comido mucho grano, le dejamos beber agua, beberá mucha agua, que al mezclarse en el estómago del animal con la gran cantidad de grano producirá un efecto, digamos, curioso: el grano se hinchará y el estómago de la vaca reventará. ¿Y? Podemos intentar hacer esto de forma remota; para lograrlo sólo necesitamos unas cuantas cosas: un corral aislado sin presencia humana diaria, de esos del norte de España, con unas tolvas de grano y unos depósitos de agua controlados por SCADA y que ese mismo SCADA esté conectado a Internet. A buscar…

Lo primero que tenemos que hacer es averiguar si realmente hay sistemas SCADA que controlen la alimentación de explotaciones agropecuarias para, si existen, tratar de explotarlos. Utilizando nuestro buscador favorito podemos darnos cuenta de que sí que hay sistemas de este tipo y es más, pueden conectarse a Internet, generalmente a través de GPRS o radio; estos sistemas controlan tanto el silo donde se almacena el grano como la bajada de pienso a los comederos, así como la dosificación de agua para las reses. Muchos fabricantes están metiéndose en este negocio, porque parece ser que es bastante rentable (sobre todo en Estados Unidos y Australia) y, dicho sea de paso, lo hacen con la misma alegría y despreocupación con la que se meten en otros negocios donde conectan todo a Internet sin mayores problemas… en principio :) Uno de estos fabricantes es Automatic Farm Systems (http://www.afsproducts.com), estadounidense, cómo no, y uno de sus productos estrella son los silos donde se almacena —y con válvulas se dispensa— el grano (http://afsproducts.com/sites/default/files/file/Bulk%20Feed%20Tanks.pdf) así como las trituradoras para dárselo al ganado (http://afsproducts.com/sites/default/files/file/Hammermils.pdf). Recordemos, tenemos que evitar que se triture el grano para hacer efectivo el ataque.

Pero al igual que muchos fabricantes industriales, Automatic Farm Systems no fabrica la parte de automatización de sus productos: otros lo hacen por él. En el caso que nos interesa, un integrador destacado es Wilson Groom (http://www.wilsongroom.com), que ha desarrollado software ad hoc que habla con los productos de AFS, en concreto con los PLC de Allen-Bradley (Rockwell) que éstos incorporan, y que permiten el control de una explotación agropecuaria (¡oh, sorpresa!) desde Internet (literalmente, su publicidad indica que “it can be remotely accessed via any web browser, providing access from a wide variety of PC-based and smartphone platforms”). Vamos, que tenemos que buscar PLC de Rockwell, los usados por AFS, en España, y luego averiguar si se trata de una explotación o no. Resumiendo mucho este proceso, podemos empezar con Shodan buscando las firmas de estos PLC (hay varias, que no vamos a poner aquí, obviamente) y restringiendo nuestra búsqueda a España (country:ES); pero los PLC de Rockwell se usan para muchas cosas. ¿Cómo llegar a determinar que el PLC controla una explotación o no? Hay dos formas: la aproximada es usando Shodan; cuando el buscador es capaz de geolocalizar una IP hasta su ciudad, lo indica, mientras que si no es capaz, el campo está vacío:

Por supuesto, esto no es muy científico, pero bueno, es una primera aproximación. La segunda me gusta más: revisando las especificaciones técnicas de los productos de Wilson Groom (el integrador, ¿os acordáis?), disponibles en su web, vemos que esta gente utiliza una aplicación para mantenimiento remoto, contra sus propios sistemas desplegados en campo, que “por seguridad” no va a través del puerto 80, como va el acceso al sistema de control, sino que va por el puerto 9090/tcp, con usuario y contraseña, eso sí :)

Así, tenemos que buscar direccionamientos de PLC Rockwell en España, y que tengan el puerto 9090/tcp accesible. Volcamos la búsqueda de Shodan a un fichero, sacamos las direcciones IP y a partir de éstas buscamos direccionamientos con el 9090 abierto; una línea de script y obtenemos al menos diez dispositivos de control conectados a Internet que cumplen estas condiciones en España, de los cuales siete están sin geolocalización concreta (por debajo del país) en Shodan… estos serán nuestros objetivos principales (si alguno falla, iremos a por los geolocalizados).

La instalación de los PLC de Rockwell tiene, como tantos otros, un usuario web por defecto, con privilegios de control total sobre el sistema (de nuevo, no doy usuario y password, pero se puede obtener de listas de contraseñas públicas disponibles en Internet). Accedemos a uno de ellos que tiene esta configuración y que, aunque Shodan no geolocaliza, localizadores de IP —con la fiabilidad que éstos tienen, que es discutible— fijan en Asturias, fuera de las grandes ciudades y muy cerca del Parque Natural de Somiedo (una zona preciosa, dicho sea de paso):

Bien, parece que nos vamos acercando. Con las credenciales por defecto accedemos a lo que es un interfaz de un sistema de control de una granja real. Pero, ¿cómo podemos saber que se trata de una granja de ganado vacuno y no de pollos, por ejemplo? Evidentemente, prueba y error. La verdad, no sabemos si aparte de unas vacas hemos perjudicado a gallinas, cerdos u ovejas, aunque creemos que no, porque estos animales no suelen ubicarse lejos de zonas urbanas: los cerdos o las gallinas no se dejan en el monte durante días y días, sino que están en granjas o corrales cerca de los municipios. En fin, es un proceso, como decimos, de prueba y error, pero confiamos en que nuestra granja sea vacuna.

Ahora toca buscar cómo cortar el grano y el agua que el sistema proporciona a los animales, cruzar los dedos y ver si funciona; en los PLC de Rockwell tenemos un usuario por defecto, “administrator”, con una contraseña también por defecto, que no vamos a poner aquí pero todo el mundo conoce :) Como en muchas instalaciones, en la nuestra podemos probar si estas credenciales funcionan. Y sorpresa. SÍ que lo hacen:

¡Estamos dentro! Ahora tenemos que buscar dónde se controla la dispensación de agua y grano a los animales; para ir rápido, los manuales de la aplicación de control (como siempre, disponibles públicamente en la web del fabricante) nos son de gran utilidad; tenemos que llegar a la pantalla correspondiente:

En ella, en el menú superior del interfaz, tenemos todos las opciones de control de la alimentación; utilizaremos CLOSE tanto para la tolva de grano como para el depósito de agua, quedando entonces así:

Vemos que se resalta en rojo el indicador, porque desde luego cortar agua y alimento a los animales, bueno, bueno, no parece a priori… ¿Qué queda ahora? Esperar. Cuarenta y ocho horas, para ser exactos. Trascurrido este tiempo, abrimos el dispensador de la tolva de grano:

Esperamos un rato a que los animales coman lo suficiente para quedarse satisfechos… eso sí, sin agua, y, por ejemplo seis horas después, abrimos el depósito, volviendo a la situación normal:

Ahora sólo queda esperar a que la naturaleza siga su curso. A priori, las vacas habrán comido mucho grano y ahora beberán agua en cantidad, con lo que teóricamente, llegamos al resultado que buscábamos. A los animales les reventará el estómago (esto lo he visto personalmente y no es lo más agradable de mundo, créanme).

Realmente, no podemos saber si hemos tenido éxito, es decir, si hemos matado por Internet. Pero como las noticias vuelan, y más en zonas donde la ganadería es un pilar fundamental de la economía, durante los días posteriores a nuestra prueba consultamos la prensa local de la zona. En el diario “La Nueva Asturias” nos llamó la atención la siguiente noticia, fechada en febrero de 2014.

También nos llamó la atención la misma noticia en “El Cantábrico”, un diario del norte.

¿Fallo en el sistema de alimentación? ¿Larga agonía? ¿Casualidad? No lo creo :) Parece que hemos logrado nuestro objetivo: matar a través de Internet. Vacas, no personas, por supuesto. Evidentemente este artículo resume bastantes horas de trabajo —no todo sale a la primera, pero tampoco se trata de detallar todos los problemas técnicos o no técnicos que nos vamos a encontrar en el camino— y da una visión muy simplificada del proceso, pero creo que ilustra bien la situación actual. He tratado de ocultar detalles técnicos que faciliten a un tercero repetir el ataque, aunque cualquiera con algo de tiempo y unos conocimientos mínimos podría realizarlo o, lo que es peor, automatizarlo por completo…

Es cierto que estas pruebas son un problemón para el ganadero, al que tratamos siempre de localizar para compensarle anónimamente por nuestros análisis (lo que tiene el tema agropecuario es que somos cuatro gatos y nos conocemos todos), pero creo que la prueba de concepto ha valido la pena. También nos hemos puesto en contacto tanto con el fabricante de los PLC como con la empresa que ha desarrollado los SCADA para informarles de estos problemas, pero en fin, que si yo fuera ganadero, y si además hoy no fuera el día que es, me preocuparía…

Ya dijimos en el anterior post de la serie que íbamos a fabricar un hoax; lo primero que queremos hacer es tocar la fibra sensible. ¿El dinero? No, la salud :) Queremos convencer a nuestros objetivos que correr más de diez kilómetros al día es perjudicial para ellos, aplicando algunas técnicas de persuasión sobre esta idea…

La primera, autoridad: que correr es malo no lo digo yo, que no me gusta el deporte, sino que lo dice un afamado médico especializado en la materia: el Dr. James Hetfield (que en sus ratos libres canta en un grupo amateur que está empezando en esto de la música y se llama Metallica… no sé si con ese nombre triunfarán algún día ;).

Este médico, que es el que opina que correr más de diez kilómetros al día es perjudicial para la salud, trabaja en un centro de reconocido prestigio como el UPMC (University of Pittsburgh Medical Center), un centro estadounidense real y, por lo que parece, de lo mejorcito en Medicina del Deporte (Google says). Estas son sus palabras iniciales:

[Read more…]

Hablábamos en el anterior post de la tecnología persuasiva; veamos cómo un hoax simple y conocido por casi todos usa diferentes técnicas de las que comentábamos en ese post. Podemos utilizar como ejemplo un bulo que lleva circulando años a través del correo electrónico y que incluso a día de hoy sigue recibiendo un número considerable de gente (yo lo recibí por última vez hace unos meses, gracias a una amiga que se encarga de propagar este tipo de bulos): el de la donación urgente de sangre en cierto hospital, con las diferentes mutaciones que ha sufrido a lo largo del tiempo y que incluso ha obligado a hospitales reales a desmentir oficialmente la información. Viene a ser algo como lo que pone en el enlace anterior:

MENSAJE URGENTE DESDE EL HOSPITAL UNIVERSITARI I POLITÈCNIC  LA FE DE VALENCIA
Si conocéis a alguien que tuviera el grupo sanguíneo AB dispuesto a donar sangre, decidlo. En el Hospital Universitario La Fe de Valencia hay un niño de 10 años ingresado con LEUCEMIA que necesita urgentemente unos 12 donantes. Este grupo sanguíneo (AB) es bastante raro, de ahí el hecho de la falta de donantes. Los médicos anuncian que si los encontraran sería muy posible salvarla vida de este niño. Por favor, reenvía este correo a quien conozcas. El teléfono de la madre (María Ángeles 963XXXX).
 
En estas pocas líneas podemos identificar algunas técnicas de persuasión de las que hemos visto en el post sobre tecnología persuasiva:

• Respaldo de terceros. El mensaje viene de un hospital reconocido, al que además se cita con su nombre “largo” para darle un toque de oficialidad (nadie llama a este hospital “Universitari i Politècnic”; creo que todo el mundo le llama simplemente “La Fe”).
• Autoridad. Como el mensaje viene de quien viene, asumimos como cierto que el grupo sanguíneo AB es bastante raro.
• Experiencia y conocimiento. Los médicos opinan que si encontraran a estos donantes podrían salvar la vida al niño (esto acompañado del respaldo del hospital lo hace todavía más creíble).
• Acercamiento al mundo real. El bulo proporciona incluso el nombre y teléfono de la madre para acercarnos a su situación y convencernos de la veracidad de lo que estamos leyendo.
• Sugestión. El propio mensaje nos solicita reenviar el bulo a quien conozcamos, siempre en favor del niño.

Esto sin contar el que este hoax nos toca la fibra sensible: un niño tiene un problema muy grave -LEUCEMIA, en mayúsculas, podemos verlo incluso sin leer el cuerpo completo del bulo, lo que a cualquier persona le preocupa y le invita a reenviar este mensaje en beneficio del supuesto niño enfermo…

Evidentemente, hay bulos más desarrollados que utilizan más técnicas que las anteriores (Hotmail será de pago, lo dice el presidente de Microsoft), incluso incorporando material gráfico que acerca a la víctima a reenviar, en estos casos, el correo (la típica foto del perrito abandonado que busca urgentemente una familia porque si no será sacrificado) o tocando directamente nuestra fibra sensible (como el que hemos puesto aquí, o aquel otro en el que Bill Gates iba a donar X dólares por cada click en un enlace o cada reenvío del bulo).

No vamos a entrar ahora en analizar los hoaxes ni las formas de identificarlos; vamos a fabricar uno nosotros mismos, a ver si somos capaces de incorporar técnicas persuasivas para que lo reenviéis cuando os llegue :) Buscamos algo absurdo, evidentemente, algo que no haríamos en circunstancias normales y que, si nos convencen bien de ello, haremos sin dudar. Algo generalista, que no esté restringido a unas pocas personas… Nada por tanto tecnológico, ni mucho menos de seguridad o cosas que sólo nos afectarían a unos cuantos (y que en este caso somos los que a priori menos picaríamos en ello)… Algo relativo, por ejemplo, a eso que ahora está tan de moda de correr sin motivo aparente (ni detrás ni delante de algo o alguien): fabriquemos un hoax de maratones para convencer a la gente de que correr es malo…

Hace unas semanas tuve la oportunidad de asistir a una charla sobre persuasive programming, un término que hasta ese momento desconocía, pero que simplificando mucho -y resumiendo lo que entendí, que no fue todo-, consiste en el desarrollo de aplicaciones que modifiquen el comportamiento del usuario, persuadiéndole para que ejecute determinadas acciones: vamos, cosas más allá del típico “Aceptar-Cancelar” que todos supongo que incluiríamos en un popup para que el usuario elija qué opción prefiere…

El caso es que esto del persuasive programming me llamó la atención (por motivos que luego comentaré) y googleando un poco acabé conociendo términos como captology o similares, y descubriendo que alrededor de lo que denominan tecnología persuasiva había todo un mundo en el que se cruzaba la tecnología con la psicología, con el objetivo de generar desarrollos, dispositivos, interfaces, etc. que tratan de cambiar actitudes o comportamientos de las personas para conseguir que éstas hagan lo que nosotros queremos que hagan…

¿Cuáles son las estrategias de persuasión? En la charla hablaban de unas cuantas (no sé si hay más):

• Automonitorización, proporcionando mensajes al usuario -no tienen por qué ser ciertos- acerca de su comportamiento y no del de otros, de forma que le resulten más cercanos: “Tú has violado la política de seguridad tres veces esta semana y diez veces este mes”.
• Simulación, transmitiendo al usuario el resultado que se produciría si elige la opción que no queremos que elija: “Sé consciente de que si violas la política de seguridad se puede producir un robo de información, y eso es muy caro”.
• Alabanza, haciéndole ver lo positivo que sería que escogiera una determinada alternativa de las que puede elegir: “Si tu opción pasa por cifrar los datos, serás un empleado ejemplar”.
• Recompensa, proporcionando “premios” si el usuario tiene un determinado comportamiento: “Si trituras la documentación confidencial antes de reciclarla, Seguridad te dará 0,01 euros por folio.”
• Recordatorios, instando al usuario a que haga o deje de hacer una cosa: “Recuerda que debes leer un libro de seguridad diferente cada mes”.
• Sugestión, transmitiendo al usuario directamente lo que creemos que debe hacer: “Seguridad te recomienda elegir la opción A porque será mejor para todos”.
• Rol social, denotando proximidad a la persona que debe tomar la decisión: “Soy Paquito, tu asistente virtual personalizado para ser seguro… ¿En qué puedo ayudarte?”.
• Experiencia, convenciendo a la persona de que sabemos mucho de un tema para que confíe en nosotros: “Este consejo lo ha proporcionado Bruce Schneier, una de las personas del mundo que más sabe de seguridad”.
• Acercamiento al mundo real, para que el usuario se identifique con un determinado mensaje o vea que detrás de un correo o de una aplicación hay personas de carne y hueso: “Si tienes cualquier problema de seguridad, te puedo ayudar: envíame un correo a mi dirección, pepe@example.com, y te llamaré enseguida”.
• Autoridad, transmitiendo -algo parecido a la experiencia, a la que hemos hecho referencia- que sabemos mucho de un tema para que el usuario haga lo que queremos de él: “Todas las personas inteligentes han pinchado sobre este enlace. Pepito Pérez, CSO de la NASA”.
• Respaldo de terceros, haciendo ver a nuestro usuario que alguien de confianza apoya nuestra alternativa: “El sistema obliga a cambiar la contraseña cada tres meses. Este sistema ha sido certificado por la NSA y la CIA lo revisa cada dos semanas”.
• Comparativa social, haciendo que el usuario se dé cuenta de cuál es la opción que queremos que elija porque es la mejor para la mayoría de gente: “El 90% de nuestros empleados usan este programa de cifra. Puedes ver sus experiencias en la intranet corporativa”.
• Cooperación, facilitando que un tercero dé apoyo al usuario para que ejecute lo que nosotros queremos: “Pregúntale a cualquier compañero como actuar ante el robo de un portátil”.
• Competición, convenciendo al usuario de que será mejor que los demás si elige una alternativa determinada: “Sé más seguro que los demás cifrando tu teléfono móvil (y participa en el sorteo de un aifon promocionado por Seguridad)”.
• Reconocimiento, proporcionando al usuario una relativa distinción si hace lo que nosotros deseamos: “Bloquea tu sesión cuando te ausentes del puesto de trabajo y serás EMPLEADO DEL MES”.

Evidentemente, todas las estrategias anteriores se pueden usar por separado (no hay que aplicar todas a la vez, ya que si lo hiciéramos el pobre usuario se volvería loco) y también combinar para lograr nuestro objetivo: convencer a una persona de que realice una determinada acción, que evidentemente es la que a nosotros nos interesa. En definitiva, persuadiéndolo y convenciéndole de que lo que va a hacer es lo mejor, sea esto cierto o no.

Pero, ¿por qué hablamos de programación o tecnología persuasiva en un blog de seguridad? Muy sencillo: lo primero que se me iba ocurriendo al escuchar la charla y las diferentes estrategias de persuasión que puede usar una aplicación, una web, un sistema… para convencernos de que hagamos algo era aplicar esas mismas estrategias al ámbito de la seguridad, por ejemplo para realizar ataques de ingeniería social. Fabriquemos un bulo, un hoax, y convenzamos a la gente de algo que nosotros queremos transmitiéndoles que es lo correcto para ellos; evidentemente ese hoax puede ser inocuo o estar relacionado con un ataque más severo, de ingeniería social dura, volviendo a la primera idea :)

Llevamos tres días jugando al ratón y al gato con nuestro amigo Vicente y empezamos a cansarnos del tema, pero no nos queda otra que seguir…

DIA 4 (y sucesivos)
A la misma hora de todos los días (aproximada, claro) estamos ya mirando la consola de eventos y los móviles, esperando a Vicente una noche más… Pero hoy Vicente ha desaparecido, tras tres días jugando con nosotros; durante unas jornadas estamos especialmente alerta a cualquier cosa que se salga de la normalidad en ACME, pero nada. Como si se lo hubiera tragado la tierra; los ataques de Acunetix no obtuvieron ningún resultado significativo, no hay más actividad anómala en el entorno -al menos similar a la generada por nuestro amigo- y parece haberse perdido todo el interés de Vicentín en ACME… ¿Que habrá pasado? ¿Habrá encontrado un ACME2? Ni idea por el momento, pero el caso es que ya no molesta, al menos a primera vista… Unos días después revisamos otra vez el entorno de ACME y no encontramos nada relevante, por lo que desactivamos el GIR y olvidamos el tema. ¿Fin de la historia? No :)

FIN DE LA HISTORIA
Aproximadamente un mes después de la fiesta nos llaman del CNP; la denuncia que en su día hicimos sigue su curso y el Oficial que está llevando el tema quería aclarar algunas dudas… Sinceramente, ni me acordaba del tema, pero es de agradecer el interés mostrado en este caso por el CNP y el excelente trabajo que hicieron. Resuelvo las dudas y a otra cosa…

Algo menos de tres meses después del incidente, el Oficial vuelve a llamarme: lo tienen. Han cogido al tipo. OPERATOR les ha dado la información, previa orden judicial, de quién estaba detrás de todas las direcciones identificadas y -oh, sorpresa- era la misma persona: Vicentín; han mandado a dos policías a su casa, lo han trincado y el chaval ha cantado hasta el último detalle… La verdad, un pobre diablo al que han pillado; como me dijo hace años un amigo de la Guardia Civil, pillamos a los más tontos, y de los más tontos a los que llevan un mes en esto… En fin, sin comentarios sobre el pardillo, ya se apañará; da incluso algo de pena, pero nos hizo perder muchas horas y sobre todo nos hizo pasar algún rato de preocupación. No detallaremos cómo fue el tema judicial para no generar morbo que no aporta nada, pero el caso es que al chaval lo pillaron con todo el equipo :)

LECCIONES APRENDIDAS
Como todo incidente, tenemos que aprender algo de la situación que vivimos en ACME; sin duda, para nosotros, lo más grave es la sensación de indefensión que sufrimos, tanto el cliente como nosotros mismos… Un atacante está analizando la seguridad de la infraestructura de un cliente -o la tuya propia- y lo más que puedes hacer oficialmente es bloquear la IP. Cojonudo, perdonen la expresión. Como si un tío está intentando forzar la puerta de tu casa y lo más que puedes hacer es cerrarla bien… Luego se nos llena la boca hablando de convergencia, de 112 digital y de cosas así. Mentira. Si alguien intenta entrar físicamente en mi casa llamo al 062 y tengo a una pareja de la Guardia Civil en la puerta; si intenta entrar virtualmente, no tengo a nadie a quien llamar (claro, puedo llamar también al 062 y esperar); menos mal que Vicentín se cansó en un momento determinado de atacar a ACME, porque en caso contrario podríamos haber estado meses bloqueando direcciones IP en el firewall. Surrealista, ¿verdad? Hasta que no tengamos una especie de “062” al que llamar en situaciones así, mal vamos, porque no podemos hacer otra cosa más que cortar tráficos… Aunque me han comentado que puedes comprar, pagando en efectivo sin dejar rastro, un VPS ruso desde el que jugar con Vicentín muy alegremente (y encima el ancho de banda del proveedor es bastante barato)… Ojo, que me lo han comentado, que nosotros eso no lo hacemos porque es ilegal, por supuesto. Seguiremos poniendo la otra mejilla para que nos den más abajo y con el pie…

Como elemento positivo, hay que reconocer que el CNP hizo un trabajo excelente, y eso es siempre de agradecer, en nuestro caso especialmente al Oficial y, por extensión, al Inspector Jefe del Grupo; nos atendieron de maravilla en todo momento, el intercambio de información fue fluido y ágil y los resultados obtenidos fueron perfectos, con el atacante delante de un juez. El aspecto judicial ante situaciones como la explicada, y las situaciones surrealistas en los juzgados, darían para más de un post, pero ese ya es otro tema que excede la gestión del incidente con Vicentín…

La gestión de incidentes no es, por suerte o desgracia, una ciencia exacta. No sabemos si otros habrían hecho lo mismo que nosotros, mejor o peor, en esta historia inventada ¿Qué opináis? ¿Se os ocurre alguna alternativa legal más allá de bloquear y denunciar? ¿Denunciaríais? ¿Atacaríais -ojo, sin saber realmente si la IP es del atacante o de su vecino-? Cualquier idea es bienvenida, que el objetivo es, siempre, ir mejorando…

Sin duda todos nuestros lectores, sobre todo los que ya tengan una edad, habrán leído el artículo An evening with Berferd, donde Bill Cheswick narra las actividades de un intruso (Berferd) en 1991 y la gestión del incidente realizada desde AT&T, incluyendo una paciente vigilancia de todo lo que hacía Berferd. Obviamente, nosotros somos más de andar por casa y no tenemos la paciencia necesaria para jugar con un atacante durante días o meses, pero también nos pegamos con algún que otro intruso (seguramente no será Berferd, le vamos a llamar Vicente) que por las noches trata de colarse en las máquinas de un cliente al que, por motivos lógicos de confidencialidad, denominaremos ACME :) Ahí va el resumen, con nuestra visión, de la respuesta al incidente… Por supuesto, toda esta historia está basada en hechos ficticios, por lo que cualquier parecido con la realidad es pura coincidencia…

DÍA 1

A las 21:40 se recibe una alerta en nuestro sistema: un amigo, con una dirección IP de un operador al que vamos a llamar OPERATOR genera una alarma crítica en nuestro SOC: un ataque a ACME mediante Acunetix, que se ha bloqueado en el IPS del cliente y teóricamente no ha ido a más, pero que debe considerarse severo. En ese momento se revisa la actividad adicional de esa IP en ACME y el resto de clientes y vemos que ha generado alguna alerta menos crítica (en ACME, parece que este es su único objetivo) y que no requería acción inmediata, pero vamos, que el tío está metiendo caña… se bloquea de inmediato todo el tráfico entrante desde esa dirección y en paralelo comprobamos que la IP es de una línea ADSL, que se geolocaliza en la misma ciudad que ACME, y que detrás de esa IP hay un router Cisco con el telnet abierto (muy curioso, ¿no? ;)

En fin, un ataque que no ha ido a más, bloqueado ya en la infraestructura y que al día siguiente requerirá los formalismos correspondientes (correo a OPERATOR, denuncia de los hechos, etc.). A otra cosa. Pero no; dos minutos después del bloqueo de la IP, aparece un ataque similar: alguien que lanza otra vez Acunetix contra ACME y genera otra alerta crítica… De nuevo iteramos el proceso: bloqueo del tráfico entrante y obtención de información… Ummm, una línea ADSL de OPERATOR con un router Cisco delante, el puerto 23 abierto y (vaya, vaya) geolocalizada donde ACME… ¿Casualidad? Seguro que no: parece que tenemos un amigo interesado en ACME, al que como hemos dicho llamaremos Vicente (Vicentín más tarde, que al final llegamos a coger confianza con él ;)

En fin, nosotros repetimos la respuesta y Vicente el ataque. Esto se pone interesante… Bloqueo de nuevo y otra vez cambio de IP de Vicente: de nuevo un ADSL de OPERATOR geolocalizada en la misma ciudad que ACME, aparentemente con un router Cisco delante y el telnet abierto. Hasta cuatro veces repetimos el proceso y hasta cuatro veces Vicentín hace lo propio: se cambia de IP para seguir “zumbándole” a ACME. Desde luego mañana a denunciar, pero esto no tiene buena pinta… Al final, parece que Vicentín se ha cansado o simplemente que se le han acabado las direcciones dinámicas desde las que atacar… Mañana será otro día para todos, pero esta noche habrá que estar alerta…

DÍA 2

Día tranquilo; Vicentín parece que se ha olvidado de ACME y no da señales de vida… Vemos que no hay nada significativo fuera de las alertas ya identificadas ayer, recopilamos todos los logs, escribimos la denuncia, y a última hora nos vamos a Comisaría a presentarla. Tras un rato de papeleos tenemos ya todo firmado y estamos saliendo… es justo entonces cuando Vicente parece que nos esté viendo: vuelve a la carga contra ACME. Nos llegan las alertas por SMS y viendo sus actividades, confirmamos que sigue el mismo modus operandi que ayer: Acunetix a lo bruto, sin ningún tipo de discreción… Nuestra gente sigue el mismo procedimiento: bloquear cada IP y recopilar evidencias, pero Vicente cambia de direccionamiento como quien cambia de zapatos. Además todas las direcciones son ADSL de OPERATOR geolocalizadas en la misma zona, pero lamentablemente de rangos completamente diferentes, por lo que no lo tenemos tan fácil como bloquear unas clases C para quitarnos a nuestro amigo de encima…

La situación nos empieza a resultar especialmente incómoda, sobre todo por el sentimiento de indefensión. Tenemos a un tipo intentando colarse en ACME pero lo más que podemos hacer oficialmente es bloquearle la IP. Hablamos con soporte legal para que nos den más alternativas y lo único que nos pueden decir es que acudamos a Juzgado de Guardia para acelerar unas horas los trámites de la denuncia (ojo, una aceleración de “unas horas” para unos trámites que pueden durar semanas). Algunos amigos de FFCCSE de forma extraoficial nos confirman lo que ya sospechábamos: que aparte de denunciar y poner la otra mejilla, no se puede hacer nada, y encima alguien nos comenta, también extraoficialmente, que la gran OPERATOR atiende los requerimientos judiciales cuando ella considera, porque claro, para eso es OPERATOR, más allá del bien y del mal. Nos suena, ¿verdad? En cualquier caso, el segundo día hemos vuelto a cortar a Vicente, o se ha quedado otra vez sin IP disponibles… o simplemente se ha cansado de ACME y ahora está con otro objetivo…

DIA 3

Ampliamos denuncia en Juzgado de Guardia aportando las nuevas evidencias, sobre todo las direcciones IP que recopilamos durante la noche de ayer. Durante el día seguimos dándole vueltas a la situación y a la cara de imbéciles que se nos queda sin poder hacer nada más que filtrar una dirección IP tras otra. ¿Cambiará Vicentín de IP automáticamente? ¿Lo hará para seguir atacando a ACME, o ésta será una de múltiples tareas? ¿Utilizará sistemas intermedios o tira directamente desde la IP de su casa? ¿Por qué siempre a la misma hora? ¿Es cuando llega a casa o cuando se queda solo en la oficina? ¿Nos estará distrayendo con este ataque tonto mientras utiliza otro vector de entrada a ACME? Para descartar esto último y con el modo paranoia ON, se moviliza un equipo auxiliar al GIR que tiene por objeto revisar todos y cada uno de los sistemas de ACME, empezando por los que están en DMZ y siguiendo por los internos. Tras varias horas de trabajo, ni rastro: no hay nada anormal más allá de lo que hemos visto. Vicente sólo dispara a un objetivo, lo hace sin esconderse y aunque le filtremos, él cambia de IP y en segundos o minutos sigue su trabajo…

Por supuesto, a su hora habitual, Vicente vuelve a la carga por tercer día consecutivo. Seguimos metiendo las IP de la línea ADSL en nuestra lista negra y mirando cómo cambia de dirección cada poco tiempo, hasta cuatro o cinco veces. No podemos hacer más, nos dicen. Situación estúpida donde las haya, pero es todo a lo que podemos aspirar, aunque ya empiezan a surgir en el equipo malas ideas (que como somos buena gente, no llegamos a ejecutar -aunque no por falta de ganas-). Y también por tercer día consecutivo, tras varios cambios de direccionamiento, Vicentín se cansa y deja de atacar… Mañana más.

Snowden, PRISM, NSA… palabras que en los últimos meses se escuchan mucho, muchísimo, en los medios de comunicación. Y es que no hay nada como unir tecnología, espionaje -con el prefijo ciber, of course– y unas cuantas siglas para generar una noticia de alcance… Me he mordido la lengua todo este tiempo, no quería escribir nada sobre esto, pero al final no he podido resistirlo: es lo que tienen las vacaciones, tanto tiempo libre para leer ciertas cosas que al final uno se pica ;)

En principio, no acabo de ver dónde está la noticia… Que Estados Unidos, a través de la NSA y de otras muchas agencias de inteligencia, espía todo lo que puede, es tan noticia como que los perros ladran. Ya, ¿y? Jamás he comprendido la aparente sorpresa de todo el mundo cuando sale a la luz el tema del espionaje de Estados Unidos. ¿De qué nos extrañamos? ¿De que un país con una gran capacidad tecnológica la use en beneficio propio? Vamos, hombre, que aquí nadie es una monjita de la caridad… Lo malo es que los españoles ni tenemos esa capacidad ni creo que la tengamos jamás; vamos, que como no esnifemos Tuenti, poco podemos hacer… Y eso, permítanme la expresión, es una soberana put^H^H^H faena; o, mejor dicho, son dos soberanas faenas. La primera porque nos hace depender de un tercero para adquirir información que posteriormente se transforme en inteligencia (sí, ese tercero es Estados Unidos… ¿quién si no, Andorra?) que hoy es nuestro amigo pero mañana puede serlo menos o simplemente puede tener intereses que no coinciden con los nuestros… La segunda faena es que nos hace completamente vulnerables: dicho de otra forma, tenemos que asumir que Estados Unidos nos espía cuando y como quiere, y por supuesto eso les proporciona sobre nosotros una ventaja envidiable en cualquier campo. ¿Que tenemos dudas si apoyar a los USA en una intervención militar en Chiquitistán? Antes de hablar con nosotros ellos saben lo que tenemos a favor y en contra de la intervención, y pueden adaptar su discurso a lo que queremos oir, por supuesto para apoyarles incondicionalmente en lo que sea… ¿Es esto una faena o no lo es? Y lo peor: si no estamos de acuerdo podemos desconectar cualquier cosa que tenga enchufe e irnos a plantar patatas, por supuesto dejando de usar productos Microsoft, no buscando nada en Google o similares, no enviando información a través de routers Cisco y, en definitiva, alejándonos de cualquier cosa que huela a americana. O mejor, sustituyéndola por Huawei y similares, que también puede ser una alternativa… así diversificamos nuestros riesgos y damos juego a otros países que, sin duda, respetarán nuestra privacidad como personas y nuestros intereses como nación… ¿verdad? :)

El problema, creo, no es que Estados Unidos nos espíe para defender sus intereses: podemos estar de acuerdo o no, y los abogados, periodistas, políticos y demás pueden hablar durante horas de ética, derecho internacional, privacidad y todo eso. Pero, con los pies en el suelo, es lo que hace cualquier país que puede hacerlo. Tan simple como eso, y nosotros, como decía antes, porque no podemos, porque si no, espero que lo hiciéramos… El problema de verdad es un uso particular de la información obtenida. Que un Servicio adquiera información para beneficiar a su país en general (entendido como gobierno, empresas, ciudadanos…) es comprensible, aunque nos perjudique, pero que lo haga para defender intereses de una empresa concreta, para beneficiar a un particular o incluso para proteger a un partido político determinado (ha habido casos), es decir, a actores que no pueden identificarse con un país, no debería tener justificación, IMHO. ¿Lo ha hecho Estados Unidos? No lo sé… ¿Alguien tiene más información al respecto? Si ha usado la información para este tipo de cosas, me parece mal; si la ha usado para beneficiarse como país frente a otros estados, ¿de qué nos quejamos? ¿De que ellos pueden y nosotros no? A ver, que somos mayorcitos y sabemos que la trinchera es mucho más dura que la LOPD, la privacy, la IT Governance, el compliance y todo eso… ¿Qué creemos, que Google nos permite usar GMail *gratis* por amor al arte, regalándonos gigas y gigas de espacio para nuestro correo, gigas que como se dice por ahí solo pueden almacenarse en una SAN, en una NAS o en una NSA :)? Venga, por favor…

Ahora la pregunta del millón: ¿hay luz al final del túnel? Creo que sí, aunque sea un simple LED. Asumamos que Estados Unidos nos espía en beneficio propio… ¿Qué podemos hacer? Dos cosas: intentar que lo hagan lo menos posible -o que lo tengan un poco más complicado- e intentar que sólo nos espíen ellos. Lo que he defendido más de una vez en este blog: usemos tecnología y servicios españoles siempre que podamos -y esforcémonos para poder, que lo cómodo es, muchas veces, lo contrario-; usémoslos, sobre todo, si lo que estamos manejando es información clasificada, sensible o como le queramos llamar. Doy por hecho que servicios nacionales y de calidad siempre podremos contratar, en cualquier ámbito… mi única duda son los productos en casos muy concretos; en estos casos, si no podemos usar tecnología nacional, usemos tecnologías abiertas. Y si tampoco podemos y no queda más remedio que usar sistemas extranjeros, hagámoslo de países que sean estratégicamente cercanos a nosotros o tengan, al menos a día de hoy, unos intereses comunes con los españoles, aunque sea de forma parcial. Dicho de otra forma, prefiero usar Linksys antes que Huawei o Twitter antes que Weibo: ya que me van a espiar, que lo hagan los de siempre ;)

Estamos cansados ya de hablar del término convergencia cuando nos referimos a la unificación, como un todo, de los diferentes ámbitos de la seguridad: física, lógica, etc. Por eso, en este post queremos hablar de divergencia, haciendo referencia a las cosas que separan los ámbitos particulares de seguridad, en especial los de seguridad lógica y seguridad física. Y una de las principales diferencias entre la seguridad física y la seguridad lógica, bajo mi punto de vista, es la regulación que tiene la primera, para lo bueno y para lo malo, y de la que adolece la segunda, de nuevo para lo bueno y para lo malo.

El sector de la seguridad privada está completamente regulado (perdón, muy regulado, no sé si completamente o casi…); los perfiles de seguridad y sus obligaciones y atribuciones se identifican claramente, así como los requisitos para acceder a dichos perfiles y poder ejercer las tareas propias de cada uno de ellos: Vigilante de Seguridad, Director de Seguridad, Jefe de Seguridad… Por contra, cuando hablamos de seguridad lógica, no existe ningún tipo de regulación: cualquiera puede hacer una auditoría, configurar un cortafuegos o gestionar un incidente, por poner unos ejemplos. Esto no es per se ni bueno ni malo ni todo lo contrario, pero introduce una condición curiosa y es el criterio particular y subjetivo que en cada caso aplicamos para decir si algo está bien o mal o para decidir si una persona o una empresa está capacitada para realizar un trabajo determinado.

Podemos discutir (y de hecho en este blog ya lo hemos hecho en más de una ocasión) de los perfiles existentes en la LSP, sus requisitos de acceso, sus atribuciones, su formación y mil cosas más; pero como hemos dicho, están perfectamente definidos, con todas las mejoras que podamos introducir sobre ellos. Podemos hablar largo y tendido de la formación, escasa en muchos casos, para obtener el TIP de Vigilante, Jefe o Director de Seguridad, sobre todo de las deficiencias que presenta, pero no podemos hablar de la formación, habilitación o lo que sea para gestionar un incidente de seguridad lógica (ojo, hablo de formación reglada, no de asociaciones, academias, certificaciones o demás). Y no podemos porque, obviamente, no existe: en ningún sitio están recogidos de forma oficial los contenidos mínimos para obtener la “habilitación” de auditor de seguridad lógica, incident handler o “director de seguridad de la información”.

Ojo, no sólo hablamos de regulación “legislativa”, sino también de normas; en seguridad física existen normas UNE o ISO para casi todo: armeros, cajas fuertes, CRA… y además muchas de ellas son de obligado cumplimiento incluso por Ley. Por contra, en seguridad de la información tenemos algunas normas puntuales, ninguna de ellas de obligado cumplimiento (en términos generales y hablando de normas UNE/ISO) y que en la mayor parte de casos no dan más que pinceladas de lo que debería ser, no de lo que debe ser: dicho de otra forma, una norma de aplicación en seguridad física marca casi siempre al detalle, por ejemplo el nivel de resistencia de una caja fuerte para que cumpla con el estándar hasta un grado determinado, mientras que la normativa de seguridad de la información es más del tipo “debemos proteger las redes”. Ya, ¿cómo? :)

Ahora la pregunta del millón: ¿sería positivo que el sector de la seguridad de la información o de la seguridad tecnológica estuviera tan regulado como el de la seguridad privada? Imagino que habrá opiniones para todos los gustos, y que esa regulación traería cosas buenas y malas. Creo -opinión particular para discutir- que una cosa negativa de la regulación excesiva es que deja poco margen a la imaginación o, incluso, a la mejora (esto se hace así porque lo dice una Ley y de ahí no te puedes salir) y eso, a la larga, convertiría esta seguridad en algo bastante estático, todo lo contrario a lo que debe ser la seguridad y más la que tiene una componente tecnológica muy fuerte. Por contra, con la regulación del sector se evitaría cierto intrusismo, al menos a priori: para abordar un proyecto se deberían cumplir unos requisitos determinados, y el que no los cumpla “no juega” (luego, a partir de ahí, ya veríamos cómo los cumple cada uno, qué requisitos son, si son mejores o peores, etc.). No cualquiera que pase por la calle podría hacer una auditoría, por poner un ejemplo, igual que no cualquiera puede montarse una CRA: hay que cumplir con una legislación estricta para empezar a hablar. Ah, y no entro al tema de las atribuciones profesionales de cada uno, que esa es otra guerra distinta (aunque también da juego, ya hablaremos ya ;).

En fin, que opiniones hay para todos los gustos… por cierto, ¿cuál es la vuestra? Seguiremos hablando de otros aspectos de la “divergencia” entre seguridad física y lógica o, en general, entre “seguridades”. Eso sí, sin olvidar que todos, se supone, vamos en el mismo barco…¿verdad?