Vyhláška o klasfikácií informačných systémov a bezpečnostných opatreniach - pripomienkovanie

Suhlasim. A myslim ze prave preto, podla tohto vzoru by sa vyhlaska mohla rozdelit do viacerych dokumentov. Ked bude vsetko v jednej, stale ju bude treba aktulizovat.
Okrem toho, standardy a pravne dokumenty su iba jedna cast systemu. Druha dolezita cast su kompetentne personalne zdroje, schopne tie standardy naplnat. Bez nich to fungovat nebude. Hocako perfektne tie stadardy budu. Vynos a ISO 2700X tu mame roky a vidime aky je stav.

3 Likes

Bol som explicitne vyzvaný, aby som v tejto diskusii vyjadril svoj názor na návrh Vyhlášky o klasifikácii IS a bezpečnostných opatreniach. Na tej vyššej úrovni podľa mňa to hlavné už napísal Ivan - ak sa ten dokument nerozdelí na viac častí, hrozí že kvôli jednotlivým “prkotinám” bude potrebné novelizovať celú rozsiahlu vyhlášku - a už aj teraz mám podozrenie, že málokto má/bude mať chuť si to všetko dôkladne prečítať. No a keďže podrobnejším skúmaním jednotlivých ustanovení návrhu vyhlášky sa tu tuším nikto nepochválil, dovolím si teraz uviesť aspoň hlavné poznámky k prvej pätine dokumentu. Enjoy!

§2 – je potrebné rozlišovať medzi informačným aktívom typu dáta a informačným aktívom typu (informačný) systém. To preto, že narušenie integrity dát nie je to isté ako narušenie integrity systému (trebárs neoprávnená úprava aplikácie, ktorá z tých istých (nezmenených) dát vytvorí iný výstup). Obávam sa, že v návrhu vyhlášky sa pod narušením integrity rozumie len narušenie integrity dát…

Napríklad, v bode (3) „I0 (nepodstatná) pokiaľ narušenie integrity nemá žiadny vplyv na orgán riadenia“ – kým narušenie integrity dát nemusí mať „vplyv na orgán riadenia“, v prípade narušenia integrity systému to môže mať vplyv na kvalitu poskytovanej služby (presnosť, vierohodnosť výstupov) a v takom prípade by asi neplatilo že „nemá žiadny vplyv na orgán riadenia“

§3 zaradenia ITVS sa má vykonať podľa aktíva s najvyšším klasifikačným stupňom – OK, ale čo sa potom myslí pod ITVS – (v nejakom zmysle) ucelený systém, alebo kolekcia všetkého, čo orgán riadenia prevádzkuje? Aby sa nestalo, že kvôli jednému zaprášenému aktívu sa budú do jeho kategórie zaradené aj nesúvisiace aktíva/systémy

§3 bod (3) má zmysel len ak sa to bude vyžadovať nie jednorazovo, ale po každej (zmysluplnej) aktualizácii

§5 – nie je z neho jasné, čo v prípade napr. vzniku nového úradu – kde bude zaradený? To sa bude kvôli tomu novelizovať vyhláška?

§7 „Akékoľvek výnimky z implementácie bezpečnostných opatrení sú orgánom vedenia dokumentované, odôvodnené, schválené štatutárom a zaslané orgánu vedenia na schválenie.“ – to nedáva zmysel, zrejme ma byť „…orgánom riadenia dokumentované,…“

Príloha č.1

Klasifikačný stupeň I2, Príklad incidentu/Dopad – odporúčam namiesto ransomvéru uvažovať zmenu aplikácie a „nemožnosť vykonávať bežnú agendu“ nahradiť „cielené ovplyvnenie bežnej agendy“. Podobne pre Klasifikačný supeň I3 odporúčam namiesto neoprávnenej modifikácie dát o bankových účtoch uviesť ako príklad cielená zmena rozhodnutí s právnymi účinkami

Príloha č.2

Skupina Z0 – rád sa nechám poučiť, ako si prevádzkovateľ môže od dodávateľa vynútiť pravidelnú aktualizáciu firmvéru, ako to predpisuje písmeno f). Odhlásenie/zamknutie koncovej stanice odporúčam pri každom odchode z príslušnej miestnosti, nie z pracoviska (písmeno g)

Z1B (Personálna bezpečnosť) – písm. f) bod č. – odporúčam

  • nielen zrušenie prístupových práv do ITVS, ale aj do chránených priestorov v ktorých sa nachádzajú kľúčové informačné aktíva (zmena/zablokovanie PIN k alarmu …)

  • podľa potreby zmenu hesiel pre správu systému, vrátane tých „v obálkach“ (ak pracovný pomer končí správca systému)

