Galvenie secinājumi:
Tekstā kritizētas šķietami korektas kiberriska analīzes, kas nepārvēršas inženiertehniskos lēmumos un produkta uzturēšanā. Tas parāda paradigmas maiņu uz riska balstītu pieeju reālā lietojuma kontekstā un visā dzīves ciklā.
- Tipisks “kiberriska novērtējums” mēdz būt tabula ar low/medium/high: atbilst atbilstības prasībām, taču neietekmē ne produkta arhitektūru, ne atbalstu.
- ES pieeja (CRA, MDR, Mašīnu regula 2023/1230) pārbīda jautājumu uz lietošanas nosacījumiem un riska kontroli visā dzīves ciklā.
- Produkta riska novērtējums nav IT analīze, pentests vai ISO 27001 ieviešana; tas attiecas uz produkta un ražotāja spēju ilgtermiņā uzturēt drošību.
- Ievainojamība (piem., CVE) ir tehniska kļūda; produkta risks izriet no lietošanas konteksta, integrācijas, lietotāju rīcības, ielāpu pārvaldības un reaģēšanas uz incidentiem.
- Nepareizi izvēlēti drošības pasākumi var palielināt risku: MFA OT vidē, automātiskie atjauninājumi IoMT un saskarņu bloķēšana IoT rada jaunus uzbrukuma vektorus un blakusefektus.
Lielākajā daļā tehnoloģiju uzņēmumu process, kas pazīstams kā kiberriska novērtējums, jau pastāv. Parasti tas izpaužas kā apjomīga tabula, sarežģīta matrica vai izklājlapa, kur dominē vērtības “low”, “medium” un “high”. Šajā dokumentā ir garš vispārīgu apdraudējumu saraksts, īsi potenciālo ievainojamību apraksti un standarta kontroles pasākumu kopums. No formālā skatpunkta viss ir kārtībā: dokuments ir pilnīgs, vadības parakstīts un droši arhivēts.
Problēma ir tā, ka inženieru praksē šis dokuments nemaina pilnīgi neko.
Tas neietekmē projektējamās ierīces arhitektūru. Tas nenosaka lēmumus par atjauninājumu piegādes veidu. Tas nemaina pēcpārdošanas atbalsta modeli un nepārskata attiecības ar komponentu piegādātājiem. Tas ir dokuments, kas ir korekts no compliance viedokļa, bet pilnīgi vienaldzīgs reālajai produktu kiberdrošībai. Tomēr tā nav inženieru vai drošības komandu kompetences trūkuma vaina. Tā ir fundamentāli kļūdaina sākumpunkta problēma.
Lielākā daļa tradicionālo riska analīžu sākas ar jautājumu: “Kādi apdraudējumi var rasties?”. Tikmēr jaunā Eiropas Savienības regulatīvā pieeja – skaidri redzama tādos aktos kā Cyber Resilience Act (CRA), medicīnas direktīvās (MDR) vai jaunajā mašīnu regulā 2023/1230 – uzspiež pavisam citu skatījumu. Tas sākas ar jautājumu:
Kādos lietošanas apstākļos produkts var kļūt par riska nesēju lietotājam, sistēmai vai tirgum – un vai ražotājs spēj šo risku kontrolēt visā tā dzīves ciklā?
Tā ir fundamentāla paradigmas maiņa. Kiberriska novērtējums produkta kontekstā nav vienkārši kārtējā IT infrastruktūras apdraudējumu analīze. Tas nav arī penetrācijas tests vai mehāniska ISO 27001 vadlīniju ieviešana. Tā ir padziļināta analīze par paša produkta un tā ražotāja spēju laika gaitā uzturēt drošību reālā ekspluatācijas vidē.
Tehniskā ievainojamība un produkta risks – nošķīrums kiberdrošībā
Lai riska novērtējums vairs nebūtu tikai birokrātiska tabula, bet kļūtu par inženiertehnisku lēmumu pieņemšanas rīku, mums precīzi jānodala divi jēdzieni, kurus tirgū nereti sistemātiski jauc. Atcerēsimies: ievainojamība nav tas pats, kas produkta risks.
- Tehniskā ievainojamība ir konkrēta, identificējama kļūda programmatūrā, aparatūras konfigurācijā vai pašā projektā. Tā var būt nepareiza datu validācija, novecojusi programmēšanas bibliotēka vai nepilnība autentifikācijas mehānismā. Šādas kļūdas tiek reģistrētas tādās datubāzēs kā CVE sistēma (Common Vulnerabilities and Exposures). Tomēr tas joprojām ir vērtējums tikai tehniskā līmenī.
- Produkta risks parādās tikai tad, kad minētā ievainojamība (vai pat tās īslaicīgs trūkums) tiek ielikta skarbajā lietošanas realitātē.
Šis konteksts ietver virkni mainīgo: darba vidi (atvērts vai izolēts tīkls), integrācijas veidu ar citām sistēmām, lietotāju uzvedību, drošības atjauninājumu pieejamību (t. s. patch management) un ražotāja organizatorisko spēju reaģēt uz incidentiem.
Produktam izlaišanas dienā var nebūt nevienas zināmas ievainojamības, un tomēr tas var radīt kritisku risku, ja tā izstrādātājam nav ilgtermiņa atbalsta procesu. Šīs atšķirības izpratne sakārto visu inženierdarbu. Tieši uz to balstās uz risku balstīta pieeja (risk-based approach). Drošības pasākumiem jābūt samērīgiem ar paredzamajiem ļaunprātīgas izmantošanas scenārijiem, nevis ar abstraktu sarakstu no interneta.
Aizsardzības paradokss: kad aizsardzība palielina risku IT un OT vidē
Kiberdrošības projektēšanā bieži pieņem, ka jaunas “slēdzenes” pievienošana vienmēr samazina risku. Prakse rāda, ka mēdz būt tieši pretēji. Pasākums, kas ieviests bez konteksta izpratnes, rada jaunus apdraudējumu vektorus.
1. Spēcīga autentifikācija industriālajā vidē (OT)
Iedomāsimies daudzfaktoru autentifikācijas (MFA) ieviešanu industriālai iekārtai. No IT skatpunkta tas ir paraugsolis, taču kiberdrošība industriālajā automatizācijā ir pavisam cita realitāte. Rūpnīcas vidē iekārta strādā 24/7, un servisa iejaukšanās notiek laika spiedienā. Kad tīkls pieviļ, tehniķis nevar tiešsaistē autorizēt tokenu. Ražošana apstājas. Rezultāts? Neapmierināts klients šo mehānismu pastāvīgi atslēdz, pilnībā apejot aizsardzību. Pasākums, kam bija jāaizsargā, radīja milzīgu operacionālo risku.
2. Automātiskie atjauninājumi medicīnas ierīcēs (IoMT)
Ātra ievainojamību ielāpošana samazina pakļautību uzbrukumiem — IT pasaulē tā ir norma. Taču medicīnisko ierīču pasaulē piespiedu atjauninājums procedūras laikā var mainīt sistēmas uzvedību vai pārraut saziņu ar slimnīcas tīklu. Šādā gadījumā tehnoloģiska aizsardzība rada kritisku klīnisko un regulatīvo risku (MDR sertifikācijas pārkāpums).
3. Interfeisu slēgšana patēriņa ierīcēs (IoT)
Ražotājs fiziski noņem lokālos diagnostikas portus no viedās mājas ierīces, lai apgrūtinātu hakeriem piekļuvi. Praksē autorizētie servisi sāk diagnosticēt defektus caur nestabiliem interfeisiem, apejot šifrēšanu, bet pieredzējuši lietotāji masveidā instalē modificētu programmatūru (custom firmware). Rezultāts — ražotājs pilnībā zaudē kontroli pār savu ekosistēmu.
Patiesa kiberriska analīze jautā: „Kā mainīsies visa ekosistēmas stabilitāte, lietojamība un drošums, ieviešot tieši šo konkrēto mehānismu?”.
5 biežākās kļūdas tehnoloģisko produktu riska analīzē
Vērtējot procesus uzņēmumos, kas tirgū laiž elektroniku un programmatūru, kiberdrošības eksperti redz atkārtojošos modeļus.
- Korporatīvā IT modeļa kopēšana produktu pasaulē. Produkts nav serveru telpa. Tas darbojas nezināmā vidē, bieži bezsaistē, un to konfigurē neprofesionāli lietotāji. IT rīku piemērošana produkta analīzei beidzas ar būtisku problēmu ignorēšanu: ierīces dzīves ciklu un piespiedu atjauninājumu neesamību.
- Abstraktu apdraudējumu analīze reālu scenāriju vietā. Tabulā ierakstīt frāzes kā “neautorizēta piekļuve” analītiski ir bezjēdzīgi. Analīzei jābalstās konkrētībā: Kas? Caur kuru interfeisu? Kādēļ? Ar kādām sekām?
- Produkta dzīves cikla (End-of-Life) ignorēšana. Riska analīze parasti attiecas uz palaišanas brīdi. Tikmēr risks ar laiku pieaug — atvērtā koda bibliotēkas noveco, un komponentu piegādātāji pārtrauc atbalstu. Neņemot vērā uzturēšanas modeli, analīze ir maldinoša.
- Atrautība no izstrādes komandas (R&D). Riska novērtējuma uztveršana kā kontrolsaraksta pirms audita ir tiešs ceļš uz katastrofu. Rezultātiem jāatgriežas pie inženieriem kā stingrām arhitektūras prasībām (Secure by Design).
- Tehnoloģiju fetišizēšana uz procedūru rēķina. Uzņēmumi iegulda milzu līdzekļus modernā kriptogrāfijā, bet nezina, kurš uzņēmumā atbild par drošības labojuma (patch) izlaišanu pēc tam, kad pētnieks ziņo par ievainojamību (Vulnerability Disclosure Program).
Kā veikt analīzi atbilstoši Cyber Resilience Act? 7 inženiertehniski soļi
Kiberriska novērtējumam jāpārstāj būt birokrātiskam slogam. Zemāk ir tirgū pārbaudīts, ES pieejai atbilstošs (t. sk. CRA prasībām) operacionālais modelis.
- Definē produkta robežas. Produkts nav tikai aparatūra. Tā ir arī mobilā lietotne, mākonis, OTA serveri un API interfeisi.
- Apraksti skarbo lietošanas vides realitāti. Neapraksti laboratorijas vidi. Atbildi uz jautājumiem par faktisko interneta savienojamību, lietotāju kompetenci un fiziskas piekļuves iespējām ierīcei.
- Identificē ļaunprātīgas izmantošanas scenārijus (Threat Modeling). Atsakies no vispārīgām listēm. Izmanto pārbaudītas, inženiertehniskas riska novērtēšanas metodes un rīkus, lai koncentrētos uz precīziem uzbrukuma vektoriem, kas pielāgoti tavai nozarei.
- Kvantificē nefinansiālās sekas. Novērtē ražošanas dīkstāves risku, apdraudējumu veselībai vai regulatīvo pienākumu pārkāpumu.
- Uzdod jautājumu par kontroli. Vai tu kā ražotājs spēj novērst, atklāt un ātri reaģēt uz identificēto ļaunprātīgas izmantošanas scenāriju?
- Izstrādā samērīgus aizsardzības mehānismus. Lēmumiem par šifrēšanu vai tīkla segmentēšanu ir tieši jāizriet no atbildēm, kas sniegtas iepriekšējos soļos.
- Izstrādā uzturēšanas procesu (Lifecycle). Dokumentē drošības ielāpu piegādes politiku, atbalsta periodu un saziņas kanālus ar klientu.
Kopsavilkums: kam jāpaliek pēc rūpīga riska novērtējuma?
Pareizas produkta kiberdrošības riska novērtēšanas rezultātam nekad nevajadzētu būt ar tekstu pārsātinātam “poēmas” tipa dokumentam auditoram. No šī darba jāizriet taustāmi artefakti: skaidra sistēmas robežu karte, stingri arhitektūras lēmumi R&D, apstiprināts budžets atjauninājumu politikai un konsekventa audita pēda, kas pierāda atbilstību ES direktīvām.
Tehnoloģiski nobriedusi organizācija vairs nejautā: „Vai mēs esam 100% droši?”. Tā vietā tā jautā: „Kur tieši mēs esam pakļauti riskam un vai spējam to pārvaldīt laika gaitā?”.
Vai tavs produkts ir gatavs jaunajām regulām?
Drošība ir process, nevis vienreizējs sertifikāts. Ja nevēlies, lai riska novērtēšana tavā uzņēmumā būtu tikai „papīru kārtošana”, ir vērts rīkoties proaktīvi. Skaties, kā praktiski sagatavot produktu Cyber Resilience Act (CRA) 2026.–2027. gadam, pirms parādās oficiālie saskaņotie standarti.
Produktu kiberriska novērtējums: kāpēc lielākā daļa drošības analīžu šķietami ir pareizas, bet praksē ir nelietderīgas?
Jo tas parasti atbilst atbilstības prasībām, bet neietekmē inženiertehniskos lēmumus: arhitektūru, atjauninājumus, pēcpārdošanas atbalstu vai attiecības ar piegādātājiem. Rezultātā tas formāli ir korekts, bet praktiski — vienaldzīgs.
Nevis no abstraktu apdraudējumu saraksta, bet gan no lietošanas apstākļiem, kuros produkts var kļūt par riska avotu, un no tā, vai ražotājs spēj šo risku kontrolēt visā dzīves ciklā. Šī pieeja ir saskaņota ar regulatīvo skatījumu, kas redzams cita starpā CRA, MDR un Mašīnu regulā 2023/1230.
Tehniska ievainojamība ir konkrēta kļūda programmatūrā, konfigurācijā vai projektējumā (piemēram, nepilnība autentifikācijā), un to var reģistrēt, piemēram, kā CVE. Produkta risks parādās tikai reālās lietošanas kontekstā, ņemot vērā integrāciju, lietotāju rīcību, atjauninājumu pieejamību un ražotāja spēju reaģēt.
Nē — nepareizi izvēlēts mehānisms var palielināt risku, jo tas rada jaunus operatīvo problēmu vektorus. Tekstā minētie piemēri rāda, ka MFA OT vidē, automātiskie atjauninājumi IoMT vai saskarņu „slēgšana” IoT var novest pie drošības pasākumu apiešanas vai pie operacionālajiem un regulatīvajiem riskiem.
Tas cita starpā ietver korporatīvā IT modeļa kopēšanu produktu pasaulē, paļaušanos uz vispārīgiem apgalvojumiem scenāriju vietā („kas, kā, kāpēc un ar kādu rezultātu”), kā arī dzīves cikla un End-of-Life posma problēmu ignorēšanu. Rezultāts ir analīze, kas nenorāda ne uz reāliem projektēšanas lēmumiem, ne uz uzturēšanas pasākumiem.