@fernand0 de @unizar
‼️“separar, aislar y pensar que las cosas han fallado, fallan y fallarán”
👉“Copias de #seguridad automáticas, estrategias adecuadas como el 3,2,1 y si no has comprobado nunca tu copia de seguridad, hazlo”
‼️" No protegemos los equipos, protegemos el negocio” pic.twitter.com/MlQdrMjYu6

— Ingenieros Industriales-Aragón y La Rioja (@COIIAR) March 14, 2024

El 14 de marzo se celebró el Congreso Industria 4.0, organizado por el Colegio de Ingenieros Industriales de Aragón y La Rioja y el Colegio de Ingenieros de Telecomunicaciones de Aragón.

Mis compañeros José Ángel Castellanos Gómez y Ángel Fernández Cuello, como directores de la Cátedra de Transformación Industrial colaboraban con el congreso y me invitaron a hablar de seguridad. Les propuse hablar de ciberseguridad industrial con algunos ejemplos que podrían permitirnos sacar algunas conclusiones y algunas recomendaciones y allí estuvimos.

en El Congreso Industria 4.0 señala que la fabricación virtual ya ha entrado en la industria hay un resumen del desarrollo y también se puede ver el vídeo (se puede ver la jornada completa; enlazo a la intervención).

Hablamos de tres ejemplos lejanos (en tiempo y en distancia algunos, otros sólo en distancia):

• El caso de STUXNET (2010)
• El ataque a las centrales energéticas de Ukrania (2015)
• El ataque a SolarWinds (2019-2020)

Todos ellos en instalaciones más o menos protegidas, más o menos lejanos, pero con aparatos, tecnología y herramientas muy parecidas a las que puede haber en cualquier fábrica de nuestro entorno. Sobre el último ataque, además se puede comentar la introducción por parte de la Presidencia de EEUU de la (Software Bill of Materials, SBOM) como una manera de, por lo menos, conocer qué problemas podemos tener ante un ataque a la cadena de suministro.

También aprovechamos para contar que todo esto ahora es un negocio, existe un mercado donde se compran y se venden las herramientas para realizar los ataques, las vulnerabilidades, … y cómo las personas somos el eslabón débil y lo fácil que es engañarnos o hacernos reaccionar en beneficio de los atacantes.

Aprovechamos para comentar un par de artículos uno de los cuales ya lo habíamos comentado en El phishing: los usuarios lo tienen realmente difícil que dicen justamente eso: es difícil para un usuario normal detectar todos los posibles fraudes que le pueden llegar.

Luego comentamos algunos ataques que están vigentes y que son especialmente en el contexto del que hablábamos: botnets con dispositivos poco vigilados, secuestro de información (RansomWare) y, ya en el contexto más de la oficina, la sustitución de facturas (que parece que es un ataque que se está produciendo bastante últimamente).

Finalmente, tres recomendaciones:

• Conocer y hacer mapas de nuestro entorno, para ver qué hay en nuestras redes.
• Compartimentalizar y segmentar, para que los fallos que pueda haber en algún sito no afecten a todos nuetros sistemas.
• Estar preparados para lo peor, haciendo copias de seguridad (y conocerlas, y comprobarlas,…).

Terminamos con una brevísima mención a que hay leyes (y que seguramente habrá más).

Un rato muy agradable en el que pudimos hablar de cosas que nos gustan en un entorno en el que creo que fueron bien recibidas.

He visto que nombran la cosa en Le Congrès Industrie 4.0 souligne que la fabrication virtuelle est déjà entrée dans l’industrie

También en El Congreso Industria 4.0 señala que la fabricación virtual ya ha entrado en la industria y en Las empresas aragonesas tienen un grado de madurez digital un 38% superior a la media.

Publicado originalmente en En el congreso Industria 4.0 hablando de Ciberseguridad Industrial