Z1E (Ochrana proti škodlivému kódu) – písm. d) odporúčam okrem sťahovania súborov prostredníctvom sietí uvažovať aj používanie médií z externých (neznámych neistých, podozrivých) zdrojov

Z1F (Sieťová bezpečnosť) – odporúčam okrem povinnosti vedenia evidencie/dokumentácie aktuálneho stavu pridať aj povinnosť evidencie/zdokumentovania (hoci aj dočasných) zmien a vedenie histórie vykonaných zmien

Z1G (Fyzická bezpečnosť a bezpečnosť prostredia) – odporúčam

  • písm a) ako „zabezpečený priestor“ uvádzať nielen serverovňu, ale vôbec priestory, kde sa nachádzajú kľúčové sieťové prvky, inštalačné média, archívne kópie dát, a pod.

  • písm. d) namiesto „…prácu v zabezpečenom priestore“ odporúčam „…vstup a prácu v zabezpečenom priestore“

Z1H (Aktualizácia softvéru) – odporúčam opatrne používať formuláciu „bez zbytočného odkladu“ – môžu sa vyskytnúť situácie, kedy sa oplatí si najprv odskúšať, či aktualizáciou nedôjde k zmenám vo funkčnosti používaných aplikácií

Z1I (Monitorovanie a manažment bezpečnostných incidentov) – odporúčam, aby interný predpis riešil aj manažovanie prípadných výnimiek (napr. pre riadenie prístupov) pre prípady, kedy bude do riešenia incidentu zapojený aj externý subjekt (vrátane orgánu vedenia)

Z1K (Zálohovanie) – odporúčam namiesto „uzamykateľného priestoru“ použiť termín „zabezpečený priestor“ a prepojiť to tak s požiadavkami na fyzickú bezpečnosť a bezpečnosť prostredia (Z1G) – veď uzamykateľný priestor nerieši napr. ochranu pred požiarom a pod.

Z1M (Riadenie prístupu) – odporúčam

  • v tejto časti riešiť aj vstup do zabezpečených priestorov, nielen do ITVS

  • okrem práce na diaľku rátať aj s prípadmi, kedy vstup do systému legitímne potrebuje aj iný subjekt (OVM) – aj to si zaslúži sformulovanie nejakých zásad

  • okrem vedenia dokumentácie prístupových práv (písm. i) uložiť povinnosť priebežnej aktualizácie a udržiavanie histórie zmien

Z1N (Aktualizácia IKT) – odporúčam opatrne používať formuláciu „bez zbytočného odkladu“ – môžu sa vyskytnúť situácie, kedy sa oplatí si najprv odskúšať, či nasadením bezpečnostných záplat (písm. b) nedôjde k zmenám vo funkčnosti použitých aplikácií

Z1O (Účasť tretej strany) – odporúčam najmä v prípadeodôvodneného jednorazového povolenia prístupu tretej strane (napr. servisný zásah) povinnosť následnej zmeny hesiel použitých pri takomto prístupe

Na ďalšie úrovne som už nemal dosť síl, ale dúfam, že aspoň časť z vyššie uvedených poznámok sa bude dať primerane aplikovať aj tam.

4 Likes

Toto je veľmi trefné a podľa mňa kľúčové aj pre návrh architektúry systémov ako takých.

Prosim spisujte to a dajte to ako pripomienky. Ku vsetkym potom dame stretnutie a workshop

Čiže odpovede na moje otázky tu už nemám čakat?

Ešte pridám pár pripomienok. Vygenerovalo ich čítanie zvyšku Prílohy 2 (t.j. skupina Z2, Z3) ale majú aj širšiu platnosť

Personálna bezpečnosť – predpisuje sa testovanie vedomostí všetkých zamestnancov orgánu riadenia, čo samo osebe je pozoruhodné (fakt všetci, teda aj upratovačky, šoféri, informátori na vrátnici,…?), ale čo s tými, ktorí testom neprejdú? Prečo striktne požadovať testovanie, keď jeho neúspech nemá žiadne dôsledky?

Kontrolný mechanizmus informačnej bezpečnosti – držať si kvalifikovaného interného audítora na kontrolu informačnej bezpečnosti raz za rok (dosť pochybujem, že by to bolo častejšie) je luxus, ktorý si môžu dovoliť len dostatočne veľké „orgány riadenia“ – čo tie menšie? Formálne to splnia nekvalifikovaným audítorom, ale nie je to potom zbytočné?

Zaujímavé, že pre sieťovú bezpečnosť sa vyžaduje firewall, ale o (ne)možnosti používaní wifín, ktorými sa firewall dá pekne obchádzať, nie je v Z2F ani zmienka

