SEA Saulės elektrinių auditas
Straipsnis · Praktika

Kompensacinės priemonės: ką daryti su nepataisomomis spragomis

VERT 2026-04-30 nutarimas Nr. O3-470 leidžia palikti saugumo spragas neištaisytas, jei jų pašalinti neįmanoma — su sąlyga, kad įdiegtos dokumentuotos pagalbinės priemonės. Šiame straipsnyje — kokios konkrečios priemonės tinka tipiniams saulės elektrinių scenarijams.

Svarbi pastaba

VERT 2026-04-30 nutarimas Nr. O3-470 yra naujas teisės aktas. Šiuo metu dar nėra viešai paskelbtų ESO ar VERT išaiškinimų konkretiems audito atvejams.

Nuolat bendraujame su ESO ir VERT atstovais dėl scenarijų išaiškinimo ir stengiamės pateikti patikrintą informaciją. Vis dėlto šiame puslapyje pateikiami atsakymai atspindi mūsų dabartinę profesinę nuomonę ir gali keistis po VERT/ESO oficialių išaiškinimų. Konkrečiai jūsų objektui taikomi sprendimai gali skirtis — kviečiame pasitarti per pirminę konsultaciją.

Principas trumpai

Kompensacinės priemonės (angl. compensating controls) tarptautinėje saugumo praktikoje yra alternatyvūs apsaugos mechanizmai, taikomi kai pagrindinė kontrolė neįmanoma arba neefektyvi. PETA 191.7 ir 191.8.3 punktai eksplicitiškai leidžia šį kelią — su sąlyga, kad priemonės yra dokumentuotos ir periodiškai peržiūrimos.

Šiame straipsnyje pasitelkiame techninius terminus, kurie tarp IT specialistų yra įprasti — prie kiekvieno pirmą kartą paminėto pateikiame lietuvišką paaiškinimą skliausteliuose, kad turinys būtų aiškus tiek priežiūros teikėjui, tiek elektrinės savininkui.

Toliau — septyni dažni saulės elektrinių scenarijai ir konkrečios priemonės, kurios atitinka VERT reikalavimus.

Tipiniai scenarijai ir sprendimai

1. Inverteryje neištaisyta CVE

Gamintojas neišleidžia patch'o (naujinio) senesniam modeliui arba įrenginys yra EOL — end-of-life (eksploatacijos pabaiga).

Kompensacinės priemonės:

  • Atskirti pažeidžiamą įrenginį į dedikuotą VLAN (atskirą vidinį tinklo segmentą), be tiesioginės interneto prieigos
  • Visa komunikacija per VPN (šifruotą tunelinį ryšį) + jump host (tarpinį prieigos serverį) su MFA (dvigubu autentifikavimu)
  • Egress firewall whitelist (ugniasienės leidžiamų išeinančių adresų sąrašas) — tik gamintojo naujinių serveris + ESO/SCADA, blokuojami visi kiti tikslo IP
  • IDS (įsibrovimų aptikimo) taisyklės ant konkrečios CVE signature'os — atpažįstamo atakos pavyzdžio (pvz., Suricata / Snort įrankiai)
  • EOL replacement plan (eksploatacijos pabaigos pakeitimo planas) — dokumentuotas grafikas (12-24 mėn.), kada įranga bus pakeista

2. Numatytasis ar silpnas slaptažodis, kurio negalima keisti

Inverteryje arba kitame valdymo sistemos komponente yra hardcoded (į programą įsiūtas) slaptažodis arba ribota slaptažodžių politika.

Kompensacinės priemonės:

  • Įrenginys nepasiekiamas iš lauko — tik per bastion host (specialiai apsaugotą tarpinį serverį)
  • Bastion'e — MFA (dvigubas autentifikavimas) + per-vartotojo audit log (kiekvieno vartotojo veiksmų žurnalas)
  • MAC / IP whitelist'as (įrenginio adreso ir tinklo adreso leidžiamų sąrašas) ant management VLAN (valdymo tinklo segmento)
  • Slaptažodis nesinaudojama tiesiogiai — tik gamintojo support (techninės pagalbos) sesijoms su rašytiniu klientų patvirtinimu