En Introduction to Cross-Site Leaks (XS-Leaks) – Attacks and Mitigations hay una introducción a este ataque, que sirve para recolectar información acerca de los usuarios, a través de fallos de programación cruzada (Cross-site scripting (XSS)) y la utilización estos fallos para acceder a información como atributos de los usuarios, permisos, papeles (roles). Y también al historia de palabras de búsqueda y otras informaciones que se almacenan en memorias temporales (caches).

XS-Leaks then allow attackers to collect information about website visitors that is usually not available. This information can give the attacker clues about the user’s identity. This can include if the victim is logged into other web applications allowing access to user attributes, permissions, or roles. Additionally, a victim’s keyword search history can be queried as well as privately cached browser objects, such as images, based on how the website caches these resources.

Interesante.

Si vuestros sistemas son tan 'seguros' que se convierten en difíciles o incómodos de usar, la gente utilizará alternativas. Para cosas del trabajo. Aplica especialmente al correo y sistemas de mensajería

— fernand0 (@fernand0) February 20, 2024

Creo que ya lo he dicho aquí pero no me importa repetirme: la ciberseguridad tiene que ir de la mano de la usabilidad (ergonomía, comodidad, facilidad de uso ,…) y de la economía (¿cuánto cuesta? en todos los sentidos, se entiende). Y por ello nombro siempre que puedo Symposium on Usable Privacy and Security (SOUPS) y Workshop on the Economics of Information Security (WEIS). Trato de leer todos los años unos cuantos de los artículos que allí se publican. Hoy solo hablaremos de la parte de comodidad de uso. La economía queda para otro día.

Por este motivo me alegró leer When Security Gets in the Way que es de hace unos años, pero que hablaba del tema.

Both conferences were attended by experts in usability, security, and privacy. Both conferences emphasized that if we ever are to have systems with adequate security and privacy that people are willing to use, then the three fields must work together as a team. Without usable systems, the security and privacy simply disappears as people defeat the processes in order to get their work done.

Muchas veces las recomendaciones de seguridad son arbitrarias, y además los profesionales se las saltan sin demasiados problemas, nos dice:

We are being sent a mixed message: on the one hand, we are continually forced to use arbitrary security procedures. On the other hand, even the professionals ignore many of them.

Necesitamos mejor comprendes los problemas, las herramientas que proporcionamos a los desarrolladores y al resto de personas que interactuarán con los sistemas.

If this endeavor is to be successful, we need more understanding of the issues, better toolkits to deliver to developers, and a comprehensive set of tools, scripts, and templates to provide the administrative support staffs around the world so that the rules and polices they develop will be consistent both with one another and with best practices of the security and privacy community.

¿Es necesario que mejorar la seguridad haga todo más difícil de usar? Cuando sean necesarios pasos adicionales, ¿la gente se quejará? No necesariamente.

Does added security make things more difficult to use? Will people always resent the extra steps? The answer to both questions is the same: Not necessarily.

Más tarde comenta sobre uno de los fallos de este tipo, relacionado con las contraseñas: mitos, sobreactuación, …

Want a classic example of a failure? Passwords. There are several myths in the world about security, but the most pervasive of these has to do with password security. Look at Northwestern University’s password requirements: an over-reaction to the problem of password discovery through brute-force attacks.

Dice muchas más cosas. Lectura interesante.

Me he autocitado en el tuit de arriba porque el otro día me encontré un caso de una organización que ponía tantas dificultades a sus usuarios para utilizar el correo corporativo que terminábamos comunicándonos con ellos a través de sistemas alternativos de correo. Eso no es seguridad.

Siempre he pensado que en el mundo del sofware libre es difícil estar seguros de que estamos ejecutando el programa del que tenemos el código en dos situaciones: cuando instalamos un binario que alguien nos proporciona, o cuando utilizamos una aplicación web. Si hablamos de teléfonos móviles y las tiendas de aplicaciones, en muchas ocasiones miro en F-Droid antes de instalar una aplicación de la ‘tienda’ de Google. Es más fea y tiene menos programas, pero también nos da la tranquilidad (si nos instalamos programas con un historial razonable y gente confiable) de que estamos un poquito más cerca del desarrollador.