Vyžaduje za zabezpečenie ochrany pracovných staníc alebo serverov, zabezpečenie notebookov nie je považované za dôležité?

Z2K (Zálohovanie) – požiadavky písm. d) akosi opomínajú hrozby neoprávneného prístupu ku kópii archívnej zálohy (živelné pohromy áno, prosté odcudzenie nie?)

Aktualizácia IKT – nie je potrebné okrem dát a programového vybavenia venovať vetu-dve aj osudu nahradzovaných zariadení?

Pre používateľské účty by sa okrem pravidiel pre heslá (zákaz zdieľania, príkaz ich zmeny) hodilo aj občas skontrolovať, či sa medzi účtami nenachádzajú aj dlhodobo neaktívne a po prešetrení ich nemilosrdne zlikvidovať/zablokovať

Zaujímavé, že v Z3G (Fyzická bezpečnosť a bezpečnosť prostredia) sa požaduje

  • strážna služba schopná byť na mieste incidentu do 3 minút od spustenia poplachu, ale nevyžaduje sa EZS či pravidelne obhliadky, teda to, čo je na spustenie poplachu potrebné…

  • zaistenie priestorov senzormi teploty, vlhkosti, dymu, prachu, … jednoduchšie riešenie, t.j. inštalácia klimatizácie (so záložnou jednotkou) sa vôbec neuvádza - nie je prijateľné?

Z3I (Monitorovanie a manažment bezpečnostných incidentov) – dovolím si upozorniť, že medzi bezpečnostné incidenty v realite patria aj také, ktoré nezachytia technické (automatizované) prvky, ktoré sú v tejto časti predpísané

2 Likes

Ja sa priznám že mám problém diskutovať o konkrétnych okruhoch opatrení, kým nie je dostatočne zrejmé, čoho všetkého sa majú týkať. A klasifikácia, tak ako je teraz uvedená, dobrú odpoveď zatiaľ nedáva.

To sa dá chápať. Mňa však fascinuje už aj to, čo je v tom návrhu vyhlášky napísané - nekonzistentnosť, strieľanie opatrení “od boku” bez zamyslenia sa nad tým, ako to bude fungovať v praxi, variabilná úroveň detailnosti, atď. Ak na tom fakt pracovalo “viac ako 15 ludi za CSIRT a bolo to pripomienkované minimalne dalsimi 10 ludmi …”, ako sme sa tu dozvedeli, tak potom mám vážne pochybnosti o organizácii práce na tom návrhu, resp. o tom, že si aspoň jeden z nich text dôkladne prečítal. Určite je chvályhodné, že sa to dalo sem na pripomienkovanie, ale autori si ešte predtým mali urobiť svoju domácu úlohu. Z mojej strany ďalšie pripomienky nebudú - a nie preto, že by už nebolo čo napísať…

teda aj top (politicky) management ? …

Urcite ano, ale az sa vratim na SR.

Vdaka za pripomienky cenim si to. Co sa tyka strielania od boku. Mali sme pocit, za nie je potrebne vysvetlovat co a pre co a ze kazdy hned porozumie. Pokusime sa to lepsie vysvetlit aby verejnost porozumela dokladne.
Opatrenia boli vybrate tak, aby po ich implementacii bola organizacia bezpecna ako celok. Tam kde je granularita nizka je potrebne aby specificky toto opatrenie bolo takto naimplementovane. Dovod je ze osetruje nejaky konkretny vektor utoku. Tam kde to nie je potrebne bol napisane vseobecnejsie opatrenie.

Keď mám pripomienkovať nejaký dokument, pozerám sa na to z pohľadu predpokladanej cieľovej skupiny … keď sa dokument nazve “Vyhláška Úradu”, tak je určený pre viac ako len ľudí z CSIRT, SD a ešte možno zopár ďalších …

Čo sa týka strieľania od boku - oficiálny dokument by mal mať niečo, čomu sa hovorí (hovorilo) “štábna kultúra” - podľa mňa to nie je len o vonkajších znakoch, ale o tom, že aj obsahovo je zostavený tak, že je tam poznateľná vnútorná logika, že je jasné ako jednotlivé časti na seba nadväzujú a spolu tak tvoria ucelený, logicky previazaný dokument. Ak výsledkom je chaotická zmes nejakých, hoci aj užitočných, opatrení a celkový kontext je potrebné si domýšľať, ťažko to nazvať inak ako že to vzniklo “strieľaním od boku”. Už aj z praktického hľadiska to nie je správny prístup - dokument je rozsiahly a jeho čítanie (možno aj pochopenie) je bez jasnej logickej štruktúry namáhavé. Aj ja, hoci o bezpečnosti čo-to viem, som sa musel nútiť ho celý prejsť - a čím ďalej tým povrchnejšie. Príliš neverím, že by sa v predpokladanej cieľovej skupine našiel niekto, kto by taký rozsiahly, neúplny a chaoticky zorganizovaný dokument dobrovoľne celý prečítal a mal pocit, že chápe čo autori vlastne chcú… Ak vám tým dokumentom ide len o odškrtnutie si uloženej úlohy, OK, ale to ste mohli hneď naznačiť, aby sme tu zbytočne neplytvali svojim časom.

