Razdoblja sigurnosne podrške prema EU CRA uz ISO 27001

U utorak je 08:20 i vlasnik proizvoda za povezani B2B pristupnik prima poruku od reguliranog klijenta: “Molimo potvrdite razdoblje sigurnosne podrške za verziju firmvera 4.6, SLA za odgovor na ranjivosti i hoće li uređaj ostati obuhvaćen sigurnosnim ažuriranjima tijekom našeg petogodišnjeg ugovora o usluzi.”

Do 09:00 nabava je proslijedila upitnik za dubinsku analizu dobavljača prema DORA-i. Do 10:15 pravna služba pita je li objavljeno razdoblje podrške usklađeno s ugovorima s klijentima. Do 11:00 CISO je uključen u NIS2 pregled rizika dobavljača jer proizvod u EU koristi pružatelj upravljanih usluga. Nakon ručka tim za privatnost pita može li nepodržana API biblioteka u proizvodu utjecati na sigurnost osobnih podataka prema GDPR-u.

Neugodna se istina brzo pokaže. Organizacija ima plan razvoja, postupak zakrpavanja, kalendar izdanja i portal korisničke podrške, ali nema uređene dokaze o razdoblju sigurnosne podrške.

Ta je praznina važna. Prema Aktu EU-a o kibernetičkoj otpornosti, razdoblje sigurnosne podrške nije samo oznaka proizvoda. To je obveza kroz životni ciklus koja utječe na obradu ranjivosti, dostupnost ažuriranja, upravljanje ovisnostima o dobavljačima, komunikaciju s klijentima, ugovorna jamstva i posttržišni nadzor. Za SaaS dobavljače, proizvođače uređaja, izdavače softvera, dobavljače usluga u oblaku i pružatelje IKT usluga, razdoblje podrške postaje predmet usklađenosti koji će revizori i regulirani kupci provjeravati.

Praktičan odgovor nije još jedna nepovezana tablica za usklađenost. Odgovor je upravljati razdobljem sigurnosne podrške unutar sustava upravljanja informacijskom sigurnošću ISO/IEC 27001:2022, a zatim iste dokaze mapirati na NIS2, DORA, GDPR, NIST CSF 2.0 i revizijska očekivanja u stilu COBIT-a.

To je Clarysec operativni model: koristiti ISMS kao mehanizam za dokaze, koristiti provedive politike za definiranje odgovornosti, koristiti Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint za izgradnju sljedivosti i koristiti Zenith Controls: The Cross-Compliance Guide Zenith Controls kao kompas za mapiranje usklađenosti među okvirima.

Zašto je razdoblje sigurnosne podrške sada predmet revizije

Razdoblje sigurnosne podrške odgovara na jednostavno pitanje: koliko dugo će proizvođač pružati sigurnosna ažuriranja, otklanjanje ranjivosti, smjernice za ublažavanje i povezanu korisničku podršku za proizvod ili verziju proizvoda?

U praksi taj odgovor ovisi o mnogim povezanim elementima:

• arhitekturi proizvoda i mogućnosti održavanja
• podršci za komponente trećih strana i ovisnosti otvorenog koda
• obvezama dobavljača i pružatelja usluga u oblaku
• procesima zaprimanja, trijaže, otklanjanja i objave ranjivosti
• kapacitetu za inženjering izdanja i testiranje
• ugovornim uvjetima s klijentima i regulatornim obvezama
• putovima za odgovor na incidente i obavješćivanje primatelja usluge
• zadržavanju dokaza i zapisima odobrenja

Ako proizvođač obeća pet godina sigurnosne podrške, a kritična kriptografska biblioteka nakon tri godine dosegne status bez podrške, razdoblje podrške postaje odluka o riziku. Ako je klijent financijski subjekt obuhvaćen DORA-om, isto razdoblje podrške postaje dio provjere IKT trećih strana. Ako proizvod obrađuje osobne podatke, nepodržani softver može postati dio odgovornosti za sigurnost obrade prema GDPR-u. Ako proizvod podržava ključni ili važni subjekt prema NIS2, sigurnost životnog ciklusa postaje pitanje sigurnosti opskrbnog lanca.

