🛠️NIS2 pentru ICT Service Management (MSP / MSSP) — termene, obligații, amenzi

MSP/MSSP trebuie sa implementeze cele zece masuri minime prevazute de NIS2 Art. 21(2)(a-j): politici de risc si securitate, tratarea incidentelor, continuitate si recuperare, securitatea lantului de aprovizionare, achizitie si dezvoltare ICT, evaluarea eficacitatii, igiena si training, criptografie, securitate HR si control acces, MFA [C2]. Pentru MSP si MSSP specifically, Regulamentul (UE) 2024/2690 din 17 octombrie 2024 detaliaza cerintele tehnice si metodologice: anexa la regulament contine 13 titluri tematice (politica de securitate, risc, tratarea incidentelor, continuitate, lant de aprovizionare, achizitie ICT, detectie / monitorizare / logging, vulnerabilitati, igiena si training, control acces, resurse umane, gestiunea activelor, securitate fizica) [C3][C8]. Cadrul se bazeaza pe ISO/IEC 27001, ISO/IEC 27002 si ETSI EN 319401 [C2]. Organul de conducere aproba si supravegheaza implementarea (NIS2 Art. 20) [C15].

MSP/MSSP au o pozitie particulara in lantul de aprovizionare: sunt furnizori ICT pentru toti clientii lor si, in acelasi timp, depind de propriii lor furnizori (RMM, EDR, file transfer, identity provider, hyperscaleri). NIS2 Art. 21(2)(d) cere managementul securitatii lantului inclusiv pentru relatiile cu furnizorii directi [C9]. Anexa Titlul 5 al Reg. (UE) 2024/2690 detaliaza: politica scrisa de securitate a lantului, evaluare a furnizorilor inainte de contractare, clauze contractuale privind securitatea, monitorizare continua [C3][C9]. In practica MSP-ul trebuie sa cascade aceste cerinte: orice sub-furnizor critic (ex. RMM-ul folosit pentru clienti, identity provider, vault de credentiale) trebuie sa fie el insusi sub un regim contractual aliniat cu NIS2.

Articolul 23 NIS2 stabileste etapele: early warning catre CSIRT-ul national (echipa DNSC) in maxim 24h de la constientizarea incidentului semnificativ, notificare detaliata in 72h, raport final in maxim o luna [C4]. Pentru MSP/MSSP exista o a doua dimensiune: clientii afectati de incident trebuie informati "fara intarziere nejustificata" pentru a permite raspunsul lor propriu (recitalul 86 + obligatii de notificare client-side derivate din contracte si Art. 21(2)(d)) [C6]. CISA si NCSC-UK au cerut printr-un advisory comun ca MSP-urile sa aiba clauze contractuale care identifica transparent responsabilitatile ICT intre MSP si client [C10]. Practic, un MSP trebuie sa aiba doua canale: unul catre DNSC, unul de notificare in cascada catre clienti.

Un MSP/MSSP care deserveste mai multi clienti dintr-un singur tenant gestionat central trebuie sa demonstreze izolarea operationala: separare a accesului privilegiat per client, logging segmentat per tenant, identitati distincte pentru operatorii MSP cand actioneaza pe sistemele clientilor, MFA obligatoriu pe orice acces inter-tenant [C10]. Reg. (UE) 2024/2690 Titlul 10 (control acces) si Titlul 7 (detectie / monitorizare / logging) cer politici de control acces si logging adecvate; in cazul unui MSP, aceasta inseamna jurnalizare per-client cu retentie suficienta pentru investigatii de tip "blast radius" [C3][C8]. Advisory-ul AA22-131A recomanda dezactivarea conturilor inactive si MFA obligatoriu pe conturile MSP cu acces la mediul clientilor, plus monitorizare a tentativelor de autentificare esuate [C10].

Cand un incident la MSP afecteaza simultan zeci sau sute de clienti (cazul tipic Kaseya, MOVEit, 3CX), planul de continuitate nu mai este o problema interna — devine raspuns coordonat pe N organizatii. Reg. (UE) 2024/2690 Titlurile 3 si 4 cer politica scrisa de tratarea incidentelor (Title 3) si politica de continuitate si gestiune a crizei (Title 4), cu testare periodica [C3][C8]. Pentru un MSP/MSSP asta inseamna: scenarii de tabletop care testeaza explicit cazul "build-ul nostru / RMM-ul nostru / portalul nostru a fost trojanizat", procedura de kill-switch pentru oprirea propagarii automate, plan de comunicare paralel catre toti clientii simultan. Lectiile din incidentele I1-I4 (SolarWinds, Kaseya, MOVEit, 3CX) arata ca firmele care nu au testat real scenariul "cascade" au reactionat cu zile sau saptamani de intarziere.

Tip: Atac pe lantul de aprovizionare software (Sunburst); atribuit APT29 / SVR (Rusia)

Impact: ~33.000 clienti Orion au primit comunicarea SolarWinds; ~18.000 au avut o instalare cu vulnerabilitate; un subset mult mai mic a fost compromis activ ulterior (agentii guvernamentale SUA, FireEye, Microsoft etc.). CISA a emis Emergency Directive 21-01 pe 13 dec 2020 obligand decuplarea sistemelor afectate.

Lecția: Build-ul software al furnizorului IT a fost vehicul pentru ~18.000 de instalari trojanizate distribuite ca update legitim. NIS2 Art. 21(2)(d) si (e), plus Reg. (UE) 2024/2690 Titlurile 5-6, cer politici de securitate a achizitiilor TIC si controale pentru integritatea ciclului de dezvoltare si livrare.

Tip: Ransomware REvil exploatand zero-day CVE-2021-30116

