Esta es la pregunta que más me han hecho desde que comenzó el apagón eléctrico de la historia de España. La respuesta no la sabremos hasta que los equipos que están investigando el incidente hayan podido analizar "Root Cause" del incidente, y para ello van a necesitar tiempo. Y lo más importante es recuperar la energía lo antes posible, que hay muchos sitios críticos donde la existencia de la energía puede salvar vidas.
Figura 1: ¿Podría ser el Apagón Eléctrico de España un ciberataque?
¿Podría haber sido un ciberataque? Pues no lo sabemos aún, y no seré yo el que vaya a especular sobre esto, pero es una de las posibilidades que podrían ser, por supuesto. Pero también podrían ser otras las causas que han producido esto, así que lo mejor es no especular y esperar a ver lo que los forenses que estén en el CSIRT ahora nos digan cuando tengan los datos.
Al final, en el pasado hemos visto caídas de sistemas de Internet, de energía, de llamadas, de gas, y de casi cualquier suministro crítico por causas que puedan interrumpir el sistema que distribuyen la luz, el gas, las redes de telefonía o datos. Y ahora no sabemos más que puede ser cualquier de ellos.
Las causas posibles, os las podéis imaginar:
Accidente: Un incendio, una inundación, una nevada, un volcán. De todo esto hemos vivido en los años recientes con Filomena, la Dana, el Volcán de La Palma, o los Incendios que nos han asolado durante mucho años parte de nuestro territorio. Estos suelen producir cortes locales, o puntuales, porque destrozan partes del sistema, pero no han solido ser nacionales porque no han tocado el corazón del sistema, y cuando se diseña un sistema crítico es necesario redundar las partes core que pueden discontinuar el sistema.
Pero puede ser de gran intensidad o tocar un punto clave. Durante la Dana, hubo que hacer un trabajo especial para reforzar los centros de llamadas del 112 que estaban saturados, y que fue una de las prioridades durante la crisis, ya que no podían atender tantas llamadas. Que se pudieran atender todas las llamadas de emergencia lo antes posible, y para eso hubo que re-enrutar comunicaciones a centros de respaldo en otras ubicaciones.
Pero los ha habido mucho más cercanos en el tiempo .En el año 2023 se alertó del ataque al sector eléctrico de Dinamarca, donde más de dos docenas de centrales fueron afectadas en tres oleadas, lo que deja claro que fue un ataque coordinado y organizado contra una infraestructura crítica de un país.
Ahora mismo no sabemos nada. Serán los expertos que estén analizando el caso los que tengan que dar las informaciones, así que todo son especulaciones, por lo que hay que evitar caer en asegurar nada, porque solo los que tengan los datos tienen la información. Lo que sí que está claro es que algo ha pasado en el sistema y hay que saber qué es para que no vuelva a pasar.
Soy un "power user" de Google Maps. Lo uso siempre. Para cualquier desplazamiento por Madrid. Desde ir al trabajo, hasta hacer una ruta que me conozca de memoria. La razón es que me he visto atrapado en Madrid, en estos más de treinta años que llevo conduciendo por esta ciudad, en innumerables ocasiones. Una obra, un accidente, una carrera de 10Km, un corte de calles por polución, o cualquier otro evento pueden hacer que tu día se arruine encerrado en un atasco. Así que no me desplazo en mi "malignomovil" sin usar Google Maps.
Figura 1: Un Google Maps para Taxistas, bicicletas y Autobuseros
Entre los problemas que tiene Google Maps en Madrid, hay tres que tengo muy localizados, y que son bastante problemáticos. El primero es el de las rutas erróneas - del que ya os he hablado otra vez-, el segundo es el famoso túnel de la M-30 donde tienes que configurar las balizas BlueTooth y no es que vayan muy allá, y el tercero, que es del que voy a hablaros hoy, es el de los datos de los Taxistas y Autobuseros.
Rutas Erróneas que te cuestan pitadas, tiempo puntos y accidentes
Usar tanto Google Maps ha hecho que conozca bastante bien sus limitaciones, y la primera de ellas son los giros imposibles que me han costado alguna multa y algún susto de accidente, además de perder tiempo. Esas rutas que están erróneas y que generan problemas no sólo a mí, sino a mucha gente que lo usan y que me gustaría que Google premiara por reportar, para mejorar cuanto antes el producto.
Figura 2: Ruta imposible de hacer
Si se te ocurre hacer la ruta que tienes en la Figura 2, te vas a llevar una pitada sí o sí, además de una bonita multa de tráfico, la perdida de algún punto del carné, y si estás de suerte no generarás ningún accidente de tráfico.
Yo he reportado estas rutas algunas veces, y escribí un artículo titulado: "Cómo corregir las rutas erróneas y peligrosas de Google Maps" para que todos los que somos usuarios de esta plataforma nos beneficiemos, pero creo que debido al impacto que tiene esta plataforma en las ciudades, deberán incentivar más desde Google la corrección de estos errores.
Balizas Bluetooth en túneles
Google Maps añadió la opción de configurar Balizas Bluetooth en túneles en Android para evitar que te pierdas en los túneles de la M-30 - por ejemplo -, pero esta opción llevamos un año esperándola en iPhone y aún no la he visto. Así que, cada vez que me toca una ruta que pasa por los túneles, memorizo bien qué punto salida tengo que tomar, para no perderme, que ya me he perdido muchas veces. De este tema ya "haré terapia" en otro artículo.
Datos de Taxistas y Autobuseros
Este es el tema del que quería hablaros hoy, que es algo que también me lleva años comiendo la cabeza, y que me ha hecho perder tiempo y reuniones por fiarme de los datos de Google Maps en estas rutas. Se trata de aquellas rutas que te meten por calles que tienen carriles BUS y Taxi, donde los datos quedan distorsionados.
Veréis, Google Maps utiliza los datos de - por supuesto todos los Google Maps - y de los terminales Android para conocer la densidad de tráfico en tiempo real. Esto, lo utilizó un hacker en una demostración muy sencilla donde ponía en rojo las rutas simplemente paseando un carrito con terminales Android. Pero esto mismo sucede si los datos vienen desde fuentes de datos sesgadas, como son los Taxistas y Autobuses, además de los ciclistas, que utilizan los carriles Bus/Taxi/Bici y de los propios pasajeros de un autobús.
Figura 5: La Gran Vía de "subida" con el carril bus/taxi y bici
En la foto de arriba tenéis la Gran Vía de Madrid, donde os aseguro que el carril Bus/Taxi y el Carril Bici funciona muy bien de subida, pero el carril para los vehículos normales está totalmente colapsado siempre, especialmente en días como ayer (noche de Reyes Magos), donde el centro de Madrid estaba a reventar. Sin embargo, como podéis ver en la recomendación de mi ruta de Google Maps me sale azulito.
Figura 6: Sube gran vía la noche de Reyes Magos
en tu vehículo y me dices si es azul
Esto es porque los datos con los que se está alimentando Google Maps no están correctamente limpios, y está chupándose datos sesgados de taxistas, ciclistas, autobuses y autobuseros, algo a lo que deberían meterle un poco más de ingenieros. Además, estos datos son peligrosos porque los taxistas y autobuses tienen permitidas zonas y giros que están prohibidos para el resto de los vehículos en las ciudades, así que deterioran la experiencia de los conductores y generan problemas en las ciudades.
Conclusiones
Personalmente creo que los datos GPS de plataformas como Waze, Google Maps, o Apple Maps, así com el uso de ellos que hacen plataformas como Uber, Cabify, Volt, FreeNow o las plataformas de movilidad y parking en las ciudades son parte de lo que es una "SmartCity" y es fundamental asegurase de que estos datos generar un buen funcionamiento de la ciudad y no lo contrario, así que hay que poner esfuerzo en mejorar estas cosas. Y nada más, que os hayan traído muchas cosas los Reyes Magos.
Aparcar en Madrid no es de las cosas más sencillas. Eso es un hecho. Pero tiene una red de parkings repartida por toda la ciudad que funcionan bastante bien. Por eso soy un usuario habitual de ellos, y por eso me los conozco bastante bien. Y hoy os quería hablar de algo, al igual que me sucede con la aplicación de Telpark, que me frustra desde el punto de la usabilidad. Y es trozo de papel que me entregan que sirve para nada. Dejadme que os lo explique.
Figura 1: El parking que me entrega un trozo de papel... y no lo entiendo
La mayoría de los parkings de los que os voy a hablar son parkings que tienen la siguiente característica: Tienen lector de matrícula. Fantástico. Una función de usabilidad que me encanta, pues si has pagado el ticket, cuando te acercas a la barrera a la salida, te reconoce la matrícula, comprueba que está pagado el ticket y se abre sin que tengas que poner el ticket en ningún lector. Fantástico. Me encanta. Y eso significa que: Tiene lector de matrículas a la salida del parking
Figura 2: Lector de matrículas en parking
Ahora bien, si analizamos el proceso, él sabe que el ticket de mi matrícula ha sido pagado porque el ticket lleva, de alguna forma, asociada la matrícula de mi vehículo, que ha leído... a la entrada del parking. Así que: Tiene lector de matrículas a la entrada del parking
Figura 3: Máquinas con lector de códigos de tickets de entrada y una
bonita pantalla táctil donde podría escribir mi matrícula fácilmente.
Fantástico. Así que sabemos que tenemos un parking que tiene lector de matrículas a la entrada y a la salida del parking, la pregunta es... ¿por qué me das un trozo de papel con el ticket? ¿Por qué no me dejas que cuando vaya a pagar escriba mi matrícula en esa bonita pantalla táctil que tienes? Vamos a ver las opciones.
Opción 1: Es por seguridad
La primera respuesta que he obtenido al respecto de esto que me trastorna es que lo hacen por seguridad. Y la respuesta ha sido que para probarlo, he ido a pagar y he llamado al soporte con el botón de ayuda que tienen y he dicho:
- "¡¡He perdido el ticket!!"
Y... ¿adivináis qué me han dicho?
- "No se preocupe, dígame la matrícula, pague y le dejamos salir".
Osea, que si pierdo el ticket, con comprobar mi matrícula me hacen otro ticket y listo. Fantástico. Es decir, que si alguien me roba las llaves del coche, y llega al parking, con decir que ha perdido el ticket resuelto. O sea... que por seguridad nada.
Opción 2: Es porque el sistema no permite hacer ese proceso
A ver, tiene.
Lector de matrículas en la entrada.
Lector de matrículas en la salida.
Pantalla táctil en la máquina de pagar.
¿Tan difícil es pedir la matrícula del coche y listo?
Opción 3: Es por si falla alguno de los lectores de matrículas
Algo que por lo visto no es fácil, pero.. si eso pasara. Hay un botón precioso que podéis probar a la salida al que podéis llamar y decir:
- "No me funciona el ticket".
Figura 4: Botón de ayuda por si falla el ticktet
Y... ¿adivináis qué me han dicho cuando he dicho eso?
- "No se preocupe, dígame la matrícula, comprobamos el pago y le dejamos salir".
Fantástico. O sea que para las incidencias tenemos un soporte que nos ayuda igualmente.
Opción 4: Hay obligación legal de darte un ticket físico cuando entra el coche
Pues no debe ser así, porque los parkings más modernizados permiten entrar con apps tipo Telpark y no me dan ningún ticket físico. Todo digital.
Figura 5: Parking automático con Telpark
Conclusiones personales
El sistema está imprimiendo tickets - gastando papel y haciendo que los usuarios se preocupen de no perderlo - solo para reducir un caso. El caso en el que el lector de matrícula no funcione y evitar que llame por botón al soporte. Podríais decir: "Es que por la noche no hay soporte". Fantástico. Pues que entregue tickets "sólo" cuando no haya soporte. Nos haría la vida mucho más fácil a todos, incluyendo al planeta, y ayudaría a:
Evitar Colas en la entrada y salida: Muchas veces la gente tiene que maniobrar porque la dichosa máquina de coger e introducir ticket no es cómoda para todos los vehículos, y para muchos exige maniobrar y poner el coche en posición. O cuando se cae al suelo y hay que buscar el ticket.
Figura 6: Tickets de papel. Se pierden. Se vuelan.
Gastan papel. Tinta de impresión. Basura.
Incomodidad en los usuarios. Preocupación.
Evitar abolladuras y raspones: Lo mismo que antes pero con las abolladuras. Es decir, que no tengas que acercarte al bordillo donde han puesto la máquina. ¿Algunos habéis catado bordillo alguna vez?
Y para terminar este post en el que hago terapia sobre mis experiencias con los parkings, una serie de opciones más.
Telpark soporta muchos parkings en Madrid, lo que es genial, porque al reconocer mi matrícula, me deja entrar y salir, pagando por la app evitando papel, colas en las máquinas de pago, y preocupación por el pago. Bien por el sistema de las apps para parkings, que en USA se utiliza masivamente.
Parkings que quieras o no te emiten la factura: Mal. Papeleras enteras de papel y tinta tiradas a la basura. No lo entiendo.
El último mensaje es para los parkings que aún utilizan tickets con bandas magnéticas, de esas que se perturban con la proximidad de dispositivos electrónicos como, por ejemplo, el teléfono móvil, y que si se doblan dejan de funcionar, como, por ejemplo, cuando metes el ticket en la cartera y se deforma un poco.
Figura 7: Tickets con bandas magnéticas. Horror++
Sed buenos, y quitad esos sistemas, que se diseñaron en 1976, pero ya tenemos otras tecnologías... A ver si las ciudades que quieren ser SmartCities fuerzan a que los parking quiten el ticket de papel y ayudan a todos, que con Cognitive Services de visión artificial se leen las matrículas perfectamente.
Hoy quería hablar de "Safety" en lugar de "Security", ya que como usuario de Google Maps me he encontrado con más de una decena de estas rutas en la ciudad de Madrid, y hoy he decidido investigar cómo reportarlas, y compartirlo con vosotros para que ayudéis a evitar que yo, u otro usuario de Google Maps, tenga un accidente o se gane una multa por seguir una ruta errónea y peligrosa.
Figura 1: Cómo corregir las rutas erróneas y peligrosas de Google Maps
El problema es sencillo. Haces una ruta entre dos puntos de la ciudad usando Google Maps y resulta que te dice que tienes que tomar un giro que está prohibido. En Madrid hay algunos de estos problemas en calles muy principales, como este que propone entre las transitadas calles de Conde de Peñalver y José Ortega y Gasset, donde te dice que gires a la izquierda como podéis ver en el mapa.
Figura 2: Giro recomendado por la ruta de Google Maps
Si miramos desde la versión de Google Maps del navegador web, podemos ver que nos da las indicaciones y que incluso tenemos una foto para poder ir a visitar el Google Street View y familiarizarnos con el giro de esta ruta.
Figura 3: Recomendación de giro con imagen de Google Street View
Y si vamos al Google Street View, podemos ver esta fantástica señal de señal obligatoria de dirección recto o a la derecha. Es decir, que si giras a la izquierda no solo puedes provocar un accidente con los coches que vienen en sentido contrario o en tu misma dirección detrás de ti que no esperan este movimiento, sino que además te puedes comer una buena multa y perder unos bonitos puntos del carné de conducir.
Figura 4: En Google Street View se ve la señal de dirección obligatoria
Si has encontrado estas rutas erróneas en Google Maps, una vez que tengas la ruta marcada en Google Maps con el giro prohibido o erróneo, en la parte inferior derecha encontrarás un texto que dice "Enviar Comentarios". Ahí es donde debes pulsar.
Figura 5: Con la ruta hecha en el mapa, pincha en "Enviar Comentarios"
Una vez lo hagas, en la ruta, tendrás la opción de enviar un comentario para corregir esta ruta, indicando qué elemento de la ruta es el erróneo y dónde está el fallo. En este caso, que hay una señal de dirección obligatoria que no nos permite girar a la izquierda.
Figura 6: Yo he reportado que ese giro está prohibido
Así que, si encuentras una ruta de éstas, recuérdala y repórtala. Si se corrige puedes estar ahorrando accidentes, salvando vidas, ahorrando multas, salvaguardando puntos del carné y mejorando la circulación, porque muchas veces solo tenemos que parar, frenar toda la circulación, pero montar un lío de tráfico.
Figura 7: Confirmación del reporte
Google Maps te mantendrá informado de tus contribuciones que quedarán en tu perfil de Google. Y por supuesto, a todo aquel que haga esa ruta pensando que es la más rápida y luego no se puede hacer, le acabas de ahorrar tiempo en su vida.
Figura 8: Confirmación del reporte y enlace a las contribuciones
Anímate, y reporta estas rutas no solo en Google Maps, sino en la plataforma de mapas que utilices, así mejoras un poco la ciudad donde vivimos todos. Eso sí, creo que Google debería agradecer a los usuairos estos reportes con unos tokens, que estamos en la época del Tokenomics y la Web3.
Hoy quería aprovechar para contaros un caso de UX que me tiene siempre "molesto". Se trata del Selector de "Duración" del parking en la appTelpark. Para los que no conozcáis Telpark os diré que se trata de una app muy cómoda que permite pagar en la Zonas de Aparcamiento Restringido de muchas ciudades, entre ellas Madrid. Además, permite reservar aparcamientos privados y te hace la vida más cómoda.
Figura 1: Telpark y el selector de la "Duración" del parking sin precisión
Pero hay un detalle que siempre me molesta, y es el impreciso selector de la "Duración" del parking, que ha sido hecho por un equipo de UX muy profesional, pero que no ha pasado fuerte QA de uso real, ya que, como he dicho, no es nada preciso.
Veréis, a la hora de seleccionar la duración de un estacionamiento en Zona Azul o Zona Verde o Zona Roja, o lo que sea, el tiempo se puede seleccionar con un "Slider" o con unas opciones pre-configuradas como accesos directos. Todo muy bien. Muy molón el "slider", y muy rápido el acceso directo, pero...
El Slider de la Hora
... pero qué pasa si quieres poner una hora concreta, por ejemplo hasta las 21:00 que acabe la hora de parking restringido, pues con el "slider" es una locura. Primero porque es un porcentaje del total de las horas que puedes apartar 4 horas en Zona Azul o 2 horas en Zona Verde, así que siempre tienes que ver cuánto varia en función del tiempo máximo de esa hora. Por ejemplo en zonas azules va de 2 minutos en 2 minutos, lo que para una persona adulta con un dedo grande, y con un control tan pequeño, es un reto para ver exactamente la hora que quieres configurar.
Figura 2: El Slider de Telpark y los acceso directos
que me hace la vida un poco menos fácil. Tengo que usar
el dedo, poca precisión y no puedo meter la hora exacta.
Y en los accesos directos faltan las horas más evidentes. No sé, las horas en punto, o las horas de finalización de la hora en esa zona, así que la mayoría de las veces esos accesos directos no te sirven para poner la hora que tú quieres exactamente.
¿Qué le vendría bien a la app de Telpak?
Pues le falta la posibilidad de poder poner la hora exacta. Un control que permita poner 12:15 o 21:00 o lo que el usuario quiera, que tener el control como usuario de una app siempre da seguridad. Es decir, directo, fácil. "Hasta las 13:15". También le faltan accesos directos "evidentes" para un usuario, como las horas próximas exactas, o las de finalización de aparcamiento restringido más próxima.
Figura 3: En tramos de 4 horas va de 2m en 2m
Si ya le metemos un poco de Machine Learning y los accesos directos se basan en los que selecciona un usuario a esa hora, o los que selecciona en esa zona, o los más seleccionados por otros usuarios en esa misma zona a esa misma hora, seguro que nos hace la vida más fácil a todos, porque las selecciones por acceso directo en ese caso son un problema claro de IA.
Y si, por último, ya Telpark te marca las zonas que se van a ver bloqueadas para parking restringido cuando consumes el máximo de tiempo en una zona de parking restringido, pues mejor que mejor, porque ya sabes que no puedes moverte y aparcar en esas calles hasta que se levante la restricción otra vez. Son solo sugerencias de un usuarios de esta app, que, como he dicho, es súper-útil y me encanta.
Para hoy domingo os traigo unos vídeos que han estado creando mis compañeros en diferentes áreas de Telefónica, para que tengáis todo disponible y que no se os escape nada. Ya sabéis que hoy es domingo y tenemos una cita importante con el mundo del deporte que Richard Carapaz, Mikel Landa y todo el Movistar Team que tenemos en el Giro de Italia, nos tienen en vilo a ver si se traen la Maglia Rosa, un podium repleto y la clasificación general por equipos, además de los dos triunfos de etapa que ya nos dieron. Así que al lío.
Figura 1: El club de los 5: SmartCities, un Genio en una caja, un blog para controlarlos a todos, un resumen y unos Trivia
El primer de los vídeos que os dejo es el nuevo capítulo de Las aventuras del Dr. Tech. Como sabéis tenemos al equipo de Brand Experience trabajando en animación, y nos traen un tercer capítulo con un Genio que nos enseña cómo hacer el Unboxing de Movistar Home.
Figura 2: Aventuras del Dr. Tech Capítulo 9: Unboxing Genius Movistar Home
Podéis ver los tres capítulos que hemos publicado por ahora en los siguientes enlaces que os dejo a continuación:
El segundo vídeo es del equipo de LUCA, que nos han hecho un seminario sobre SmartCities, donde Marta Rodríguez, Industry Expert de Public Sector, Transport, Tourism & Education, imparte este seminario sobre cómo las Administraciones Públicas están aprovechando el potencial del Big Data para gestionar de manera inteligente la movilidad y el turismo de las ciudades, optimizando los sistemas y rutas de transporte público para adecuarlas a las necesidades reales de los viajeros y comprendiendo el comportamiento de los visitantes para adaptar la oferta turística a la demanda real.
Figura 3: LUCA Talk SmartCites
El tercer vídeo es el que ha hecho el equipo de Movistar Home (Home as a Computer) que nos trae cómo funcionan los Trivia de las series Movistar Plus dentro de nuestro equipo Movistar Home. Os lo dejo aquí mismo.
Figura 4: Trivia de Series Movistar Plus en Movistar Home
El cuarto vídeo que os dejo es un resumen de nuestra participación como Telefónica Empresas en el último Digital Enterprise Show 2019 en Madrid, donde yo di una charla junto a mis compañeros de IoT, BigData, Cloud, Ciberseguriad, etcétera. Aquí el vídeo resumen.
Figura 5: Resumen del DES 2019 Madrid
Y el último que te dejo es anuncio de nuestro equipo de comunicación para avisar de que todos los blogs que teníamos en las unidades B2B de Telefónica para que ahora estén juntos en ThinkBig Empresas. Para que te suscribas si quieres seguir nuestros contenidos.
Ha sido hace nada, y ya están disponibles los vídeos del evento que realizaron los compañeros de LUCA en Madrid. Bajo el título de "Changing the Game with Big Data" presentaron algunos de los proyectos en los que hemos estado trabajando durante los últimos tiempo, con experiencias concretas contadas directamente por los propios clientes.
Figura 1: Sesiones de Changing the Game with Big Data en Vídeo
Yo tuve el honor de dar la bienvenida a los asistentes que puedes ver aquí, pero lo realmente importante son las charlas donde se pudo ver todo lo en lo que desde el equipo de LUCA Data-Driven Decisions se ha estado trabajando. Estas son las sesiones.
Figura 2: La propuesta de LUCA para transformar tu sector
Figura 3: LUCA Store: Conociendo mejor a tu cliente
En el Mobile World Congress presentamos LUCA Store, con varios casos concretos de clientes, que puedes ver en este vídeo de dos minutos donde se ve el poder de los insights generados.
Figura 4: LUCA Store
Figura 5: LUCA Transit: Innovación en la gestión de la movilidad en las smartciteis
Además del caso explicado en la charla de LUCA Transit de la movilidad de Zaragoza, ya en el Mobile World Congress de este año hablamos de cómo usar LUCA Transit con datos OpenData de las ciudades para medir la seguridad de las ciudades. Esta es la explicación de cómo se saca esa información.
Figura 6: LUCA Transit: Cómo medir la seguridad de las carreteras con Big Data
Figura 7: LUCA Tourism: Optimizando la oferta turística con Big Data
Figura 8: Big Data & Business con Synergic Partners
Figura 9: Sesión de Preguntas y Respuestas
No hay nada mejor que ver a tus clientes hablando de las soluciones creadas, y en el mundo del Big Data, donde la aplicación de los insights que se extraen de los datos tiene tanto impacto, más todavía. Esperamos que estas experiencias os den ideas para aplicar el poder del Big Data en vuestro entorno.
Los ataques a los sistemas SCADA utilizados en el control industrial es algo que puede tener consecuencias graves si no se han hecho los deberes de seguridad adecuados. Los sistemas industriales utilizados en estos entornos están formados por una buena cantidad de componentes de distintos fabricantes, PLCs, protocolos especiales y sistemas que a veces pasan muchos años antes de ser cambiados - o tan siquiera actualizados -. Y por supuesto, tienen vulnerabilidades que aparecen en sistemas PLCs [PLCs exponen passwords, PLCs vulnerables a Brute-Force] en el equipamiento utilizado en la construcción del sistema y en el software que se haya desarrollado a medida para dicha plataforma.
Figura 1: Intentan envenenar el agua en una planta depuradora en UK
Es un ecosistema complejo del que hay que preocuparse con cariño. Nuestro compañero en Eleven PathsClaudio Caracciolo (@holosec) conoce a la perfección estos entornos por su experiencia trabajando con ellos, y nos explicó en detalle cómo funciona en la charla que impartió dentro de las Eleven Paths Talks y que puedes ver online ya.
Figura 2: Comprendiendo la seguridad en sistemas industriales
Dicho esto, hoy quería centrarme en un caso explicado en el último informe Data Brech Digest publicado por Verizon, en el que cuentan cómo fue la investigación para descubrir el ataque que se había producido a un planta depuradora de agua de un distrito en Reino Unido. Los equipos de gestión del funcionamiento de la planta depuradora se dieron cuenta de que algo había pasado cuando saltaron las alarmas de control que vigilan que nada vaya mal en la planta al detectarse que la mezcla de componentes químicos que se estaba usando podría dañar la salud de las personas que la bebieran.
Figura 3: Intento de configurar agua "no potable" variando los compuestos químos
Esto sucede porque los sistemas SCADA se crearon para ayudar a los ingenieros a tomar las decisiones de seguridad más adecuadas, pero además del sistema informatizado y automatizados existen controles que verifican que ningún fallo provoque una situación no deseada, como la de que el agua que se entrega a los usuarios sea de mala calidad y nociva para su salud.
Errores en la gestión de la seguridad de la planta depuradora
Tras la investigación realizada por el Equipo de Respuesta ante Incidentes, la explicación resulto ser la acumulación de una serie de BASICS de seguridad no realizados por la empresa que gestiona el IT de la planta de seguridad y que os paso a resumir a continuación.
1) Arquitectura no segmentada de la red
La empresa cuenta con una aplicación web/mobile a la que los clientes se pueden conectar para la gestión de sus cuentas y sus pagos. Esto está alojado en un servidor web, pero que tiene conexión directa con el servidor SCADA, basado en un AS/400 (que también debería fortificarse). Este servidor AS/400, además, tenía conexión de a Internet, por lo que una vez llegado a él se podría sacar datos. Llegando a un servidor, es fácil acceder a las credenciales de acceso a otros servicios, incluso acceder a las passwords de gestión de los PLCs e incluso mucho más fácil, ya que puede que haya sistemas PLC sin passwords o fácilmente saltables.
Figura 4: Arquitectura de red de los sistemas de la planta. Desde el AS/400 acceso a todo.
2) Aplicación de pagos con mala gestión de identidades
Cualquier cliente de la empresa se podía conectar al sistema de pagos con un sistema de credenciales basado en usuario y contraseña, sin que hubiera ninguna protección de Segundo Factor de Autenticación o Autenticación Robusta, lo que permitía a un atacante hacerse fácilmente con alguna cuenta de usuario con ataques simples de phishing, troyanos, etcétera.
3) Aplicación de pagos con vulnerabilidades en el código del backend
La aplicación de pagos no estaba correctamente auditada y desde la sesión de un usuario era posible explotar bugs en el backend que permitieran acceder a los ficheros del servidor. No se sabe si la vulnerabilidad permitía subir una shell, era un ataque de LFI, o unDirectory listing, pero con este fallo se podía acceder a los ficheros del servidor.
4) Credenciales de acceso al sistema SCADA en AS/400 sin 2FA
De nuevo, el acceso al sistema SCADA utilizaba usuarios y contraseñas sin ninguna protección de Segundo Factor de Autenticación, así que cualquiera que se hiciera con las credenciales podría entrar a manipular el servidor.
5) Credenciales almacenadas en el servidor de la aplicación de pagos
Figura 5: Cúmulo de fallos en la gestión de las credenciales de acceso a los sitemas
6) Reutilización de credenciales en distintos sistemas
Al final, los atacantes se pudieron llevar la base de datos de los usuarios, ya que las credenciales funcionaban en otros sistemas conectados, como el servidor que hospedaba la aplicación financiera de la planta.
Por suerte, al manipular las cantidades de productos químicos con las que se hace la depuración del agua, las alertas de seguridad de la planta levantaron las alertas. De nuevo, un caso en el que el cúmulo de errores de seguridad lleva a que casi Security se convierta en Safety y haya un verdadero problema para los clientes de esta planta. Hay que agradecer que las Infraestructuras Críticas aplican conceptos de defensa en profundidad para no depender totalmente de un sistema informatizado y, en este caso, ha evitado una catástrofe.
Las redes industriales y, concretamente, las redes de sensores son hoy en día una realidad emergente y con muchas expectativas de cara al futuro tanto en entornos empresariales o públicos. Los grandes ayuntamientos están apostando por convertir sus ciudades en las llamadas “Smart Cities” con este tipo de estructuras. Entre las tecnologías que existen parece que hay dos a día de hoy que se imponen sobre los demás en cuanto a su aceptación en el mercado. Son el estándar IEEE802.15.4 y ZigBee, que entre ambos proporcionan un conjunto de protocolos y servicios a los usuarios para permitir una comunicación fiable y segura en este tipo de redes.
Figura 1: Smart Cities, ataques en redes IEEE 802.15.4 & ZibBee
Estas redes de sensores, al igual que la mayoría de redes inalámbricas, no están exentas de potenciales peligros que pueden ponerlas en un serio riesgo de compromiso de seguridad. Mostraré la implementación de un ataque de denegación de servicio mediante un caso real. Como prueba de concepto, se muestra como dejar inhabilitado un nodo de una red que utiliza la especificación IEEE802.15.4.
Smart City: Estructura básica de una red de sensores
No hay quien pueda negar que están de actualidad. Los equipos de gobiernos de todas las ciudades quieren tener ciudades inteligentes que controlen el riego, el tráfico, las plazas de aparcamiento en las calles, la recogida de la basura, el control de la calidad del aire, la temperatura en cada zona de la ciudad, los transportes públicos y el estado las playas.
Figura 2: Vídeo promocional del proyecto Valencia Smarty City
Las posibilidades de dotar a una ciudad de más y mejores servicios son grandes, y el primera paso es contar con una red de sensores que capture la información necesaria de todos los puntos de la ciudad. Sensores que midan la humedad y la temperatura en los jardines, sensores que detecten si un espacio de parking está ocupado o no, sensores que detecten si hay personas esperando en el semáforo, sensores que sean capaz de capturar cualquier información que sea útil para tomar una decisión de actuación en la Smart City.
Figura 3: Sensores de calidad del aire y en un contenedor de basuras
Todos esos sensores se comunican entre ellos y con el Gateway para gestionar estas la recogida de datos y, recibir las ordenes de configuración y actuación. Esta comunicación se hace - centrándonos en las redes creadas con las tecnologías de este artículo - con los estándares IEEE 802.15.4 y el protocolo ZigBee hacia los Gateways, que también deben estar colocados en las calles y que son los encargados de encaminar esos datos hacia los centros de control a través de una red de fibra óptica o WiFi, para que los datos queden almacenados en un Big Data sobre el que se pueda construir la inteligencia de actuación para mejorar la vida en la Smart City.
El ataque de Denegación de Servicio
Esta es una prueba de concepto en la que se ha llevado a cabo un ataque de denegación de servicio sobre una red con las tecnologías IEEE 802.15.4/ZigBee. El proceso que se ha seguido es muy simple y lo que se desea mostrar es la facilidad con la que ha sido posible dejar sin recursos un nodo de la red. Para montar la red ZigBee se han utilizado varios sensores (o motas). Concretamente se ha utilizado la plataforma Z1 de la marca Zolertia. Por otro lado, para simular el dispositivo atacante se ha utilizado un Sniffer/Inyector de paquetes la marca Atmel: el dispositivo RZUSBSTICK.
Figura 4: Dispositivo AVR RZUSBSTICK
En esta prueba de concepto es necesario que un sensor actúe como nodo encaminador (o Gateway, M1) y que el otro actúe como dispositivo RFD (Reduced Function Device) hoja, M2. Los dispositivos que funcionan como RFD son sensores que no cuentan con una fuente de energía constante, es decir, que funcionan con batería y a los que se les reduce las funciones para maximizar la vida útil de su reserva de energía. Para ello, si un dispositivo va a ser un sensor de temperatura y su misión va a ser solo recoger la temperatura y emitirla hacia la red para que llegue vía Gateway hacia el Big Data, se le configura como RFD.
En una red con múltiples sensores, dependiendo de si se han configurado como FFD (Full Function Device) o RFC (Reduced Function Device) se pueden configurar diferentes topologías de red, ya que un RFD solo emite su información, mientras que un FFD puede hacer un encaminado de comunicaciones de otros. Así, existen topologías árbol, en estrella o en malla de redes de sensores. Para esta PoC, la topología escogida es la de estrella y el nodo al que se atacará agotando los recursos es el que actúa como Gateway, por lo que en el caso de tener más sensores conectados a la mota Gateway, todos dejarán de comunicarse.
Figura 5: Topología en estrella en red de sensores
Para poder programar las motas en este prueba de laboratorio se han de conectar inicialmente a una sistema GNU/Linux Debian con un cable USB/MicroUSB, después ya no es necesario esa conexión y pueden operar mediante baterías, (como en una implantación real ) y por tanto ser un nodo completamente autónomo.
El siguiente paso consiste en examinar los paquetes que se envían en el momento de la asociación de la mota M2 en la red y los que se envían durante la transmisión de paquetes al servicio para poder, posteriormente, inyectar los paquetes previamente modificados desde el dispositivo atacante. Para averiguar qué paquetes circulan por la red durante las fases de asociación de dispositivos y la conexión al servicio se ha utilizado el software WireShark y la herramienta zbdump. Para escuchar la red mediante el dispositivo RZUSBSTICK son necesarias las herramientas que se encuentran en KillerBee. Eso es debido a que una simple tarjeta WiFi convencional no puede escuchar las frecuencias de las redes IEE 802.15.4
Mediante el dispositivo RZUSBSTICK, el software Wireshark y la herramienta zbdump se ha determinado cuáles son los paquetes esenciales y necesarios para llevar a cabo la asociación de un dispositivo al encaminador. Y al mismo tiempo se ha obtenido el paquete que se envía cuando se solicita el servicio de la mota M2. Esta información se ha utilizado para construir posteriormente unos paquetes maliciosos específicos con los que atacar el sistema.
Figura 6: Datos de asociación de una mota a la red usando ZigBee
La Figura 6 muestra los datos que se han obtenido al escuchar la red inalámbrica, con estos datos se pueden falsificar nuevos nodos, ya sea con la utilización de motas nuevas o con la posibilidad que aporta el dispositivo RZUSBSTICK que es capaz de inyectar tramas en el medio de transmisión. Con esta capacidad, podemos hacer un ataque de spoofing para simular la entrada de una nueva mota a la red. En la Figura 7 podemos ver como se ha falsificado una nueva mota dentro del sistema con una MAC “CAFECAFE”
Figura 7: Adición de una mota falsa con MAC "CAFECAFE"
El protocolo ZigBee cifra los datos que se envían entre los diferentes nodos, pero sigue funcionando sobre el estándar IEEE 802.15.4, por lo que aunque no se puedan obtener los datos, sí que podemos insertar una mota a nivel de capas de comunicación más bajas y obtener los datos de inicio y destino de cada una de las transmisiones. Ya que el estándar no cifra los datos. La Figura 8 muestra cómo podemos obtener los datos de la comunicación entre las motas, aunque funcionen con ZigBee, por lo que podemos hacer una composición exacta de la red y su modo de funcionamiento, y saber cada cuando se despiertan los sensores para transmitir los datos hacia el Gateway.
Figura 8: Captura de comunicación ZigBee
ZigBee funciona con tres contraseñas a diferentes niveles. Una que viene de fábrica, con la que se insertará en la red ZigBee del mismo fabricante y se crearan las otras dos claves. La segunda, creada a partir de la primera, común a toda la red y que servirá para las comunicaciones Broadcast, y una tercera única, que se obtiene mediante un proceso llamado SKKE, entre el Gateway y cada nodo, con la que cifrará el contenido que se envían entre ellos dos.
Posibles ataques a una red IEEE 802.15.4 & ZigBee
De forma rápida, en un esquema como el que se ha mostrado, podríamos realizar algunos de estos ataques que podrían afectar al funcionamiento, y por tanto a la seguridad, de los servicios desplegados en una Smart City sobre una red de sensores vulnerable.
• Denegación de servicio (Denial of Service-DOS). De difícil mitigación, colocando un nodo que controle las comunicaciones permanentemente.
• Escucha de la red (eavesdropping): un dispositivo escucha la red a la espera de recibir la información que se transmite. Con cifrado se hace más difícil la escucha.
• Usurpación de identidad (spoofing): Hacerse pasar por otro nodo de la red para recibir y enviar datos de terceros. Si es encaminador podrá capturar todo el tráfico que pase por él.
• Reenvío de paquetes (replay): Consiste en el reenvío, o no, de paquetes capturados anteriormente para desestabilizar la red o el nodo que los recibe y que únicamente espera un dato. El control de secuencia ayudará a la mitigación de este ataque.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