NIS2 taj upravljački aspekt izričito naglašava. Article 20 zahtijeva da upravljačka tijela ključnih i važnih subjekata odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i pohađaju osposobljavanje. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu, siguran razvoj i održavanje, obradu i objavu ranjivosti, procjenu djelotvornosti, kibernetičku higijenu, kriptografiju, kontrolu pristupa, upravljanje imovinom i autentifikaciju. Article 23 dodaje fazne obveze izvješćivanja o značajnim incidentima.

DORA stvara sličan pritisak za financijske subjekte. Zahtijeva upravljanje IKT rizicima, program testiranja digitalne operativne otpornosti, upravljanje incidentima i upravljanje rizicima IKT trećih strana. DORA Article 28 obuhvaća načela upravljanja rizicima IKT trećih strana, a Article 30 zahtijeva pisane ugovorne aranžmane s jasnim opisima usluga, sigurnosnim mjerama, pomoći pri incidentima, pravima na reviziju, pravima raskida i izlaznim aranžmanima.

GDPR dodaje sloj privatnosti. Ako proizvod obrađuje osobne podatke, voditelji obrade i izvršitelji obrade trebaju odgovarajuće tehničke i organizacijske mjere prema Article 32, ugovornu jasnoću prema Article 28 te spremnost za procjenu povrede i obavješćivanje prema Articles 33 i 34.

Zato se razdobljem sigurnosne podrške prema CRA mora upravljati kao obitelji kontrola unutar ISMS-a, a ne kao izoliranim poljem upravljanja proizvodom.

ISO 27001 kao okosnica kontrola za razdoblja sigurnosne podrške prema CRA

ISO/IEC 27001:2022 vrijedan je jer je skalabilan, temeljen na riziku i usmjeren na sustav upravljanja. Zahtijeva da organizacija definira kontekst, zainteresirane strane, opseg i povezane procese, a zatim pravne, regulatorne i ugovorne zahtjeve prevede u procjenu rizika, obradu rizika, operativne kontrole i dokaze ISO/IEC 27001:2022.

Za upravljanje razdobljem sigurnosne podrške to znači da organizacija mora:

1. Identificirati proizvode, verzije, module, usluge u oblaku i ovisnosti u opsegu.
2. Identificirati zainteresirane strane, uključujući klijente, regulatore, distributere, uvoznike, integratore, izvršitelje obrade, podizvršitelje obrade, partnere za odgovor na incidente i dobavljače.
3. Evidentirati pravne, regulatorne i ugovorne obveze podrške.
4. Procijeniti rizike koji bi mogli spriječiti ispunjenje obveza podrške.
5. Odabrati kontrole za upravljanje ranjivostima, siguran razvoj, provjeru sigurnosti dobavljača, upravljanje incidentima, neprekidnost poslovanja, privatnost i dokumentirane informacije.
6. Izraditi napomene u Izjavi o primjenjivosti koje objašnjavaju zašto se kontrole primjenjuju.
7. Pregledati razdoblje podrške kada se promijene arhitektura, ovisnosti o dobavljačima, izloženost prijetnjama ili obveze prema klijentima.

Zenith Controls identificira tri tematski povezana kontrolna uporišta ISO/IEC 27002:2022 kao središnja za ovaj upravljački problem: 5.31 pravni, zakonski, regulatorni i ugovorni zahtjevi, 8.8 upravljanje tehničkim ranjivostima i 8.25 sigurni životni ciklus razvoja softvera. To nisu jedine uključene kontrole, ali čine upravljačku okosnicu.

Ključ je sljedivost. Razdoblje podrške proizvoda mora biti sljedivo od obveze do scenarija rizika, od scenarija rizika do odabranih kontrola, od kontrola do zahtjeva politike i od zahtjeva politike do dokaza.

Zenith Blueprint, faza upravljanja rizicima, Korak 13, izravno opisuje tu disciplinu sljedivosti:

“Unakrsno povežite propise: Ako su određene kontrole implementirane posebno radi usklađenosti s GDPR, NIS2 ili DORA, to možete navesti u Registru rizika (kao dio obrazloženja utjecaja rizika) ili u napomenama SoA.”

Izvor: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza upravljanja rizicima, Korak 13: planiranje obrade rizika i Izjava o primjenjivosti Zenith Blueprint