Impact: Aprox. 60 de MSP-uri compromise direct prin VSA on-premises; ~1.500 organizatii downstream criptate (clientii MSP); cerere de rascumparare initial 70 mil. USD, redusa apoi la 50 mil. USD. Atacul a coincis cu weekend-ul de 4 iulie.

Lecția: RMM-ul folosit zilnic de MSP-uri (Kaseya VSA) a devenit vector simultan pentru criptarea clientilor lor. Concluzie operationala: orice tool privilegiat utilizat transversal pe clienti are nevoie de pipeline de patching agresiv, izolare per-tenant si capacitate operationala de oprire instant a propagarii.

Tip: Exploit zero-day SQL injection CVE-2023-34362; web shell LEMURLOOT pentru exfiltrare

Impact: Pana la 19 iulie 2023: 383 organizatii si peste 20 milioane persoane afectate (Emsisoft). Cascade prin furnizori downstream: Zellis (payroll) -> British Airways, BBC, Boots. CISA si FBI au emis joint advisory AA23-158A.

Lecția: Un produs (MOVEit Transfer) folosit de un singur furnizor downstream (Zellis) a expus zeci de organizatii mari. NIS2 Art. 21(2)(d) si Reg. (UE) 2024/2690 Titlul 5 cer monitorizarea continua a furnizorilor critici si testarea scenariului in care furnizorul tau de tier-2 este vectorul atacului.

Tip: Atac dublu pe lant de aprovizionare; atribuit Lazarus (Coreea de Nord, UNC4736)

Impact: 3CX raporteaza ~600.000 clienti corporativi si ~12 milioane utilizatori in aerospatial, sanatate, ospitalitate, finante. Aplicatiile desktop (Win + macOS) au fost livrate cu cod malitios; backdoor secundar Gopuram livrat la tinte selectate (cripto). Compromiterea initiala a venit prin software-ul tert Trading Technologies — un atac "double-hop" pe lantul de aprovizionare.

Lecția: Furnizorul tau este compromis prin furnizorul lui. NIS2 Art. 21(2)(e) cere securitatea ciclului de achizitie + dezvoltare + intretinere, inclusiv pentru dependentele indirecte; CRA Reg. (UE) 2024/2847 introduce SBOM si raportarea vulnerabilitatilor active la produsele cu elemente digitale [C11].

Reg. (UE) 2024/2690 — cerinte tehnice si metodologice NIS2 pentru MSP, MSSP si infrastructura digitala · Direct aplicabil din 17 oct 2024; nu necesita transpunere nationala [C3]

Pentru MSP/MSSP, este textul de referinta pentru operationalizarea Art. 21(2) NIS2. Anexa cu 13 titluri (politica, risc, incidente, continuitate, lant de aprovizionare, achizitie ICT, detectie/monitorizare/logging, vulnerabilitati, igiena, control acces, HR, active, securitate fizica) este lista de control pe care DNSC o va folosi la verificari [C3][C8]. ENISA a publicat in 2025 un ghid tehnic de implementare cu exemple de evidenta si mapping pe ISO/IEC 27001 si ETSI EN 319401 [C2].

DORA — Reg. (UE) 2022/2554 · Direct aplicabil din 17 ian 2025 [C12]

Cand un MSP/MSSP semneaza contract cu o entitate financiara (banca, asigurator, casa de pensii, fintech), intra automat sub regimul Art. 28-30 DORA: clauze contractuale standardizate, registru ICT third-party la nivel de client (template Reg. (UE) 2024/2956), evaluare a concentrarii. Daca furnizorul este desemnat "critical ICT third-party provider" (CTPP) de ESAs (EBA + ESMA + EIOPA), intra sub oversight european direct [C12]. Lista CTPP-urilor desemnate este publicata anual de ESAs.

CRA — Reg. (UE) 2024/2847 (Cyber Resilience Act) · Intrare in vigoare 10 dec 2024; aplicabil integral 11 dec 2027; Art. 14 (raportare vulnerabilitati) din 11 sep 2026 [C11]

MSP/MSSP care dezvolta sau redistribuie produse cu elemente digitale (agenti EDR proprii, instrumente RMM customizate, integrari) intra sub CRA ca producator sau importator. Cerinta cheie: SBOM obligatoriu, raportarea vulnerabilitatilor active catre ENISA si CSIRT-ul national in 24h, gestiune a vulnerabilitatilor pe toata durata de viata a produsului [C11]. CRA se cumuleaza cu NIS2 — nu se substituie.

ISO/IEC 27001:2022 si ISO/IEC 27036 · Standarde voluntare; folosite drept baseline pentru demonstrarea conformitatii cu Reg. (UE) 2024/2690 [C2]

Reg. (UE) 2024/2690 cere ca masurile sa fie aliniate cu ISO/IEC 27001 si ISO/IEC 27002 [C2]. Pentru lantul de aprovizionare, ISO/IEC 27036 (Information security for supplier relationships) este standardul de referinta operationala. In practica DNSC, certificarea ISO/IEC 27001 reduce semnificativ efortul demonstrarii conformitatii, dar nu este per se suficienta — auditul DNSC se face pe textul Reg. (UE) 2024/2690.

CISA / NCSC-UK Joint Advisory AA22-131A — protejarea MSP · Document non-legal, dar referinta internationala (Five Eyes) [C10]

Advisory din 11 mai 2022 emis impreuna de CISA, FBI, NSA, NCSC-UK, ACSC (Australia), CCCS (Canada), NCSC-NZ. Recomandari concrete pentru MSP-uri si clientii lor: MFA obligatoriu pe orice cont MSP cu acces la mediul clientilor, dezactivarea conturilor neutilizate, clauze contractuale care identifica explicit responsabilitatile ICT [C10]. Este referinta operationala uzuala in audituri si contracte UE.