Ierosinātajam pagaidu risinājumam būs vajadzīgas tikai šādas KDP, kas ir daļa no šā dokumenta:

KDP mērķis ir nodrošināt, ka IT pakalpojumi, kas saistīti ar ES ETS un Šveices ETS reģistru sasaistes darbību, tiek sniegti rezultatīvi un efektīvi, proti, ka tiek izpildīti pakalpojuma pieprasījumi, novērstas pakalpojumu atteices, atrisinātas problēmas un ka rutīnas operacionālie uzdevumi tiek izpildīti saskaņā ar starptautiskajiem IT pakalpojumu vadības standartiem.

IT pakalpojumu vadība

IT

sekretāre no Šveices puses

sekretāre no Eiropas Savienības puses

·KDP atbalstam, jo īpašu incidentu vadības, problēmu vadības un pieprasījumu izpildes aspektā, un saziņai starp abām pusēm izmanto IT pakalpojumu vadības (ITSM) rīku.

Ja iespējams, sākotnējo diagnostiku veic apkalpošanas dienests, kas reģistrējis pretenziju. Lai to izdarītu, apkalpošanas dienests vispirms noskaidros, vai incidents nav jau zināma kļūda. Tādā gadījumā risināšanas gaita vai aprisinājums jau ir zināms un dokumentēts.

Klasificēšanas posmā incidents jākategorizē un jāprioritizē atkarībā no ietekmes un steidzamības, lai to varētu risināt tā prioritātei atbilstošā termiņā.

·Vispārīgā skatījumā incidentu vadība sastāv no šādām darbībām:

Incidentu vadības procesa mērķis ir panākt, ka IT pakalpojumi pēc iespējas ātrāk un ar minimāliem darbības traucējumiem atsāk darboties normālā pakalpojumu sniegšanas režīmā.

Kad incidents ir noslēgts, to vairs neatver. Ja incidents pēc neilga laika atkārtojas, reģistrē jaunu incidentu, nevis vēlreiz atver sākotnējo incidentu.

Incidentu formāli noslēdz tad, kad apkalpošanas dienests ir pabeidzis incidenta noslēgšanas posmu un par to paziņojis otrai pusei.

Noslēgšanas posmā ir jāveic virkne darbību, no kurām īpaši izceļamas šādas:

Atkopšanu var veikt IT atbalsta darbinieki vai arī galalietotājs, kam dod norādījumus, kā to izdarīt.

Ierasta prakse izmeklēšanas un diagnostikas posmā ir mēģinājums reproducēt incidentu kontrolētos apstākļos. Incidenta izmeklēšanas un diagnostikas gaitā ir ļoti svarīgi izprast to notikumu secību, kas pie incidenta noveduši.

Pieprasījuma izpildes procesa ietvaros no sākuma līdz beigām tiek pārvaldīti pieprasījumi pēc jauna vai esoša pakalpojuma, proti, no brīža, kad pieprasījums tiek reģistrēts un apstiprināts, līdz brīdim, kad tas tiek noslēgts. Pakalpojuma pieprasījumi parasti ir nelieli, iepriekš definēti, atkārtojami, bieži, iepriekš apstiprināti un procedurāli pieprasījumi.

Par problēmas atrisināšanu ir atbildīga risinātāju grupa, kam problēma piešķirta, un tā ir atbildīga arī par to, ka grupas puses apkalpošanas dienestam tiek sniegta relevantā informācija.

Lai problēmām varētu vieglāk izsekot, tās var iedalīt kategorijās pēc to smaguma un prioritātes tādā pašā veidā kā incidentus, ņemot vērā saistīto incidentu ietekmi un biežumu.

Problēmu var ierosināt incidents, vai arī to var ierosināt pēc pašu iniciatīvas, lai novērstu jebkurā sistēmas posmā atklātās nepilnības.

Problēmas unikālais identifikators ir identifikators, ko piešķir IT pakalpojumu vadība (ITSM). To izmanto jebkādā saziņā par šo problēmu.

Atkarībā no tā, kura puse ierosinājusi pretenziju, kontaktpunkts ar problēmu saistītajos jautājumos būs ES vai CH apkalpošanas dienests.

Šī procedūra ir jāievēro ikreiz, kad tiek identificēta problēma, kas savukārt ierosina problēmu vadības procesu. Problēmu vadības galvenais uzdevums ir uzlabot kvalitāti un samazināt incidentu skaitu. Problēma var būt viena vai vairāku incidentu cēlonis. Kad tiek ziņots par incidentu, incidentu vadības mērķis ir pēc iespējas ātrāk atjaunot pakalpojumu, tostarp izmantojot aprisinājumus. Kad problēma reģistrēta, mērķis ir izpētīt problēmas pamatcēloni, lai noskaidrotu, kādas izmaiņas vajadzīgas, lai nodrošinātu, ka problēma un ar to saistītie incidenti vairs nenotiek.