Za razdoblje sigurnosne podrške prema CRA, Izjava o primjenjivosti ne smije samo navesti da se “primjenjuje upravljanje ranjivostima”. Treba objasniti da se upravljanje ranjivostima primjenjuje zato što organizacija ima obveze životnog ciklusa prema CRA, očekivanja NIS2 u vezi sa sigurnim razvojem i opskrbnim lancem, zahtjeve klijenata za dubinsku analizu dobavljača prema DORA-i, sigurnosne obveze prema GDPR-u kada se obrađuju osobni podaci i ugovorna obećanja podrške.

Od obećanja podrške do uređenog životnog ciklusa

Razdoblje sigurnosne podrške koje definira proizvođač treba proći šest upravljačkih provjera.

Prvo, mora biti definirano. Organizaciji je potrebna standardna taksonomija, kao što su aktivna podrška, podrška samo za sigurnosne potrebe, produljena podrška, ograničena podrška i bez podrške. Svaki status treba objasniti dostupnost ažuriranja, obradu ranjivosti, komunikaciju s klijentima i putove eskalacije.

Drugo, mora biti procijenjeno s aspekta rizika. Pet godina podrške za SaaS proizvod kojim se upravlja iz oblaka i koji ima kontrolirane kanale ažuriranja razlikuje se od pet godina podrške za ugrađeni uređaj s terenskim ograničenjima, ovisnostima o čipovima trećih strana i terminima uvođenja kojima upravljaju klijenti.

Treće, mora biti odobreno. Proizvod, sigurnost, pravna služba, privatnost, korisnička podrška i odgovorno rukovodstvo trebaju odobriti polazno razdoblje i iznimke.

Četvrto, mora biti komunicirano. Klijenti trebaju razumjeti datum početka podrške, datum završetka, način ažuriranja, kanal za prijavu ranjivosti, očekivanja u pogledu otklanjanja, posljedice kraja podrške i dostupne mogućnosti produljenja.

Peto, mora biti praćeno. Ovisnosti se mijenjaju. Dobavljači obustavljaju biblioteke. Ranjivosti se pojavljuju. Okruženja klijenata se mijenjaju. Upravljanje razdobljem podrške mora uključivati praćenje životnog ciklusa komponenti, pregled dobavljača, izvore informacija o ranjivostima, zapisnike zakrpa, testiranje izdanja i naučene lekcije iz incidenata.

Šesto, mora biti dokazivo. Ako revizor, regulator ili regulirani klijent zatraži dokaz, organizacija mora pokazati registar usklađenosti, registar podrške proizvoda, procjenu rizika, mapiranje Izjave o primjenjivosti, registar ranjivosti, zapise o zakrpama, preglede dobavljača, odobrenja izdanja i obavijesti klijentima.

Clarysec politike čine to praktičnim. Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy zahtijeva:

“Sve pravne i regulatorne obveze moraju biti mapirane na konkretne politike, kontrole i vlasnike unutar sustava upravljanja informacijskom sigurnošću (ISMS).”

Izvor: Legal and Regulatory Compliance Policy, zahtjevi za provedbu politike, točka 6.2.1 Legal and Regulatory Compliance Policy

Za MSP-ove, ekvivalentna disciplina počinje jednostavnijim registrom. SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy - SME navodi:

“GM mora održavati jednostavan, strukturiran Registar usklađenosti koji navodi:”

Izvor: Legal and Regulatory Compliance Policy-sme, zahtjevi upravljanja, točka 5.1.1 Legal and Regulatory Compliance Policy - SME

Obveza razdoblja podrške mora biti u registru usklađenosti ako proizlazi iz zakona, ugovora s klijentom, sektorske regulative ili očekivanja reguliranog kupca. Ne smije postojati samo u napomenama o izdanju ili marketinškom tekstu.

Izradite registar razdoblja sigurnosne podrške prema CRA u jednoj radionici

Zamislite SaaS dobavljača koji pružateljima logističkih usluga u EU i klijentima iz financijskog sektora prodaje povezani analitički uređaj. Proizvod uključuje ugrađeni agent, API u oblaku, mobilnu administratorsku aplikaciju i nekoliko biblioteka otvorenog koda. Prodaja želi obećati pet godina sigurnosne podrške za svaku veću verziju uređaja.

CISO može provesti usmjerenu radionicu s proizvodom, inženjeringom, pravnom službom, privatnošću i upravljanjem dobavljačima.

Korak 1: izradite registar razdoblja podrške

Izradite jedan redak po verziji proizvoda i uključite:

• proizvod i verziju
• datum izdanja
• datum početka podrške
• standardni datum završetka sigurnosne podrške
• mogućnost produljene podrške
• način isporuke ažuriranja
• kanal za objavu ranjivosti
• cilj za kritičnu zakrpu
• ulogu u obradi podataka, kao što su voditelj obrade, izvršitelj obrade ili oboje
• kritične dobavljače i komponente
• pogođene sektore klijenata
• vlasnika rizika
• datum odobrenja
• lokaciju dokaza

Taj registar postaje dokumentirana informacija u okviru ISMS-a. Zenith Blueprint, faza temelja ISMS-a i vodstva, Korak 6, daje očekivanje za upravljanje dokumentima:

“Dokumenti trebaju imati odgovarajuću identifikaciju (naslov, možda broj dokumenta ili jedinstveni identifikator, autora), odgovarajući format te pregled i odobrenje prikladnosti prije uporabe.”

Izvor: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza temelja ISMS-a i vodstva, Korak 6: dokumentirane informacije i izgradnja repozitorija dokumenata ISMS-a Zenith Blueprint

Clarysec Enterprise PIMS Documented Information Evidence Management Policy PIMS Documented Information Evidence Management Policy primjenjuje slična načela dokazivanja na dokumentaciju o privatnosti:

“[Svi] Privacy Lead / PIMS Manager MORA dodijeliti identifikator dokumenta, vlasnika, broj verzije, status odobrenja, datum stupanja na snagu i datum pregleda u REG12 prije objave dokumentiranih informacija PIMS-a.”

Izvor: PIMS Documented Information Evidence Management Policy, izrada, odobravanje, verzioniranje i objava, točka 4.2.1 PIMS Documented Information Evidence Management Policy

Čak i ako registar razdoblja podrške po zadanim postavkama nije dokument o privatnosti, primjenjuje se ista disciplina: vlasnik, verzija, odobrenje, datum stupanja na snagu i datum pregleda.

Korak 2: povežite obećanja podrške s obradom rizika

Za svaku verziju proizvoda izradite scenarije rizika kao što su:

• Kritična ranjivost otkrivena je u podržanoj verziji, ali inženjerski kapacitet nije dostupan.
• Komponenta treće strane ostaje bez podrške prije završetka deklariranog razdoblja sigurnosne podrške.
• Dobavljač mijenja lokaciju hostinga ili podizvršitelja i utječe na isporuku ažuriranja.
• Ranjivost utječe na osobne podatke i pokreće procjenu povrede privatnosti.
• Regulirani financijski klijent zahtijeva dokaze o otpornosti IKT trećih strana.

ISO/IEC 27001:2022 točke 6.1.1 do 6.1.3 pružaju planski mehanizam: identificirati rizike, procijeniti vjerojatnost i posljedice, dodijeliti vlasnike rizika, odabrati obrade, usporediti odabrane kontrole s Annex A, izraditi Izjavu o primjenjivosti i dobiti odobrenje preostalog rizika.

Za rizik “nepodržana komponenta prije datuma završetka podrške”, zapis rizika treba uključivati kontrole ISO/IEC 27002:2022 5.31, 8.8 i 8.25, kao i kontrole dobavljača kao što su 5.19 informacijska sigurnost u odnosima s dobavljačima, 5.20 uređivanje informacijske sigurnosti u ugovorima s dobavljačima, 5.21 upravljanje informacijskom sigurnošću u IKT opskrbnom lancu i 5.22 praćenje, pregled i upravljanje promjenama usluga dobavljača.

Korak 3: postavite pravila za dokaze o ranjivostima i zakrpama

Razdoblje podrške vjerodostojno je samo ako upravljanje ranjivostima funkcionira tijekom tog razdoblja.

SME Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME postavlja strogi zahtjev za hitnu izloženost:

“Kritične zakrpe moraju se primijeniti u roku od 3 dana od objave, osobito za sustave izložene internetu”

Izvor: Vulnerability and Patch Management Policy-sme, zahtjevi za provedbu politike, točka 6.1.1 Vulnerability and Patch Management Policy - SME

Također zahtijeva zapise spremne za reviziju:

“Zapisnik zakrpa mora se održavati i pregledavati tijekom revizija i aktivnosti odgovora na incidente”

