Bezpečnostný incident nie je bežný tiket. Okruh žiadateľov je menší, okruh riešiteľov je menší a „office manager práve videl v zozname všetkých tiketov tiket o vyšetrovaní phishingu" je niekedy sám osebe incidentom. GLPI nemá tlačidlo „classified mode", ale existujúce funkcie entít, profilov, kategórií a skupín sa dajú skombinovať do nastavenia dostatočne tesného aj pre ISO 27001 — za predpokladu, že to spravíte pred prvým reálnym incidentom, nie počas neho.
Začnite privátnou kategóriou
Najväčší únik nie je útočník — je to zvedavý agent prezerajúci si frontu. Otvorte Setup > Dropdowns > ITIL kategórie a vytvorte kategóriu pre bezpečnostné incidenty. Na formulári kategórie nastavte Viditeľné pre tikety na Áno a do poľa Obmedzené na skupiny pridajte explicitnú skupinu používateľov. Len členovia týchto skupín uvidia kategóriu v rozbaľovacom zozname pri vytváraní tiketu a len ich tikety sa im vynoria vo vyhľadávaní.
Môžete ísť ďalej cez podkategórie (napr. Bezpečnosť > Phishing, Bezpečnosť > Únik dát, Bezpečnosť > Kompromitácia účtu) — každú možno priradiť inému bezpečnostnému subtímu, ak vaša firma oddeľuje SOC od infraštruktúrnej bezpečnosti.
Obmedzte profil riešiteľa
Kategórie riadia, čo sa vytvára. Profily riadia, kto si to vie prečítať následne. Vytvorte profil Bezpečnostný analytik a nastavte Vidieť všetky tikety na Nie. Predvolený profil Technik má túto možnosť zvyčajne na Áno — čo znamená, že každý technik vidí každý tiket bez ohľadu na kategóriu. To je zlý predvolený stav pre bezpečnostnú prácu.
Priraďte profil Bezpečnostný analytik ľuďom, ktorí majú vyšetrovať. Uvidia len tikety, kde sú žiadateľom, riešiteľom alebo pozorovateľom. Skombinujte to s biznis pravidlom, ktoré automaticky priradí každý tiket s bezpečnostnou kategóriou bezpečnostnej skupine, a reťaz je uzavretá: bezpečnostné tikety existujú len vo frontoch bezpečnostných ľudí.
Skryte riešenie pred žiadateľom
Štandardne žiadateľ pri uzavretí tiketu prečíta celé pole riešenia. Pri bezpečnostnom vyšetrovaní to spravidla nie je to, čo chcete — neposielate používateľovi e-mail „zistili sme, že útok prišiel cez kompromitovaný účet praktikantky z marketingu". GLPI umožňuje označiť jednotlivé followupy ako privátne: followup je vidieť vnútri tiketu pre riešiteľov a pozorovateľov, ale nejde žiadateľovi do e-mailu a neukazuje sa na samoobslužnom portáli.
Vyškoľte analytikov: vyšetrovacie poznámky idú do privátnych followupov. Pole riešenia, ktoré žiadateľ uvidí, obsahuje verziu pre používateľa („Potvrdený phishing. Odporúčaná akcia: zmena hesla, zapnutie MFA"). Dva paralelné príbehy v jednom tikete — interný a externý.
Stíšte notifikačný engine na týchto tiketoch
Predvolené notifikácie obsahujú názov tiketu a telo popisu v e-maile. Ak je kategória citlivá („Bezpečnosť > Kompromitácia účtu CFO"), tento názov ide v čistom texte do nejakej schránky — vrátane, často, indexu Outlooku. Upravte notifikačnú šablónu pre bezpečnostné kategórie: posielajte e-mail len s číslom tiketu a odkazom. Príjemca sa musí prihlásiť do GLPI, aby videl zvyšok. Menej pohodlné, oveľa bezpečnejšie.
Pre skutočne citlivé prípady použite entity
Kategórie a profily pokryjú 95 % dôvernosti. Pre posledných 5 % — vyšetrovania na úrovni predstavenstva, interné HR-IT incidenty, podozrenia z insider aktivity — vytvorte samostatnú entitu. Samostatná entita v GLPI je vlastný rozsah: vlastné kategórie, vlastní používatelia, vlastná knowledge base, vlastný vyhľadávací index. Používateľ v nadradenej entite nevidí v citlivej dcérskej entite nič, pokiaľ tam nie je explicitne profilovaný. Je to ťažšie udržiavateľné než kategórie, ale pre prípady, kde aj samotná existencia tiketu je dôverná, je to jediná štruktúra, ktorá obstojí.
Auditujte, kto čo videl
GLPI loguje každé zobrazenie tiketu v záložke História na samotnom tikete. Po citlivom incidente je to stopa, ktorú audítor bude chcieť: ktorý používateľ, v ktorom čase, otvoril tento tiket. Z krabice to nie je formálny regulačný report, ale dáta tam sú. Exportujte ich pred uzavretím a priložte k post-incident review.