Nie som si istý, či v prípade politického managementu ide o zamestnancov … ale špeciálne politickému managementu by som to testovanie doprial a do vyhlášky by som navrhol aj sankciu automatického odvolania z funkcie v prípade zlyhania v teste - už len pre tú srandu čo by tu nastala :slight_smile:

2 Likes

Klasifikacia - toto vadi v pripade, ze je myslienka naviazat controlsy na klasifikacnu uroven. Vyhlasku vsak vnimam niekde medzi baseline a navazovanim na klasifikaciu. V sucasnom stave sa obavam, ze kazdy si spravi klasifikaciu po svojom, co bude mat dva dopady:

  1. klasifikacie z dvoch organizacii nebudu vzajomne porovnatelne
  2. Security bude tlacene do nizsich stupnov, kedze vyssie klasifikacne stupne znamenaju vyssie naklady

Pokial bude vyhlaska postavena ako baseline, kde dodatocne opatrenia budu naviazane na klasifikaciu, tak toto nemusi vadit, kedze minimalne bod #2 bude pokryty a bezpecnostna uroven by sa mala zvysit aplikovanim baseline.

2 Likes

Bod c.2 je sice Dano logicky, ale v statnej sprave bohuzial moze nastavat aj presny opak. Napriek nakladom urcite skupiny budu tlacit stupen hore z dovodu napr. udrzania riesenia mimo gov cloud a mimo ich it kralovstva. Motivacie pri rozhodnutiach v nasom egov niekedy naozaj nie je mozne zrovnavat s raciom komercie.

2 Likes

Data, ktore su zivotne dolezite pre instituciu musia byt adekvatne chranene. Co sa tyka kvality a bezpecnosti dat je potrebne vyriesit zodpovednost za bezpecnost.

Jedinym raciom komercie je zisk, co nie je jednak udrzatelne a jednak aplikovatelne pre statnu spravu.

Ach. Toto je velmi zvlastny pohlad. Dovolim si tvrdit, ze public cloud tu bude aj davno potom ako skoncia nejake eurofondy. Predstava, ze v krutom konkurencnom prostredi kde bojuju giganti Google/Azure/Amazon neznamena reputacia nic a preferuju sa kratkodobe zisky je naozaj velke zjednodusenie toho ako biznis na celom svete funguje.

Teraz som nehovoril o cloudoch :slight_smile: NA to je separatne vlakno. Teraz som hovoril, ze mnoho sukromnych spolocnosti sa primarne pozera na zisk a viacmenej dufa, ze sa nic nestane. Preto hovorit o nejakom raciu je neprimerane

Jedna sa aj o velke spolocnosti. Viem to povedat z praxe aj sudneho znalca.
Co sa cloudov tyka, k tomu spracovavam materialy aj na zaklade mojej cesty v USA, kde v mnohych statoch je zakazane davat do cloudu vsetko kde mozu byt PII, citlive informacie (podla ich klasifikacnej schemy) ako aj data, kde su poziadavky na zvysenu ochranu. Mozeme si zobrat za priklad napriklad Nebrasku alebo Texas.

Urcite sa najde kopec prikladov ako sa to robit da aj neda. Skor ide o to ake je zadanie. A to je jasne definovane v schvalene strategii vladny cloud.

To nespochybnujem. Mojou ulohou(zadanim, preco vobec robim tuto pracu) je navrhnut, presadzovat a implementovat riesenie tak aby obcania sr si boli isty, ze ich data su v bezpeci. Ak niekto urobi manazerske rozhodnutie, ze akceptuje riziko, je to na nom a musi si potom samozrejme zan niest aj dosledky. Dokument priorita vladny cloud neriesi dostatocne bezpecnost, ta sa riesi prave v dokumente Priorita kyberneticka bezpecnost.

Btw, vsetkym dakujeme za pripomienky, vsetky dorucene pripomienky budu spracovane. V kratkom case posleme navrh terminov na slubeny workshop.