Izvor: Vulnerability and Patch Management Policy-sme, zahtjevi upravljanja, točka 5.4.1 Vulnerability and Patch Management Policy - SME

Za poslovna okruženja, Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy zahtijeva:

“Centralizirani Registar upravljanja ranjivostima mora održavati tim sigurnosnih operacija, a CISO ili delegirano tijelo mora ga pregledavati mjesečno.”

Izvor: Vulnerability and Patch Management Policy, zahtjevi upravljanja, točka 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, faza kontrola u praksi, Korak 19, objašnjava operativno očekivanje iza kontrole ISO/IEC 27002:2022 8.8:

“Budite informirani o novim sigurnosnim greškama (putem upozorenja dobavljača, CVE izvora itd.) za svoj softver i hardver. Procijenite koje su relevantne (koristimo li taj softver? koliko je greška kritična?) i pravodobno primijenite ispravke ili mjere ublažavanja.”

Izvor: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza kontrola u praksi, Korak 19: tehnološke kontrole I Zenith Blueprint

Svaka podržana verzija proizvoda treba revizijski trag dokaza o ranjivostima: zaprimanje, analiza relevantnosti, ozbiljnost, pogođene verzije, plan otklanjanja, izdanje ispravka, smjernice za ublažavanje, komunikacija s klijentima i odobrenje zatvaranja.

Korak 4: povežite siguran razvoj s trajanjem podrške

Sigurnosna podrška počinje prije izdanja. Ovisi o razvojnim praksama koje omogućuju održavanje proizvoda.

SME Secure Development Policy-sme Secure Development Policy - SME navodi:

“Komponente se moraju redovito ažurirati kada se objave sigurnosne zakrpe. Ako se identificira kritična ranjivost, komponenta se mora odmah nadograditi ili zamijeniti.”

Izvor: Secure Development Policy-sme, zahtjevi za provedbu politike, točka 6.6.3 Secure Development Policy - SME

SME Application Security Requirements Policy-sme Application Security Requirements Policy - SME zahtijeva da ugovori i zahtjevi:

“specificiraju obveze za objavu ranjivosti, rokove odgovora i zakrpavanje.”

Izvor: Application Security Requirements Policy-sme, zahtjevi upravljanja, točka 5.3.2 Application Security Requirements Policy - SME

Ako organizacija obeća podršku do 2031., arhitektura mora podržavati održiva ažuriranja, zamjenu ovisnosti, sigurne cjevovode izrade, regresijsko testiranje i hitna izdanja. Kontrole ISO/IEC 27002:2022 za siguran razvoj, sigurnu arhitekturu, sigurno kodiranje, sigurnosno testiranje, razvoj povjeren vanjskim izvođačima, razdvajanje okruženja i upravljanje promjenama postaju omogućitelji razdoblja podrške.

Jedan skup dokaza za CRA, NIS2, DORA i GDPR

Isti dokazi o razdoblju podrške mogu zadovoljiti različite regulatorne razgovore, ali svaki okvir postavlja pitanje na drukčiji način.

Ovisnost o dobavljačima često je mjesto na kojem obveze podrške ne uspijevaju. Enterprise Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy zahtijeva:

“Registar ovisnosti o dobavljačima: VMO mora održavati ažuran registar svih kritičnih dobavljača, uključujući detalje kao što su pružene usluge/proizvodi; je li dobavljač jedini izvor; dostupni alternativni dobavljači ili mogućnost zamjene; trenutačni ugovorni uvjeti; i procjena utjecaja ako dobavljač prestane pružati uslugu ili bude kompromitiran.”

Izvor: Supplier Dependency Risk Management Policy, zahtjevi za implementaciju, točka 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, faza kontrola u praksi, Korak 23, upozorava da će revizori pregledavati ugovore s dobavljačima i dokaze o praćenju dobavljača:

“Revizori će pregledati uzorke ugovora ili ugovora o razini usluge. Traže izričite odredbe o informacijskoj sigurnosti, kao što su rokovi za prijavu povrede, ograničenja pristupa, obveze obrade podataka, zahtjevi za šifriranje ili prava na reviziju.”

Izvor: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza kontrola u praksi, Korak 23: organizacijske kontrole Zenith Blueprint