Por eso me gustó leer algunas novedades que anunciaron hace algunas semanas en Reproducible builds, signing keys, and binary repos.

Las construcciones reproducibles (reproducible builds) nos aportan garantías desde el punto de vista de poder verificar que lo que se instala corresponde, efectivamente, al código fuente asociado. A eso le han añadido la posibilidad de que el desarrollador firme los paquetes que instalamos, lo que nos protegería frente a un ataque malicioso que sustituyera algo en la plataforma.

A few advantages are pretty clear: higher trust is the first thing coming to mind, as now two parties (F-Droid and the developer) can both confirm the integrity of the distributed APK.

El artículo desarrolla un poco más algunos temas, pero dejamos a quien tenga interés su lectura.

Mantengo la idea de que en un mundo en el que poca gente presta atención a la seguridad, parece que las únicas medidas que puedan ayudarnos un poco son las leyes. No lo digo solo yo, utilizo de vez en cuando un artículo de Bruce Schenier en el que hablaba del tema, Why Was SolarWinds So Vulnerable to a Hack? y me gusta citar un par de párrafos completos sobre el tema (los pongo al final).

El caso es que con las leyes, el cumplimiento y los procedimientos puede ocurrirnos que sigamos perdiendo de vista el objetivo, que es estar más seguros. De eso hablaban en Is the cybersecurity community’s obsession with compliance counter-productive?.

El ejemplo con el que empieza es ilustrativo: ¿alguien cree que en caso de accidente de nuestro avión tenemos más probabilidades de sobrevivir si las mesitas están correctamente plegadas y las maletas de mano están adecuadamente posicionadas en su lugar?

Does anyone think the chances of surviving a plane crash increase if our tray tables are locked and our carry-on bags are completely stowed under our seats?

Pero alguien lo indicó en alguna regulación y a nadie se le pasaría por la cabeza saltarse ese procedimiento.

Luego nos dice: casi todos los problemas de seguridad que aparecen en las empresas tienen que ver con vulnerabilidades no solucionadas, robo de credenciales y por ataques de programas maliciosos (que entran típicamente a través del phishing).

Esto no tiene mucho que ver con la normativa y, a lo mejor, centrarse en ella nos resta tiempo y personas para dedicarse a lo importante.

And how many would deploy those compliance and auditing resources to patch more vulnerabilities, invest in additional cybersecurity expertise, tools to identify and reduce their external threat footprint, and myriad other effective measures to genuinely reduce their organization’s cyber risk?

Luego reconoce que, seguramente, la gente de ciberseguridad sigue ese camino porque les permite tener las espaldas cubiertas.

The less obvious reason for our community’s love for compliance is that it covers behinds. “Yes, we were breached, but we did everything we were supposed to do, so don’t blame us.”

Pudiendo estar de acuerdo en la gestión de recursos creo que el autor pierde de vista que hay un número grandísimo de organizaciones que dedican cero recursos a la ciberseguridad. Así que, a lo mejor, poner leyes es una forma de obligarles a pensar en ella. En un mundo ideal todo el mundo haría su trabajo y, efectivamente, a lo mejor cada quien debería poder elegir a qué destina sus recursos. Pero el mundo no es así, lamentablemente.

Los párrafos de los que hablaba arriba:

There are two problems to solve. The first is information asymmetry: Buyers can’t adequately judge the security of software products or company practices. The second is a perverse incentive structure: The market encourages companies to make decisions in their private interest, even if that imperils the broader interests of society. Together these two problems result in companies that save money by taking on greater risk and then pass off that risk to the rest of us, as individuals and as a nation.

The only way to force companies to provide safety and security features for customers and users is with government intervention. Companies need to pay the true costs of their insecurities, through a combination of laws, regulations and legal liability. Governments routinely legislate safety — pollution standards, automobile seatbelts, lead-free gasoline, food service regulations. We need to do the same with cybersecurity: The federal government should set minimum security standards for software and software development.