Pripomienky: Strategická priorita Bezpečnosť

Pripomienkovanie
1

V tejto téme preberme, čo by malo byť predmetom NKIVS v časti “Informačná a komunikačná bezpečnosť”.

Skúsme k tomu spraviť (na úrovni odrážok) zoznam tém / riešení. Následne by sa tieto veci mali objaviť aj v NKIVS.

Pripomienky k NKIVS by sme chceli v pondelok (15.2.2016) zosumarizovať, takže dovtedy diskutujme.

Pokladové dokumenty:

1 Like
2

dokument pouziva terminy “digitalny priestor” a “kyberneticky priestor” bez toho aby zadefinoval co to je. Podobne aj IB a KB.

dokument je niekedy prilis detailny napr “Zároveň sa odporúča zohľadniť aj iné všeobecné bezpečnostné požiadavky na web aplikácie, napr. poznámky vývojárov v kóde aplikácie, pravidelné implementovanie bezpečnostných „záplat“, indexovanie adresárov,”, raz “odporuca”, inde zase “budu povinne”, “je vhodne vykonat”, “musi byt vykonavane”…nie je mi jasne ci sa jedna o dokument strategicky, alebo to ma charakter studie, alebo z neho vyplyvaju konkretne ulohy, zasady…aky bude vlastne nextstep.

AD 2.1.1. "…aby nebola ohrozená ich dôvernosť a integrita. " doplnit “autentickost”

AD 3.1.2 "Na úrovni jednotlivých rezortov a organizácií budú zadefinované a obsadené samostatné role v oblasti informačnej a kybernetickej bezpečnosti podľa medzinárodných štandardov " tie role a útvary sú už vymenované na obr. 1, ráta sa s nejakými ďalšími ? akými ?

AD 3.1.2.1 “Definícia konkrétnych bezpečnostných požiadaviek a funkcií musí vychádzať najmä zo štandardu (Common Criteria) uvedeného v predchádzajúcej kapitole.” Toto je prve miesto kde sa CC spomina, v predchadzajucej kapitole som to nenasiel. Kazdy rezort / PO si bude musiet nastudovat CC? Preco nemoze vzniknut CCbased alebo ina metodika pre tento ucel, ktoru vytvori KIBVS ?

“To aké konkrétne bezpečnostné funkcie budú pre príslušnú aplikáciu požadované je plne v kompetencii samotných
obstarávateľov, ktorí by mali vychádzať najmä z analýzy rizík” kto, na zaklade coho a kedy takuto analyzu rizik spravi ?

“Pravidlá, politiky a požiadavky budú vytvárané na základe aktuálneho stavu vývoja IT a medzinárodne platných
a uznávaných noriem a pravidiel (ISO, NIST).” Tak potom preco sa uvadzaju konkretne pravidla aj v tomto dokumente ?