Za klijente obuhvaćene DORA-om to je kritično. Ugovori za IKT usluge koje podržavaju kritične ili važne funkcije trebaju jasne opise usluga, uvjete podugovaranja, sigurnosne mjere, pomoć pri incidentima, prava na reviziju i inspekciju, prava raskida i prijelazne aranžmane. Dobavljač koji ne može podržati te obveze može spriječiti proizvođača da da vjerodostojno obećanje o razdoblju podrške.

Mapiranje kontrola za upravljanje razdobljem podrške spremno za reviziju

Ovo mapiranje omogućuje timovima za sigurnost, pravnu službu, proizvod i prodaju da govore istim jezikom. Registar razdoblja podrške nije samo dokaz za CRA. On je provjera sigurnosti dobavljača za NIS2, provjera trećih strana za DORA, podrška sigurnosti obrade za GDPR i upravljački artefakt za certifikaciju ISO 27001.

Aspekt privatnosti: kada nepodržano postaje nesigurno

Upravljanje razdobljem sigurnosne podrške nije samo pitanje kibernetičke sigurnosti. Ako proizvod pohranjuje, prenosi ili obrađuje osobne podatke, nepodržani softver može postati rizik za privatnost.

GDPR se primjenjuje na obradu u kontekstu poslovnog nastana u EU i može se primijeniti i na organizacije izvan EU koje nude robu ili usluge pojedincima u EU ili prate njihovo ponašanje. Osobne podatke definira široko, a povredu osobnih podataka tretira kao povredu sigurnosti koja dovodi do slučajnog ili nezakonitog uništenja, gubitka, izmjene, neovlaštenog otkrivanja ili pristupa obrađivanim osobnim podacima.

Za upravljanje razdobljem podrške timovi za privatnost moraju znati koje verzije proizvoda obrađuju osobne podatke (PII), koji su sustavi još podržani i utječu li ranjivosti na povjerljivost, cjelovitost ili dostupnost osobnih podataka.

Clarysec Enterprise PII Security Access Control Policy PII Security Access Control Policy zahtijeva:

“[Oba] Vlasnik sustava / vlasnik aplikacije MORA evidentirati obuhvat procjene ranjivosti za sustave koji obrađuju PII u REG12 najmanje tromjesečno i nakon značajne tehničke promjene.”

Izvor: PII Security Access Control Policy, sigurna konfiguracija i upravljanje ranjivostima, točka 4.7.4 PII Security Access Control Policy

Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy dodaje kontinuirano praćenje za visokorizične odnose u području privatnosti:

“[Svi] Vlasnik dobavljača / nabave MORA tromjesečno pratiti aktivne visokorizične odnose s izvršiteljima obrade i podizvršiteljima obrade, a ostale aktivne odnose s izvršiteljima obrade i podizvršiteljima obrade PII godišnje, prema uvjetima dubinske analize dobavljača, statusu ugovora, statusu provjere sigurnosti, otvorenim pitanjima i datumima pregleda u REG08.”

Izvor: Processor Subprocessor Third Party Privacy Management Policy, kontinuirano praćenje, pomoć, sučelje za otkrivanje i izlaz, točka 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

Kada ranjivost postane incident, Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy zahtijeva procjenu okidača kroz više okvira:

“[Uvjetno] Privacy Lead / PIMS Manager MORA procijeniti primjenjive pravne, sektorske, financijske, kibernetičke, ugovorne, klijentske i okidače izvješćivanja prema primateljima usluge za svaki incident visokog utjecaja u vezi s osobnim podacima i evidentirati ishod primjenjivosti u REG01, REG08 i REG10.”

Izvor: PII Incident Breach Management Policy, klasifikacija i procjena povrede, točka 4.2.6 PII Incident Breach Management Policy

To je praktično preklapanje između obveza podrške prema CRA, komunikacije o incidentima prema NIS2, postupanja s velikim IKT incidentima prema DORA-i i odgovornosti za povrede prema GDPR-u.

Kako revizori testiraju isti proces razdoblja podrške

Snažan proces upravljanja razdobljem podrške treba izdržati više stilova revizije. Dokazi se ne mijenjaju mnogo, ali se mijenja perspektiva revizora.

NIST CSF 2.0 koristan je kao komunikacijski sloj jer njegova funkcija GOVERN uključuje pravne, regulatorne, ugovorne i privatnosne obveze, ciljeve upravljanja rizicima, apetit za rizik, uloge, politike i nadzor. Ishodi za opskrbni lanac obuhvaćaju strategiju dobavljača, kritičnost, ugovore, dubinsku analizu dobavljača, praćenje, koordinaciju incidenata i odredbe o završetku odnosa.