3. Modbus TCP / Sunspec be šifravimo

Komunikacija su inverteriu vyksta plain text (atviru tekstu) protokolu — duomenis perimti įmanoma.

Kompensacinės priemonės:

  • TLS tunnel — stunnel arba VPN (šifruotas saugus ryšys) tarp inverterio ir SCADA
  • Atskira management VLAN (valdymo tinklo segmentas) be wireless (bevielio) prieigos
  • Switch port security (komutatoriaus prievado apsauga) — sticky MAC (užfiksuotas įrenginio adresas), kad niekas neprijungtų savo įrangos į valdymo tinklo prievadą
  • Periodinis tcpdump / NetFlow tikrinimas (tinklo srauto įrašymas), kad srautas tik leistinuose tinkluose

4. Nepalaikoma 2FA prie web sąsajos

Valdymo sistemos web UI (interneto sąsaja) neturi 2FA — two-factor authentication (dviejų faktorių autentifikavimo), nors PETA 192.4 to reikalauja.

Kompensacinės priemonės:

  • Web UI nepasiekiamas iš interneto — firewall block 0.0.0.0/0 (ugniasienė blokuoja visą įeinančią prieigą)
  • Prieiga tik per VPN, kuris pats reikalauja 2FA
  • Reguliariai keisti vidinį slaptažodį (pvz., kas 90 d.)
  • Logging (žurnalavimas) ant kiekvieno login (prisijungimo) mėginimo — su alarm'u (pranešimu) nesėkmių serijai

5. Ribotas logging arba nėra audit trail

Įrenginys nepalaiko žurnalų eksporto arba juos saugo trumpą laikotarpį, nors PETA 191.8.1 reikalauja įrašų peržiūros nuo paskutinio audito. Logging = veiksmų žurnalavimas, audit trail = atsekamasis veiksmų pėdsakas.

Kompensacinės priemonės:

  • Syslog (sisteminių pranešimų protokolas) siunčiamas į išorinį server'į, kad pats įrenginys nepamestų įrašų
  • NetFlow / IPFIX (tinklo srauto įrašymo standartai) ant management switch (valdymo komutatoriaus) — kas su kuo bendrauja
  • Bastion host'o session recording (tarpinio serverio sesijų įrašymas — pvz., auditd, pam_tty_audit įrankiai)
  • Kasmėnesinis log review (žurnalų peržiūra) su sign-off (atsakingo asmens parašu)

6. Tiekėjas iš grėsmės šalies — reikalinga nuotolinė priežiūra

Pagal PETA 192/193 grėsmės šalies tiekėjas (pvz., Huawei iš Kinijos) reikalauja nuotolinės priežiūros, bet nuolatinė prieiga prieštarautų reikalavimams.

Kompensacinės priemonės:

  • Nuotolinis valdymas išjungtas iš gamintojo pusės — atidaromas tik on-demand (pagal poreikį, ticket-based — pagal kliento prašymą)
  • Sesija atidaroma rankiniu būdu kliento personalo, ribota laike (max 4 val.)
  • Sesija įrašoma — jump host recording (tarpinio serverio sesijos įrašas)
  • Po sesijos credentials rotated (slaptažodžiai pakeičiami), network rule expires (tinklo taisyklė nustoja galioti)
  • Visa veikla logged (užžurnaluota) ir periodiškai audituojama

7. Senas firmware, paskutinis update prieš 3+ metus

Gamintojas nebepalaiko įrangos, naujų patch'ų (naujinių) niekada nebus. Firmware = įrenginio vidinė programinė įranga.