Trešā puse, kurai pakalpojuma pieprasījums novirzīts, ir atbildīga par pakalpojuma pieprasījuma savlaicīgu risināšanu un saziņu ar to apkalpošanas dienestu, kas pakalpojuma pieprasījumu eskalējis.

·pakalpojuma pieprasījuma realizācija skar gan ES, gan CH. Tādā gadījumā apkalpošanas dienesti izdod darba rīkojumus savā atbildības jomā. Pakalpojuma pieprasījuma izpildes norisi savstarpēji koordinē abi apkalpošanas dienesti. Vispārējā atbildība gulstas uz to apkalpošanas dienestu, kas pakalpojuma pieprasījumu saņēmis un iniciējis.

Pakalpojuma pieprasījumu izvirzījušās puses apkalpošanas dienesta darbinieks pārbauda, vai ir vajadzīgs kāds apstiprinājums no otras puses, un, ja jā, rīkojas, lai to saņemtu. Ja pakalpojuma pieprasījums netiek apstiprināts, apkalpošanas dienests atjaunina un noslēdz pretenziju.

Attiecībā uz visiem pakalpojuma pieprasījumiem kontaktpunkts ir ES vai CH apkalpošanas dienests atkarībā no tā, kura puse izvirzījusi pakalpojuma pieprasījumu. Šis apkalpošanas dienests ir atbildīgs par pakalpojuma pieprasījuma reģistrēšanu un rūpīgu analīzi.

Ar pakalpojuma pieprasījumu saistīto informāciju ES vai CH apkalpošanas dienestam iesniedz pa e-pastu, telefoniski, izmantojot IT pakalpojumu vadības (ITSM) rīku vai citu norunātu saziņas kanālu.

Izmaiņas pieprasījumu (RFC) iesniedz izmaiņu vadības vienībai validēšanai un apstiprināšanai. Attiecībā uz visiem izmaiņas pieprasījumiem kontaktpunkts ir ES vai CH apkalpošanas dienests atkarībā no tā, kura puse izvirzījusi izmaiņas pieprasījumu. Šis apkalpošanas dienests ir atbildīgs par izmaiņu pieprasījuma reģistrēšanu un rūpīgu analīzi.

Mērķis ir nodrošināt, ka tiek izmantotas standartizētas metodes un procedūras, kā efektīvi un nekavējoties pārņemt kontroli pār visām izmaiņām, kas skar IT infrastruktūru, lai līdz minimumam samazinātu jebkādu saistīto incidentu skaitu un ietekmi uz pakalpojumiem. Izmaiņas IT infrastruktūrā var rasties reaktīvi — kā atbildes reakcija uz problēmām vai ārēji uzliktām prasībām, piemēram, normatīvo aktu grozījumiem — vai proaktīvi — lai uzlabotu rezultativitāti un efektivitāti vai atspoguļotu komerciālas iniciatīvas.

Laidums parasti sastāv no vairākiem problēmu labojumiem un pakalpojuma uzlabojumiem. Tas satur nepieciešamo jauno vai izmanīto programmatūru un jebkādu jaunu vai izmainītu aparatūru, kas nepieciešama apstiprināto izmaiņu ieviešanai.

Laidums jeb izlaišana nozīmē vienu vai vairākas izmaiņas IT pakalpojumā, kas ir apkopotas laiduma plānā un kas ir jāautorizē, jāsagatavo, jākompilē, jātestē un jāievieš vienlaikus. Vienvienīgs laidums var būt kļūdas izlabošana, aparatūras vai citu komponentu maiņa, izmaiņas programmatūrā, lietojumprogrammu versiju atjauninājumi, izmaiņas dokumentācijā un/vai procesos. Katra laiduma saturu pārvalda, testē un ievieš kā vienvienīgu vienumu.

Ja ieviešana ir kļūmīga vai testēšanā ir noskaidrojies, ka ieviešana nav bijusi sekmīga vai nav atbildusi norunātajiem akceptēšanas/kvalitātes kritērijiem, abu pušu laiduma vadības vienībām ir jānodrošina atrite iepriekšējā stāvoklī. Par to jāinformē visas attiecīgās ieinteresētās personas, toskait skartie/ aptvertie galalietotāji. Kamēr nav saņemts apstiprinājums, procesu var atsākt jebkurā no iepriekšējiem posmiem.

Atkarībā no drošības notikuma veida informācijas drošības speciālists nosaka, kādas organizācijas jāiesaista IMT.

·atkarībā no drošības incidenta smaguma laikus eskalēt līdz pienācīgam līmenim informēšanas un/vai lēmumu pieņemšanas nolūkā.

Tādā gadījumā incidentu raksturo kā informācijas drošības incidentu, nekavējoties reģistrē IT pakalpojumu vadības rīkā un kā tādu arī pārvalda.