Revizori u stilu COBIT-a i ISACA-e često se usmjeravaju na dizajn upravljanja: tko je vlasnik odluke, koji je proces definiran, koje metrike pokazuju učinkovitost, kako se iznimke odobravaju i kako se provodi kontinuirano poboljšanje.

Clarysec Enterprise Information Security Policy Information Security Policy sažima načelo revizivosti:

“Sve implementirane kontrole moraju biti revizijski provjerljive, potkrijepljene dokumentiranim postupcima i zadržanim dokazima o radu.”

Izvor: Information Security Policy, zahtjevi za provedbu politike, točka 6.6.1 Information Security Policy

To je rečenica koju svako razdoblje sigurnosne podrške mora moći zadovoljiti.

Produljite, skratite ili završite podršku bez stvaranja lažnog jamstva

Najteži upravljački trenuci nisu pri lansiranju proizvoda. Događaju se kada se stvarnost promijeni.

Možda ćete trebati produljiti podršku jer regulirani klijenti ovise o proizvodu, migracija nije izvediva ili sektorski klijent ima ugovorne potrebe za kontinuitetom. Možda ćete trebati skratiti ili ograničiti podršku jer dobavljač povlači sigurnosno održavanje, komponentu više nije moguće zakrpati, platforma doseže tehnička ograničenja ili arhitektura proizvoda ne može sigurno podržati određenu klasu ranjivosti.

Kontrolirana promjena razdoblja podrške treba uključivati:

• okidač promjene, kao što su kraj životnog vijeka kod dobavljača, kritična ranjivost, ugovor s klijentom ili regulatorna promjena
• pogođene proizvode, verzije, klijente i sektore
• analizu utjecaja na osobne podatke i kritične usluge
• pregled izvedivosti za dobavljače i komponente
• procjenu rizika i odluku o preostalom riziku
• ažurirani registar razdoblja podrške
• ažuriranu obavijest klijentima i ugovornu poziciju
• ažurirane napomene u Izjavi o primjenjivosti kada se mijenjaju kontrole ili obveze
• odobrenje uprave i datum pregleda

Enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy koristan je kada je promjena potaknuta ranjivošću:

“Plan otklanjanja ili ublažavanja mora se izraditi za sve potvrđene ranjivosti. Implementacija ispravka mora se prioritizirati prema ozbiljnosti. Primjerice, kritične ranjivosti moraju se otkloniti ili ublažiti u roku od 14 dana kada je izvedivo, ili ranije kada se otkrije aktivno iskorištavanje, dok se problemi niže ozbiljnosti moraju riješiti u razumnom roku.”

Izvor: Coordinated Vulnerability Disclosure Policy, zahtjevi za implementaciju, točka 6.6 Coordinated Vulnerability Disclosure Policy

Ako se potpuni ispravak ne može isporučiti odmah, kompenzacijske kontrole, onemogućena funkcionalnost, pojačano praćenje ili smjernice za konfiguraciju klijentima mogu privremeno biti prihvatljivi, ali odluka mora biti dokumentirana i komunicirana.

Praktični Clarysec kontrolni popis za spremnost razdoblja podrške

Koristite ovaj kontrolni popis prije objave ili obnove bilo koje obveze razdoblja sigurnosne podrške prema CRA.

