Atacul Suisun City a afectat 911: exercițiu de continuitate când echipele pierd rețeaua

Suisun City, California, a detectat pe 7 august 2026, în jurul orei 05:45, software malițios în sistemele IT. Orașul și-a oprit întreaga rețea pentru a limita incidentul și a conserva probele, iar pe 8 august Consiliul Local a declarat stare de urgență pentru a putea accesa rapid sprijin și resurse.

Comunicatul oficial spune că incidentul a afectat rutarea apelurilor 911, dispeceratul poliției și pompierilor, evidențele și alte servicii municipale. Dispecerii au continuat să preia apeluri prin centrul Solano County, iar poliția și pompierii au continuat să răspundă solicitărilor.

Ce este confirmat și ce nu știm încă

• Orașul confirmă infectarea și compromiterea sistemelor IT cu software malițios și oprirea controlată a întregii rețele.
• Au fost afectate operațiuni de siguranță publică: rutarea 911, dispeceratul poliției și pompierilor și sistemele de evidență.
• Emergency Operations Center a fost activat, iar investigația implică FBI, Department of Homeland Security și California Office of Emergency Services.
• Serviciile de urgență au rămas active prin centrul de dispecerizare al Solano County; publicul nu a fost informat despre un pericol iminent.
• Pe 11 august, orașul anunța prelungirea închiderii City Hall și a serviciilor publice fizice până pe 14 august, în timp ce operațiunile interne și investigația continuau.
• Nu sunt confirmate public vectorul inițial, autorul, utilizarea ransomware, exfiltrarea de date sau amploarea unei eventuale expuneri.

De ce continuitatea este și o problemă de awareness

Un plan tehnic de disaster recovery nu este suficient dacă angajații nu știu ce canal rămâne valabil, cine poate declara schimbarea și cum se verifică o instrucțiune primită în afara sistemelor obișnuite. În timpul unei întreruperi, atacatorii pot profita de confuzie cu apeluri, mesaje personale sau documente care pretind că oferă accesul de urgență.

• Un coleg primește pe telefonul personal o „nouă adresă VPN” și i se cere să instaleze un client pentru continuitate.
• Un manager primește un document extern cu presupusele numere alternative și îl distribuie fără verificare.
• Help desk-ul este rugat să dezactiveze MFA deoarece serviciul obișnuit „nu funcționează”.
• Un furnizor cere acces administrativ temporar, invocând aprobarea verbală a conducerii.
• Comunicarea publică neactualizată îi face pe oameni să caute răspunsuri pe canale neoficiale, unde pot apărea instrucțiuni false.

Regula de continuitate: canalul alternativ trebuie stabilit înainte de incident

Un canal de rezervă creat în mijlocul crizei este greu de autentificat. Organizația trebuie să definească anterior cine îl activează, cum este anunțat, ce tip de informație poate circula și cum se validează identitatea persoanelor care dau instrucțiuni.

• Păstrează offline lista scurtă cu roluri, numere de contact, furnizori critici și centre alternative; verifică periodic dacă este actuală.
• Folosește o frază sau un mecanism procedural de validare pentru activarea canalului, fără a transforma un secret partajat permanent într-o singură barieră de securitate.
• Definește ce decizii pot fi luate prin telefon și ce schimbări cer confirmare printr-un al doilea canal și două persoane.
• Interzice explicit trimiterea parolelor, codurilor MFA, cheilor ori accesului privilegiat pe chat-uri improvizate.
• Pregătește mesaje publice scurte care spun ce funcționează, ce este indisponibil și care este sursa oficială pentru actualizări.

Tabletop în șase injecturi

Exercițiul poate fi adaptat pentru administrație publică, sănătate, utilități sau orice organizație cu servicii care nu pot aștepta restaurarea completă a rețelei. Participă IT, operațiuni, help desk, securitate fizică, comunicare, juridic și management.

• Inject 1 — la 05:45 sunt detectate sisteme compromise. Cine are autoritatea să izoleze rețeaua și ce servicii trebuie menținute cu prioritate?
• Inject 2 — telefonia și dispeceratul intern nu mai pot fi folosite normal. Cine activează centrul alternativ și cum sunt distribuite numerele verificate?
• Inject 3 — un angajat primește pe WhatsApp o aplicație „de urgență” trimisă de cineva care cunoaște incidentul. Cum verifică și unde raportează?
• Inject 4 — un furnizor cere acces privilegiat pentru restaurare. Ce aprobare, jurnalizare și limitare temporală sunt obligatorii?
• Inject 5 — apare online afirmația că serviciul 911 este complet oprit. Cine publică actualizarea factuală și cum evită divulgarea detaliilor investigației?
• Inject 6 — sistemele revin parțial. Ce criterii trebuie îndeplinite înainte de reconectare și cine confirmă revenirea la canalul normal?

Decizia și dovada pentru fiecare rol

• IT documentează sistemele izolate, dependențele, ordinea restaurării și criteriile de reconectare; nu promite un termen înainte de verificare.
• Operațiunile mențin serviciile esențiale prin procedurile alternative și notează manual evenimentele care trebuie reconciliate ulterior.
• Help desk-ul nu reduce cerințele de autentificare sub presiunea incidentului și folosește callback către numere cunoscute.
• Managementul stabilește prioritățile și acceptă explicit riscurile temporare, fără a transforma urgența într-o permisiune nelimitată.
• Comunicarea diferențiază impactul asupra sistemelor de disponibilitatea serviciului și publică aceeași sursă oficială pe toate canalele.
• Echipa de securitate păstrează probele și cronologia, verifică accesul neautorizat și împiedică restaurarea să distrugă evidența necesară investigației.

Ce măsurăm după exercițiu

• Timpul până la izolarea inițială și timpul până la activarea funcției alternative esențiale.
• Procentul participanților care găsesc contactele corecte fără acces la e-mail sau intranet.
• Procentul solicitărilor urgente verificate printr-un al doilea canal înainte de acordarea accesului.
• Numărul deciziilor fără owner, termen, criteriu de revenire sau dovadă păstrată.
• Timpul până la prima comunicare publică factuală și numărul canalelor care au rămas cu informație contradictorie.
• Calitatea reconcilierii înregistrărilor create manual după restaurarea sistemelor.

Pentru Learning Awarely, lecția transferabilă este că reziliența nu înseamnă doar backup și redundanță. Înseamnă ca fiecare rol să știe ce protejează, pe cine sună, ce refuză și ce dovadă lasă atunci când rețeaua obișnuită nu mai poate fi folosită.