·ievāc laiduma kopsavilkuma dokumentu no īstenošanas vienībām;

Informācijas drošības vadības mērķis ir nodrošināt organizācijas klasificētās informācijas, datu un IT pakalpojumu konfidencialitāti, integritāti un pieejamību. Līdztekus tehniskajiem komponentiem, t. sk. projektēšanai un testēšanai (sk. STS), pagaidu risinājuma drošības prasību izpildei ir vajadzīgas šādas kopējas darbības procedūras.

·apmācības un kapacitātes veidošanas iespējas, lai pastiprinātu reģistru sistēmu noturību informācijas drošības aspektā, mazinātu turpmāku incidentu risku un minimizētu to ietekmi.

·ja reģistrs iepriekš ticis atslēgts, to atkal pieslēdz;

Pēc incidenta raksturošanas IMT novērtē jebkura jauna drošības incidenta smagumu un nekavējoties sāk rīkoties atkarībā no smaguma pakāpes.

IMT incidenta izskatīšanā sadarbojas ar visām iesaistītajām organizācijām un attiecīgajiem to vienību dalībniekiem. Analīzes gaitā noskaidro aktīva konfidencialitātes, integritātes vai pieejamības zuduma apmēru un novērtē, kā tas ietekmēs visas skartās organizācijas. Pēc tam tiek definētas sākotnējās un pēcākās darbības, kā atrisināt incidentu un pārvaldīt tā ietekmi, tostarp šo darbību ietekmi uz resursiem.

Sensitīvās informācijas aktīvus identificē, balstoties uz to ietekmi uz sasaisti.

Šīs informācijas sensitivitātes pakāpi novērtē saskaņā ar sensitivitātes skalu, kas piemērojama šai sasaistei un kas sīki izklāstīta šā dokumenta sadaļā “Rīkošanās informācijas drošības incidentu gadījumā”.

10.2.Informācijas aktīvu sensitivitātes pakāpes

Identificējot informācijas aktīvus, tos klasificē pēc šādiem noteikumiem:

·ja identificēta vismaz viena AUGSTA konfidencialitātes, integritātes vai pieejamības pakāpe, aktīvs klasificējams kā “ETS KRITISKI SVARĪGS” aktīvs;

·ja identificēta vismaz viena VIDĒJA konfidencialitātes, integritātes vai pieejamības pakāpe, aktīvs klasificējams kā “ETS SENSITĪVS” aktīvs;

·ja identificēta tikai ZEMA konfidencialitātes, integritātes vai pieejamības pakāpe, aktīvs klasificējams kā “ETS IEROBEŽOTAS PIEEJAMĪBAS” aktīvs.

10.3.Informācijas aktīvu īpašnieka nozīmēšana

Visiem informācijas aktīviem nozīmē īpašnieku. ETS informācijas aktīvi, kas ir daļa no EUTL un SSTL sasaistes vai ir ar to saistīti, ir jāiekļauj kopējo aktīvu inventarizācijas sarakstā, ko uztur abas puses. ETS informācijas aktīvi, kas nav daļa no EUTL un SSTL sasaistes, ir jāiekļauj aktīvu inventarizācijas sarakstā, ko uztur attiecīgā puse.

Par to, kas ir īpašnieks katram informācijas aktīvam, kurš ir daļa no EUTL vai SSTL sasaistes vai ir ar to saistīts, puses vienojas savā starpā. Par informācijas aktīva sensitivitātes novērtēšanu atbild tā īpašnieks.

Īpašniekam jābūt senioritātei, kas atbilst piešķirto aktīvu vērtībai. Par īpašnieka atbildību par aktīvu(-iem) un pienākumu uzturēt vajadzīgo konfidencialitātes, integritātes un pieejamības līmeni ir jāvienojas un šie aspekti ir jāformalizē.

10.4.Sensitīvas informācijas reģistrēšana

Visu sensitīvo informāciju iekļauj sensitīvās informācijas sarakstā (SIL).

SIL ir jāņem vērā un jāreģistrē gadījumi, kad sensitīvas informācijas sakopojumam (piemēram, informācijas kopumam, kas glabājas sistēmas datubāzē) var būt lielāka ietekme nekā vienvienīgam informācijas aktīvam.

SIL nav statisks. Ar aktīviem saistītie draudi, ievainojamības, drošības incidentu iespējamība vai sekas var mainīties negaidīti; tāpat reģistru sistēmas darbībā var tikt ieviesti jauni aktīvi.

Tāpēc SIL regulāri pārskata, un jebkādu jaunu informāciju, kas identificēta kā sensitīva, nekavējoties reģistrē SIL.

Katrā SIL ierakstā norāda vismaz šādas ziņas:

·informācijas apraksts;

·informācijas īpašnieks;

·sensitivitātes pakāpe;