• Je li proizvod i verzija navedena u registru razdoblja podrške?
• Je li datum završetka podrške odobren od strane proizvoda, sigurnosti i odgovornog rukovodstva?
• Jesu li pravni, regulatorni i ugovorni pokretači mapirani u registru usklađenosti?
• Je li scenarij rizika razdoblja podrške uključen u registar rizika?
• Jesu li kontrole mapirane u Izjavi o primjenjivosti, uključujući 5.31, 8.8 i 8.25 kada je primjenjivo?
• Jesu li kritični dobavljači i komponente mapirani u registru ovisnosti o dobavljačima?
• Postoje li dokazi da se komponente mogu zakrpati ili zamijeniti tijekom razdoblja podrške?
• Jesu li definirane odgovornosti za zaprimanje, trijažu, otklanjanje i objavu ranjivosti?
• Jesu li SLA-ovi za kritične zakrpe usklađeni s politikom i ugovorima s klijentima?
• Zadržavaju li se zapisnici zakrpa, zapisi izdanja i odluke o ranjivostima?
• Jesu li sustavi s osobnim podacima obuhvaćeni dokazima procjene ranjivosti kada se obrađuje PII?
• Jesu li obavijesti klijentima, izjave o podršci i ugovorni uvjeti međusobno usklađeni?
• Postoji li proces za produljenje, skraćivanje ili završetak podrške uz odobrenje rizika?
• Primaju li preispitivanja uprave ulazne informacije o rizicima razdoblja podrške, dobavljačima, ranjivostima i incidentima?
• Mogu li se dokazi dostaviti u roku od 48 sati za reviziju klijenta ili upit regulatornog tijela?

Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy dodatno naglašava disciplinu preispitivanja uprave za programe privatnosti:

“[Oba] Najviše rukovodstvo MORA pregledati nesukladnosti PIMS-a, korektivne radnje, rezultate praćenja, rezultate revizije, rizike za privatnost, provjeru sigurnosti dobavljača i ulazne informacije o promjenama zainteresiranih strana u REG12 tijekom svakog preispitivanja uprave.”

Izvor: PIMS Monitoring Audit Improvement Policy, preispitivanje PIMS-a od strane uprave, točka 4.3.5 PIMS Monitoring Audit Improvement Policy

Za upravljanje razdobljem sigurnosne podrške isti ritam pregleda treba primijeniti kroz ISMS: ranjivosti, učinkovitost zakrpavanja, provjera sigurnosti dobavljača, obveze prema klijentima, incidenti, iznimke podrške i korektivne radnje trebaju ulaziti u preispitivanje uprave.

Učinite razdoblje sigurnosne podrške dokazivim

Akt EU-a o kibernetičkoj otpornosti mijenja način razmišljanja o sigurnosti proizvoda. Potiče proizvođače i pružatelje softvera da razmišljaju izvan dana izdanja. Razdoblje sigurnosne podrške postaje obećanje kroz životni ciklus koje mora biti inženjerski omogućeno, upravljano, praćeno i dokazano.

Za CISO-e, pouka je jasna: ne dopustite da razdoblje podrške postoji samo u marketingu proizvoda. Za rukovoditelje usklađenosti, ne gradite zaseban silos dokaza za CRA. Za revizore, provjerite jesu li obveze podrške sljedive do rizika, kontrola, dobavljača, incidenata i dokumentiranih odobrenja. Za vlasnike poslovanja, zapamtite da vjerodostojno razdoblje podrške može postati tržišna prednost, osobito pri prodaji sektorima reguliranima NIS2, financijskim subjektima obuhvaćenima DORA-om i klijentima osjetljivima na privatnost.

Clarysec pomaže organizacijama da to provedu kroz:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint za izgradnju sljedivosti ISMS-a, dokumentiranih informacija, mapiranja Izjave o primjenjivosti i spremnosti za reviziju
• Zenith Controls: The Cross-Compliance Guide Zenith Controls za mapiranje kontrola ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 i revizijska očekivanja
• pakete politika za velika poduzeća i MSP-ove za upravljanje ranjivostima, siguran razvoj, pravnu usklađenost, ovisnost o dobavljačima, dokaze o privatnosti i odgovor na incidente
• praktične registre i radne tokove dokaza koji obećanja o razdoblju podrške pretvaraju u revizijski provjerljivo upravljanje

Vaš je sljedeći korak jednostavan: odaberite jednu ključnu verziju proizvoda i izradite njezin dosje dokaza o razdoblju sigurnosne podrške. Mapirajte obvezu, odobrite razdoblje podrške, testirajte proces upravljanja ranjivostima, provjerite ovisnosti o dobavljačima, potvrdite komunikaciju s klijentima i zadržite zapise.

Ako možete opravdati jedan proizvod, možete skalirati model. Ako ne možete opravdati jedan proizvod, praznina nije u dokumentaciji. Praznina je u upravljanju.

Preuzmite Zenith Blueprint, koristite Zenith Controls za mapiranje svojih dokaza ili zatražite Clarysec procjenu spremnosti kako biste razdoblja sigurnosne podrške prema CRA pretvorili u upravljanje prema ISO 27001 spremno za reviziju.