Comunicat del COEINF de 21 de juliol de 2024:
Una actualització automàtica d’un antivirus paralitza milers d’organitzacions i infraestructures crítiques arreu del món
La degana d’aquest col·legi es lleva divendres al matí molt i molt d’hora i veu una perduda d’una periodista del 3cat que la cerca d’urgència per fer unes declaracions sobre “tema aeroport”.
Ella era a Madrid, a punt d’una reunió important, anava amb el temps quadrat i no havia llegit encara els titulars del dia.
Quina fou la seva sorpresa quan comença a veure notes d’alguns dels grups de whats professionals dels quals forma part (tots carregats de professionals del sector) i troba un munt de col·legues compartint des de les 7 del matí que tenen pantalles blaves, que no sembla un problema propi, que no arrenquen els sistemes i descobreix que el grau d’afectació de la incidència no només afecta infraestructures crítiques com hospitals i aeroports sinó tota mena de línies de producció, sistemes de teletreball de no sé quantes empreses, bancs, i accessos variats a informació, serveis digitals a tot arreu…. mundialment!
Des del Col·legi d’Enginyeria Informàtica de Catalunya (@COEINF) volem, primer de tot, posar en valor la tasca ingent de tots els nostres professionals que des de divendres a primeríssima hora s’han estat deixant la pell per superar la incidència i recuperar tots els sistemes, accessos i serveis de les seves organitzacions sense descans, alguns encara treballen. Cap ha mirat el rellotge, creieu-ho. Cap s’ha fixat si li tocaven ja les vacances. I el que hem vist ha estat un teixit hiperresponsable de professionals que, com sempre passa al nostre sector, per la porta del darrere i sense fer molt soroll, han anat cosint i recosint tot el dany que una decisió aliena havia procurat a les seves organitzacions i de retruc a tots els seus usuaris, interns i externs.
Dissabte, entrada la nit, encara una companya ens anunciava exhausta que havia pogut aixecar per fi el darrer servidor de la seva empresa, una multinacional globalment afectada per l’incident.
Dijous a mitjanit, la darrera actualització automàtica de l’antivirus Falcon sensor Crowdstrike havia tombat Azure, el sistema operatiu Windows de Microsoft i milers de sistemes i usuaris d’arreu n’han rebut les conseqüències.
No parlem de qualsevol. Parlem dels grans! Crowdstrike és una de les empreses més importants del món en seguretat per serveis d’internet. I Azure és el núvol de Microsoft, la propietària de Windows.
L’incident te a veure amb una posta en producció d’una actualització automàtica que no estava prou provada per detectar la seva perfecta funcionalitat abans d’arriscar que alguna cosa falli i afecti sistemes i usuaris reals. En aquest cas, el que s’actualitzava no era un sistema local d’abast limitat. No. S’actualitzava un antivirus amb milers d’organitzacions que hi havien confiat la seva protecció, la seva pròpia seguretat.
Per més d’un dia una falla en aquesta actualització ha provocat un desgavell de dimensions considerables i ha paralitzat el normal desenvolupament d’organitzacions de tota mena, incloses infraestructures crítiques com els hospitals, els aeroports, en aquest darrer cas justament el cap de setmana de canvi de torn de vacances, probablement un dels caps de setmana amb més afluència de vols i passatgers de l’any. L’impacte de la incidència el podrem avaluar més exactament els dies que venen, però és enorme i d’abast global.
A hores d’ara encara no disposem de prou informació per saber ben bé com ha estat possible que una actualització que no era compatible arribés a desplegar-se urbi et orbi i veurem els dies que venen que és el que ha passat realment.
Però des del Col·legi sí que podem apuntar algunes qüestions que són d’extrema importància per la seguretat de les organitzacions.
En primer lloc, sembla inexplicable que CrowdStrike hagi desplegat un upgrade que no era compatible amb una eina tan utilitzada com Azure i això apuntaria, en principi, a una mala praxi per part de Crowdstrike pel que fa als testos necessaris abans de llençar una actualització d’abast global. La companyia ha apuntat un error humà (que dissabte ja va dir que estava resolt) i ha demanat disculpes, però encara es desconeix ben bé que ha pogut passar realment i que ells hagin reparat la incidència no ha descol•lapsat els impactats que encara estan recuperant equips, molts manualment i d’un en un.
Per altra banda, sembla que Microsoft tampoc ha rebut l’actualització abans que la resta d’usuaris de Falcon i no ha pogut detectar la incompatibilitat abans que es fes el desplegament massiu. Tractant-se de companyies que donen serveis d’infraestructures TIC a tantíssims usuaris potser seria bo fer desplegaments en dues fases on poder detectar abans del desastre generalitzat si alguna cosa no està prou correcta. De fet, el més recomanable fora que Crowdstrike i Microsoft tinguessin un entorn de proves comú on poder fer els testos i validacions exhaustius abans de llençar a tots els clients.
Finalment, s’ha pogut veure com un gran nombre d’organitzacions, incloent-hi infraestructures crítiques tenen processos d’actualització automàtica que porten a producció directament algunes actualitzacions. És cert que en el cas d’actualitzar un antivirus el temps és crític (si apareix un nou tipus d’atac, cada minut que passa fins que l’antivirus incorpora la protecció és un risc per a l’organització de rebre aquell atac) com també és cert que una companyia com Crowdstrike genera prou confiança per a assegurar que quan proposa una actualització es pot desplegar sense riscos. I no és menys cert que les companyies que utilitzen serveis TIC externalitzats (moltíssimes) estan constantment sotmeses a actualitzacions de tots els seus proveïdors que són difícils de gestionar i automatitzar tantes com es pugui pot ser en moltes ocasions l’única manera de no tenir el departament de TIC de la companyia col·lapsat verificant actualitzacions tota l’estona. Però també és cert que en moltíssimes companyies no s’inverteixen els recursos necessaris per mantenir l’entorn de proves que permeti un test previ al desplegament real d’actualitzacions o nous productes.
Quatre factors decisius a conduir moltes d’aquestes empreses a negociar actualitzacions automàtiques amb els seus proveïdors de més confiança.
Al final l’incident posa de manifest la importància dels processos de QA (assegurament de la qualitat) i de validació dels softwares previs a la posta en producció de canvis i actualitzacions. I posa de manifest els perills de no fer-ho.
Però per poder-ho fer correctament és molt important dedicar pressupost i recursos a aquests processos com a part crítica de l’estabilitat de tota l’estructura TIC de la companyia. Des del COEINF voldríem novament interpel·lar tot el sector per anar evolucionant cap a organitzacions que mantinguin els seus entorns de proves com cal per evitar escenaris com els que hem viscut aquests dies. Sabem que si el proveïdor fa el que toca aquestes coses no haurien de passar. Però en realitat no tenim garantia que sempre sigui així i el més segur és fer proves internes abans que alguna falla en el proveïdor ens paralitzi el negoci. Apuntaríem des d’aquí que hi hauria encara una passa més que ajudaria a incrementar la seguretat d’aquests processos. Fora de fet més efectiu encara automatitzar els testos previs sobre l’entorn de proves i el llançament de l’actualització automàtica condicionada a passar els testos, més que no pas desplegar directament en producció.
Rebem sovint feedback dels nostres professionals sobre les dificultats que es troben perquè les seves organitzacions els aprovin el desplegament d’aquests entorns de proves per un tema principalment de pressupost. Però el fet és que als consells d’administració de les organitzacions sovint no s’entén prou bé la raó de ser d’aquestes peticions i no se’ls hi dona la importància real que tenen únicament per una manca de percepció del valor incalculable que representen per la companyia. Només cal veure com han baixat les accions de Crowdstrike i Microsoft el mateix dia de l’incident.
Invertir en qualitat del software i en seguretat no és mai un caprici prescindible, vist que les TIC constitueixen ja fa temps les infraestructures bàsiques de companyies i ecosistemes. Certament, aquestes inversions prenen sentit per evitar grans danys en situacions molt puntuals, i en esdeveniments que no es donen gairebé mai. Però mentre ningú discuteix les inversions necessàries a les organitzacions contra robatoris o incendis i ningú escatima en les assegurances i protocols de prevenció corresponents, destinades a donar protecció si mai passa res (encara que gairebé mai passa res) ens falta encara agafar consciència que les TIC de la companyia també s’han de tractar amb la mateixa cura i prevenció que els focs i robatoris.
D’altra banda, el gran impacte que ha tingut aquest incident, evidencia els perills de la dependència que tantes organitzacions tenen d’aquestes grans proveïdores d’infraestructura tecnològica, on es produeix una “confiança” obligada a les seves actualitzacions, derivada directament de tot el model de distribució de software, i que en realitat representa un risc que no estem tractant com mereix.
Totes les organitzacions han d’estar degudament preparades per poder prevenir adequadament disfuncions del negoci i, com dèiem, els entorns de proves i les verificacions prèvies a la posta en producció sens dubte ajudaran. Però també cal estar ben preparat per actuar ràpidament quan es produeix una disfunció que no s’ha pogut evitar. Això, més enllà d’inversió, entorns de proves i protocols preventius i de mitigació de l’impacte, requereix també un altre element tant o més crític que els ja esmentats. Gestionar el paper clau de les TIC a les organitzacions i les seves interconnexions cada cop més nombroses amb l’ecosistema és una tasca d extrema complexitat. Els professionals a càrrec de les TIC de l’organització han de tenir la formació i coneixements necessaris per poder gestionar aquesta complexitat amb totes les seves implicacions i cal també prendre consciència que la preparació que cal per a aquestes posicions requereix especial atenció.
I finalment, faltaria reflexionar globalment sobre l’actual política d’actualitzacions de software. Quantes vegades, si no et preocupes de desactivar la configuració del teu pc et salta una actualització automàtica de sistema operatiu enmig d’una classe, una presentació pública, un consell d’administració o una demostració de producte a client, entre d’altres. En aquesta ocasió l’actualització s’ha disparat el dijous abans d’un cap de setmana crític pels aeroports per exemple, i comportava un risc inassumible per aquest sector. I en altres moments seran crítics altres sectors.
Negociar quan i com es fan aquests upgrades hauria de formar part de processos acordats amb tots els col·lectius implicats i també seria important assegurar-se que quan es treu un producte a mercat està prou provat per aguantar amb solvència garantida un interval prou llarg de temps per no requerir actualitzacions cada setmana, ni cada quize dies. Entenem que els antivirus s’han d’actualitzar a remolc de les vulnerabilitats que es van detectant, però les actualitzacions constants de tots els proveïdors saturen els sistemes i dificulten poder atendre com cal les que estan destinades a protegir la seguretat de les organitzacions i els usuaris.
En resum, les recomanacions del Col·legi Oficial d’Enginyeria Informàtica de Catalunya se sintetitzen així:
Per aquells que distribueixen software:
- tenir processos de QA que garanteixin que s’han testejat i validat prou productes, serveis i actualitzacions abans de posar-les en producció.
- evolucionar cap a una política que defugi les actualitzacions constants de pocs detalls i concentrar-se en fer-ne poques a l’any molt provades i de millora significativa per no saturar el pla d’actualitzacions dels clients.
- disposar d’entorns comuns de proves amb aquells actors que distribueixen infraestructures tecnològiques a moltes empreses i validar conjuntament amb ells la compatibilitat de les actualitzacions abans d’enviar-les massivament a tothom.
- negociar amb cura quan es fan les actualitzacions als diferents clients per minimitzar l’impacte i ser sensible als calendaris dels clients i usuaris finals en la mesura del possible.
Pels que utilitzen serveis externalitzats de software:
- tenir bons processos de QA que incloguin un bon entorn de proves on verificar les actualitzacions abans de passar-les a producció.
- que l’actualització automàtica inclogui una fase prèvia de testatge exhaustiu sobre l’entorn de proves i desplegament a producció només si valida el test previ.
- negociar amb els proveïdors dates de mínim impacte per fer actualitzacions i també estudiar el millor moment pels usuaris de la companyia.
- disposar de plans de recuperació d’incidències que permetin actuar de pressa si no es pot evitar la incidència.
- tenir cura de posar al capdavant de les posicions que han de gestionar tota aquesta complexitat professionals degudament formats i capacitats.
Des del COEINF esperem que la recuperació de la normal operativa de tots els afectats es pugui assolir com més ràpidament millor i que aquest incident contribueixi a elevar l’estat de consciència de tot l’ecosistema sobre el paper central que juguen les TIC a les organitzacions i la importància de disposar de professionals i infraestructures adequades per assegurar la disponibilitat dels sistemes amb la màxima qualitat i garanties.
I finalment, reiterem el reconeixement a l’esforç de tots els professionals que han treballat sense descans en la mitigació de l’incident.