Kompensacinės priemonės:

  • Dokumentuotas EOL replacement plan (eksploatacijos pabaigos pakeitimo planas — 12-24 mėn.), su biudžetu ir terminais
  • Tarp kol kas — visi aukščiau išvardyti tinklo lygmens sprendimai (VLAN, jump host, monitoringas)
  • Kasmėnesinis CVE feed monitoring (pažeidžiamumų stebėjimas) konkrečiam modeliui — NIST NVD ar gamintojo bulletin'ai (pranešimai)
  • Prieš grafiką — testuoti pakaitinę įrangą integracinėje aplinkoje
Svarbu — kada kompensacinės priemonės nepakanka: PETA 191.10 reikalauja, kad sąsają su internetu turinčių valdymo sistemos įrenginių kritinio ir aukšto lygio kibernetinio saugumo spragos (CVSS ≥ 7,0) būtų pašalintos per 5 kalendorines dienas nuo naujinio paskelbimo. Šiame lange kompensacinės priemonės nepriimamos kaip nuolatinis sprendimas — turi būti realus patch'as (naujinys), izoliacija nuo interneto arba įrenginio išjungimas. Tik po šio žingsnio galima grįžti prie tvarios kompensacinių priemonių strategijos.

Ko negalima rašyti kaip kompensacinę priemonę

  • Sutartis su gamintoju — popierinis dokumentas savaime nesumažina techninės rizikos.
  • Saugomas slaptažodis seife — jei jis vis tiek galioja prieigos lygmenyje, spraga lieka.
  • Tik vaizdo stebėjimas — kompensuoja tik fizinį incidentą po fakto, ne techninę spragą.
  • Vartotojų apmokymas vienas pats — turi būti kartu su technine kontrole.
  • Antivirusas inverteriui be IDS / network controls (įsibrovimų aptikimo / tinklo apsaugos) — saugumo „dažai" be pagrindinės struktūros.

Ką privalo turėti audito ataskaita

Kad kompensacinės priemonės būtų priimtos pagal PETA 191.7, audito ataskaitoje (ar prie jos pridedamame priedėlyje) turi būti aiškiai pateikta:

Privaloma ataskaitos struktūra kiekvienai spragai

  1. Spragos identifikacija — CVE numeris arba aiškus aprašymas, CVSS score (pavojingumo įvertinimas)
  2. Pagrindimas, kodėl nepataisoma — gamintojo dokumentas, EOL statement (eksploatacijos pabaigos pareiškimas), patch nesuderinamumas
  3. Kompensacinių priemonių sąrašas — tikslūs, įgyvendinti, ne planuojami
  4. Liekamosios rizikos vertinimas — po priemonių įdiegimo: low / medium / high (žemas / vidutinis / aukštas)
  5. Periodinės peržiūros planas — kas, kada vertina, ar priemonės dar veikia
  6. EOL / replacement roadmap (eksploatacijos pabaigos / pakeitimo planas) — jei taikoma, kada įranga bus pakeista

Kaip pasiruošti auditui

Jei jau matote, kad jūsų objekte yra spragų, kurių pašalinti negalima dėl gamintojo politikos ar EOL (eksploatacijos pabaigos) statuso, naudinga prieš auditą:

  • Surinkti gamintojų atsakymus apie patch'ų (naujinių) prieinamumą — el. pašto perrašyti su datomis
  • Dokumentuoti esamą tinklo architektūrą su VLAN'ais (vidiniais tinklo segmentais) ir ugniasienės taisyklėmis
  • Identifikuoti, kuriuos įrenginius pakeisti planuojama per artimiausius 12-24 mėn.
  • Užfiksuoti, kas atsako už periodinę kompensacinių priemonių peržiūrą

Šie dokumentai yra pagrindas auditoriui formuluoti tinkamą atsakymą deklaracijos kontekste, ir mažina audito trukmę bei nereikalingą iteraciją.

Susiję puslapiai