Jautājumā tiek jautāts par mūsu programmatūras atjauninājumu plasteri politiku

Patch politika ietilpst vulnerabilitāšu pārvaldībā, nevis incidentu reagēšanā

Jautājums par patch politiku pieder pie procesu, lai identificētu un novērstu ievainojamības, nevis pie incidentu reagēšanas. Klienti vēlas zināt, vai atjauninājumi tiek ieviesti sistēmiski un laicīgi, ar atšķirību starp kritiskajiem patch-iem (bieži vien pāris dienu laikā) un parastajiem atjauninājumiem (bieži vien fiksēta nedēļu cikla ietvaros). Atbilde, kas tikai saka "mēs regulāri atjauninājam", ir pārāk neskaidra; parasti tiek prasīts konkrēts laika limits katrai riska klasei un informācija par to, kurš ir atbildīgs par ieviešanu un kontroli.

Ja tev nav noteikti termiņi, tad "nē" ir godīga atbilde, pat ja praktiski patchi ātri. Procedūra, kas eksistē tikai kāda cilvēka galvā, nav politika, kuru vari pierādīt. Bieži vien tajā pašā sarakstā tiek vaicāts arī par to, vai šī patch politika ir daļa no plašāka riska analīzes procesa — ja tam jau pastāv noteikta politika, vari patch politiku tur iekļaut kā daļu, nevis to dokumentēt atsevišķi. Pievērsi uzmanību arī jautājuma darbības jomai: vai tas attiecas uz tavu pašu infrastruktūru, uz produktiem, kurus piegādā tu, vai uz abiem. Tas nosaka, vai tavs pierādījums ir iekšējais politikas dokuments vai izlaides piezīme uz klientiem.

Izsekojams uz Direktīvas 21. panta 2. punktu NIS2

Vulnerabilitāšu pārvaldība un tā novēršana (handling un disclosure) ir minēta kā atsevišķs pasākums Direktīvas (ES) 2022/2555 21. panta 2. punktā, līdzās pamata kiberdrošības praksei. Patch politika ir šī pasākuma operacionālā īstenošana. ISO/IEC 27001 standartā tas atgriežas Pielikumē A, starp kontroles pasākumiem tehniskajai vulnerabilitāšu pārvaldībai, kur patch-u laika jautājums ir skaidri minēts kā kontrole. Saskaņā ar Kiberdrošības likumu, Nīderlandes NIS2 transponēšanu, šī prasība stājas spēkā no 2026. gada 15. augusta to subjektu gadījumā, uz kuriem likums attiecas.