3.1 “…centrálnych systémov umožňujúcich riadenie informačnej bezpečnosti tak na centrálnej úrovni štátu,
ako na úrovni pripojených organizácií. Typickým príkladom je napríklad vytvorenie nástroja na centrálny monitoring
siete, potrebného tak pre riadenie prevádzky, ako aj pre monitoring z pohľadu ochrany kybernetického priestoru
krajiny.” versus “3.2.4.1.2.1 Systém riadenia informačnej bezpečnosti (ISMS” - raz sa pod systemom riadenia rozumeju nastroje a raz subor politik, roli, zasad, postupov, procesov a procedur v zmysle 27001/27002

…to takto dalej nejde, pripomienkovane tymto sposobom je naprd, neexistuje verzia vo formate, kde sa budu dat pisat pripomienky do textu ?

3

Najprv môj názor k tomu dokumentu strategickej priority:

  • Je tam rozpracované organizačné zabezpečenie a to najmä centrálne.
  • Kapitola 3.2.4 Biznis architektúra v skutočnosti iba opäť popisuje k organizačnému zabezpečeniu členenie agendy, z hľadiska riešení je skoro prázdna.
  • Kapitola 3.2.5 Aplikačná architektúra je tiež prázdna.
  • Potom nasleduje návrh projektov, ktoré sú všetky centrálne, všetky realizuje MF alebo NBÚ a ešte je tam z neznámych dôvodov prilepený projekt Govnet 2.0, ktorý zjavne patrí do iného dokumentu.
  • Ešte aj budovanie povedomia (awareness) je poňaté ako dodávka IS. Tu vidno úplne jasne zhubný pohľad na informatizáciu cez “IT projekty”.
  • Z projektov niektoré sa predsa venujú biznis+app. riešeniam, zaujímavé sú 4.4.6 SOC,CMR,SIEM, 4.4.7 IS ILP, 4.6.1 IS PKI, 4.6.2 IS AltA, 4.6.3 NTP - keďže však tieto veci nie sú nijako v príslušných architektonických kapitolách rozobraté, vyzerá to úplne náhodne
  • K viacerým veciam v dokumente nie je vôbec jasné čo, prečo a ako má byť spravené - napr. certifikácia/akreditácia (čoho? na akom podklade?), centrálny manažment mobilných zariadení (prečo? prečo nie napr. aj centrálny manažment prenosných médií?)
  • Chýba akékoľvek zhodnotenie a reflexia súčasného stavu, legislatívneho, koncepčného, faktického.

Celkovo to nie je architektúra IB, škoda.

4

Keďže existujúce dokumenty veľmi nepomohli, skúsme definovať, čo sú kľúčové koncepty v oblasti bezpečnosti, ktoré treba teraz riešiť.

  • riadenie bezpečnosti
    • zjednotiť dnes existujúce bezpečnostné požiadavky zo všetkých režimov - t.j. štd.ISVS, OOÚ, krit. infraštruktúra - okrem utajovaných skutočností - a vytvoriť jednotný prístup
    • zaviesť kategorizáciu podľa vyžadovaného stupňa bezpečnosti - na úrovni org / IS ?
      .
  • BCM
    • riešenie závislosti integrovaných systémov, a to aj následné, riešiť to aj legislatívne
    • systémovo riešiť výkon verejnej moci počas nedostupnosti IS (viď. zhrozenie právnikov v zákone o SlovLexe)
    • nové rozdelenie zodpovedností pre integrované, cloudové systémy (čo sa stane keď inštitúcia A nevie plniť povinnosti kvôli inštitúcii B?)
      .
  • identifikácia
  • jedna FO = jedna identita
  • identifikátor vs. OOÚ - univerzálne a iné identifikátory (ja som za zrušenie celého SIFO konceptu)
    .
  • autentifikácia
  • úrovne autentifikácie ku službám - prehodnotiť existujúce vyžadované, čo s našimi 4 levelmi (STORK) vs. eIDAS 3 levely
  • autentifikácia zahraničných subjektov - riešenie eIDAS
  • umožnenie rôznych foriem autentifikácie otvoreným spôsobom - federácia, úrovne
    .
  • autorizácia
  • iné autorizácie ako ZEP - de-facto sa to už všelikde používa, chcelo by to štandardizáciu
  • centrálna správa autorizácií - možnosť používateľa zvoliť metódu autorizácie, blokovať určité metódy autorizácie
  • ZEP -čo s ním ďalej
  • autorizácia pri G2G - jednotné pravidlá, kedy / v akej úrovni je vyžadovaná - napr. pri prenose údajov
    .
  • riadenie prístupu
  • laissez faire (vs. need-to-know?)
  • riadenie rolí, asi centrálne?
  • možnosť používateľa prehliadať kto z vs. ktoré moje údaje / kedy / na aký účel použil
    .
  • accounting / logovanie / uchovávanie
  • štandardizácia logov - minimálne biznis vrstva - centralizácia?
  • čo ďalej s MDUERZ
    .
  • iné
  • jednotné pravidlá pre bezpečnosť v Govnete
  • OpenAPI bezpečnostné požiadavky
  • čo aktívny dohľad nad aktivitami v mene usr? (podľa vzoru bánk)
  • centrálne podporné aplikácie pre inštitúcie - od NTP, až po SIEM
    .
  • podpora bezpečnosti u používateľov
  • vzdelávanie / awareness
  • podporné nástroje pre používateľa (ako overí či má bezpečné PC, spojenie, ako vie monitorovať čo sa deje)
  • možnosti limitácie zodpovednosti používateľa (dnes je kompletná zodpovednosť prenesená na používateľa)
1 Like
5

Az na tie francuzske otvorene okna, ktore by si podla mna zasluzili najprv diplomovku, potom pilotny projekt v nejakom slovenskom labaku / malej organizacii a potom mozno mozeme rozmyslat ci a co s tym :slight_smile: suhlasim. Ano ja viem ze inde to maju ale my sme na slovensku kde este nemame elementarne zaklady (organizacne ani technologicke na nieco take. Ale mozno by sa hodilo identifikovat prerekvizity na nieco take a benefity, daka studia, whatever.

Podla mna je este dolezita legislativna rovina. Raz sa tam spomina zakon o IB. Potom zakon o IB a KB. Ale leg zamer zakona o IB mame uz davno schvaleny. A rozpracovany je aj zakon o IB. Co s tym ? Od toho sa predsa bude odvijat napr. klasifikacia inf a ISVS.

Chyba aj riadenie rizik. Kazdy si necha spravit bprojekt ako sucast suvisiaceho ikt projektu, pre rizika (ne)prijme opatrenia a to je koniec rednorazovej akcie. Manazment identifikovanych rizik sa nerobi.

6

Konsolidovane pripomienky k NKIVS z celej platformy su tu: https://docs.google.com/document/d/1osKeaMejoENaCZT_7IoWS125riiBHz3OqiVsaFPTv_4/edit?usp=sharing