SZAKDOLGOZAT
Farkas Imre László
2011.
Budapesti Kommunikációs és Üzleti Főiskola
SZAKDOLGOZAT Az információbiztonság szervezésének kihívásai és lehetséges válaszok az informatikán túl
Belső konzulens neve:
Farkas Imre László
Dr. Kiss Ferenc
Gazdálkodási és menedzsment szak
Budapest 2011.
1. Bevezetés........................................................................................................................ 5 1.1.
Témaválasztás, a szakdolgozat célja....................................................................... 5
1.2.
Hipotézis ................................................................................................................. 6
2. Módszertani alapok ........................................................................................................ 8 2.1.
Az információbiztonság menedzselése ................................................................... 8
2.2.
Fontos kifejezések értelmezése............................................................................. 10
2.3.
Kísérlet az információvagyon meghatározására ................................................... 12
2.4.
A kontroll fogalmának definíciója ........................................................................ 14
3. Az információbiztonság jelenlegi kihívásai és azok lehetséges okainak elemzése ..... 17 3.1.
Áttekintés .............................................................................................................. 17
3.2.
Szervezeti széttagoltság ........................................................................................ 18
3.3.
Erőforráshiány ...................................................................................................... 19
3.4.
Reaktív működés................................................................................................... 19
3.5.
Széttagolt jelentési rendszerek.............................................................................. 19
3.6.
„Papírgyár” ........................................................................................................... 20
3.7.
Tudásciklusok ....................................................................................................... 20
3.8.
A veszélyérzet hiánya ........................................................................................... 22
3.9.
Elefántcsonttorony ................................................................................................ 23
3.10.
Másodlagos kontroll hiánya .............................................................................. 24
4. Analógiák
kutatása:
más
szakterületeken
elterjedten
alkalmazott
eljárások
feltérképezése ...................................................................................................................... 25 4.1.
Áttekintés .............................................................................................................. 25
4.2.
Közgazdasági vonatkozások ................................................................................. 25
4.3.
Analógiák a pénzügyi controlling területéről ....................................................... 25
4.4.
A Balanced Scorecard relevanciája ...................................................................... 28
4.5.
A folyamatszervezés fontossága ........................................................................... 28
4.6.
Tudásmenedzsment............................................................................................... 29
4.7.
Tömeges együttműködés ...................................................................................... 31
4.8.
A rendszerelmélet alkalmazása............................................................................. 32
4.9.
Marketing és PR, mint a biztonság építői ............................................................. 33
4.10.
Az ügyfélközpontúság kritikussága .................................................................. 35
4.11.
Szociológiai szempontok .................................................................................. 35
4.12.
Pszichológiai vonatkozások .............................................................................. 36
5. Szintézis: az információbiztonság új megközelítési lehetőségeinek elemzése ........... 38 5.1.
A problémák kiváltó okainak és lehetséges válaszoknak együttes elemzése ....... 38
5.2.
Az információbiztonság stratégiai megközelítése ................................................ 39
5.3.
A biztonság, mint üzleti funkció........................................................................... 41
5.4.
A biztonság, mint szolgáltatás .............................................................................. 46
5.5.
Hogyan adjuk el a biztonságot? ............................................................................ 48
5.6.
Hogyan (és miért) mérjük a biztonságot? ............................................................. 56
5.6.1.
Az eredeti Balanced Scorecard alkalmazása ................................................. 58
5.6.2.
Biztonsági szempontokból definiált mutatószámrendszer ............................ 59
6. Összefoglalás................................................................................................................ 61 7. Irodalomjegyzék........................................................................................................... 63 8. Mellékletek................................................................................................................... 67 8.1.
Az információbiztonsági szervezet eredményességének és elismertségének
felmérésére összeállított kérdőív ..................................................................................... 67 8.2.
COBIT érettségi modell........................................................................................ 68
8.3.
A BMIS modell elemeinek és azok kapcsolatának összefoglaló leírása .............. 71
Mottó: „Nem fedezhetünk fel új irányokat oly módon, hogy még jobban meresztjük szemünket a korábbi irányba.” – Edward De Bono
1. Bevezetés 1.1. Témaválasztás, a szakdolgozat célja A Budapesti Kommunikációs és Üzleti Főiskola Gazdálkodási és Menedzsment szakán Üzleti Kommunikáció szakirányon végzett tanulmányaimra nézve jelen dolgozat relevanciáját a BKF-en tanultak és tízéves informatikai és biztonság-szervezési tapasztalataim szintézise adja. A dolgozat fő célja kettős: kifejezetten annak elemzése, miként alkalmazhatóak a BKF-es tanulmányaim során megismertek jövőbeli szakmai munkám során – és ennek fordítottja: az informatikai ismeretekkel nem rendelkező kollégák és érdeklődők számára gondolati kapcsolatot teremteni saját szakterületükkel. Abban azonban biztos vagyok, hogy bármilyen előnyt csak sablonoktól mentes és nyitott gondolkodással kovácsolhatunk e gondolatmenetből, a feltárt módszerek sikeres alkalmazása pedig minden bizonnyal egyfajta kombinációt tesz szükségessé a bevett és az „új” módszerek között. Ez teszi számomra e témát a jelen szakdolgozatban való kifejtésre érdemesnek. Az információbiztonság (Information Security, IS) mint szakterület, alapvetően informatikai
gyökerekkel
rendelkezik,
ám
„hatóköre”
az
ezredforduló
tájékán
folyamatosan bővülni kezdett. Ahogy a technika egyre komplexebbé vált (és válik), illetve mára az informatikától való függés gyakorlatilag totális, a „teljes rendszer” egyéb összetevőinek menedzselése egyre fontosabbá vált. Ezen szakterületek például az információk osztályozása és átfogó védelme, a humán biztonság, az üzletmenet átfogó értelmezése és folytonosságának biztosítása, a biztonsági incidensek és katasztrófahelyzetek kezelése, illetve biztonsági rendszerünk folyamatos fejlesztése. A dolgozat kimondottan nem informatikai háttérrel közelíti meg az információbiztonság területét. Szakdolgozatom célja azon módszerek, diszciplínák feltérképezése, amelyek nem képezik a szűken vett informatikai vagy biztonságtechnikai terület részeit, és amelyeket a napi gyakorlatban nem, vagy csak érintőlegesen alkalmaznak az IS szakemberek. Célom e közeli vagy épp távolabbi társterületek illetve módszerek áttekintése, illetve azoknak az 5
információbiztonság szervezése során történő hasznosítási módjainak elemzése. Mindebből egy előremutató képet kívánok festeni az információbiztonság szervezési feladatairól – az általánosnál sokkal tágabb kontextusban és izgalmasabb felfogásban! Jelen dolgozatnak nem célja kimerítő módszertani elemzést adni az információbiztonsági szakterületről, különösen nem az informatika, fizikai biztonság illetve vagyonvédelem témakörére. Mindazonáltal a feltárt módszerek és összefüggések szándékom szerint a vagyonvédelem, humán erőforrás menedzsment, sőt egyéb üzleti illetve támogató terület szervezésében is hasznosnak bizonyulhatnak. E gondolatmenet végig vitele mindenképpen sablonoktól mentes gondolkodást igényel. Ezért jelen dolgozatban az információbiztonság szűkebben vett módszertani arzenálján túlmutató módszerek felderítésére alapvető módszerként alkalmazom az analógiák módszerét. E módszer lényege, hogy alapvetően múltbeli, vagy éppen más szakmabeli tapasztalatokra építve hasonlóságokat, párhuzamokat keresek az információbiztonság és egyéb szakterületek között. (Kiss, 2001.) A rugalmas gondolkodás elősegítése érdekében kutakodásom célját tehát a következő módon határoztam meg: Olyan, más területeken alkalmazott megoldások keresése, amelyek választ adnak az információbiztonság területén felmerülő problémákra, méghozzá a problémák és megoldások analóg volta miatt – és ezek segítségével az információbiztonsági szakterület hatékonyabbá és eredményesebbé tétele.
1.2. Hipotézis Mint sok más szakterület képviselői, az információbiztonsági terület szakemberei sokszor nem ismerik fel az egyéb diszciplínák által kínált módszerek jelentőségét, ezért azokat nem is alkalmazzák tevékenységük hatékonyabbá és eredményesebbé tételére. Ennek káros hatásai visszafogják az információbiztonsági és informatikai szervezetet, ennél fogva az üzleti folyamatoknak az informatika fejlődése által indukált optimalizálását, végső soron pedig magát az üzletet – nem beszélve a legalapvetőbb cél teljesüléséről: a biztonság elfogadható szintjének megteremtéséről. Meggyőződésem, hogy az információbiztonság szakterülete rengeteget tanulhat például az üzleti stratégiai tervezés, a rendszerelmélet, a folyamatszervezés, a pénzügyi controlling, a
6
pszichológia, a szociológia, a tudásmenedzsment és csoportmunka vagy a marketing és pr módszertani területeitől.
7
2. Módszertani alapok 2.1. Az információbiztonság menedzselése Az Információbiztonsági irányítási rendszer (Information Security Management System, ISMS) „az átfogó irányítási rendszernek az a része, amely – egy, a működési kockázatokat figyelembe vevő megközelítésen alapulva – kialakítja, bevezeti, működteti, figyeli, átvizsgálja, fenntartja és fejleszti az információvédelmet. […] Az irányítási rendszer magában foglalja a szervezeti felépítést, a szabályzatot, a tervezési tevékenységeket, a felelősségi köröket, a gyakorlatot, az eljárásokat, a folyamatokat és az erőforrásokat.” (MSZ ISO/IEC 27001:2006:22.) Az információbiztonság menedzselésének módja tehát egy adott szervezet stratégiai döntései közé tartozik, figyelembe véve a szervezet méretét, tevékenységét, szervezeti és technikai adottságait és nem utolsó sorban: céljait. Az IS, társterületekkel együttműködve, ám önmagában autonóm menedzsmenttel kell, hogy rendelkezzen, saját magára vonatkozó küldetéssel (mission), a jövőről alkotott elképzelésekkel (vision), stratégiai tervekkel, illetve a stratégia végrehajtását lehetővé tevő operatív tervekkel, illetve a stratégiához való folyamatos visszamérést lehetővé tevő mutatószám-rendszerrel. Az ISO 27001 szabvány által előírtak megvalósításához az ISO 27002 nyújt segítséget, amelyet a Közigazgatási Informatikai Bizottság is feldolgozott 25. sz. ajánlása keretein belül. Az alábbi felsorolás az MSZ ISO/IEC 27001:2006 szabvány alapján bemutatja az információbiztonság, mint szakterület felépítését. (A felsorolásban a szabvány angol verziójának saját fordítását használom fel.) •
Az
információbiztonsági
terület
belső
szabályozási,
folyamat-
és
felelősségrendszerének kialakítása, a kockázatokkal arányos védelem biztosítása •
Külső felekkel kapcsolatos kockázatok kezelése
•
Információs vagyon osztályozása és kezelése (adat, szoftver, hardver, hálózat, stb.)
•
Humán biztonság (intézkedések felvételkor és a munkaviszony megszűntetésekor, illetve folyamatos biztonsági tudatosítás)
•
Fizikai biztonság
8
•
Az informatikai üzemeltetés és a telekommunikáció biztonsága (technikai biztonsági intézkedések)
•
Jogosultságok kezelése (rendszerekhez, helyiségekhez, eszközökhöz, hálózathoz, stb. való hozzáférés)
•
Alkalmazás-fejlesztés és rendszer-beszerzés biztonsági követelményei
•
Biztonsági incidensek kezelése (feltárás, jelentés, eseményekből való tanulás)
•
Üzletmenet-folytonosság menedzselése (kiesések kezelése, helyettesítő eljárások kidolgozása, katasztrófa-elhárítás)
•
A jogszabályoknak, illetve belső utasításoknak való megfelelés biztosítása és auditálás (MSZ ISO/IEC 27001:2006)
Mindezen témakörök átfogó kezelése nem egyszerű feladat, ám az ISO 27001 szabvány egy olyan rendszert vázol fel, amelyben a terület komplex menedzselése kezelhetővé válik. Az információbiztonság, de maga az informatika is viszonylag fiatal iparágnak számítanak. Ennek egyik hátrányos folyománya, hogy a szakmai terminológia nem teljesen letisztult. Sőt, ahogy a terület „érik”, úgy lesznek komplexebbek mind saját magán belüli, mind az egyéb szakmákkal való kapcsolatrendszerei – fogalmi keretei tágulnak. Az e fejlődést lehetővé tevő terminológia is egyre bővül. Bár a témakörben az elmúlt tizenöt évben kiadott ISO szabványok és egyéb nemzetközi publikációk, ajánlások sokat javítottak ezen a hiányosságon, a (főleg) angolról magyarra történő fordítások során, az angol nyelven egészen egyértelmű jelentéssel bíró fogalmak és kifejezések ködössé váltak, sőt, egyes esetekben jelentésük is torzult. Emiatt a magyar szóhasználat esetenként nem egyértelmű, amely szakmai körökben tapasztalatom szerint rendszeres, kisebb-nagyobb vitákat eredményez, melyek a lényegi problémáktól eltávolodva, félreértésektől nehezített elméleti, értelmezésbeli fejtegetésekbe torkollanak. E probléma okán, bevezetésként, néhány alapkifejezés közti összefüggést, illetve különbséget emelek ki, olyan formában értelmezve azokat, ahogy jelen dolgozatban azokat alkalmazom.
9
2.2. Fontos kifejezések értelmezése A pontos fogalmazás érdekében fontos rendet tenni a következő alapfogalmak között. Alább néhány fontos fogalom jelen dolgozatban alkalmazott értelmezést adom meg. 1. „Adat: Az információ megjelenési formája, azaz a tények, elképzelések nem értelmezett, de értelmezhető közlési formája. (ITB, 1996:188.) 2. „Információ: Jelentéssel bíró szimbólumok összessége, amelyek jelentést hordozó adatokat tartalmaznak és olyan új ismeretet szolgáltatnak a megismerő számára, hogy ezáltal annak valamilyen bizonytalanságát megszűntetik és célirányos cselekvését kiváltják.” (ITB, 1996:197.) 3. „Információrendszer: Információk meghatározott célú, módszeres gyűjtésére, tárolására,
feldolgozására
(bevitelére,
módosítására,
rendszerezésére,
aggregálására) továbbítására, fogadására, megjelenítésére, megsemmisítésére stb. alkalmas rendszer. Ha ez a rendszer számítógéppel támogatott, akkor számítógépes információrendszerről (informatikai rendszerről) beszélünk.” (ITB, 1996:196:198.) 4. „Informatikai rendszer: A hardverek és szoftverek olyan kombinációjából álló rendszer, amit az adat-, illetve információ-feldolgozás különböző feladatainak teljesítésére alkalmazunk. Az informatikai rendszerek különleges tulajdonsága a szabad programozhatóság. Az informatikai rendszerek közé soroljuk tipikusan a »célszámítógépeket« és az »általános célú számítógépeket«.” (ITB, 1996:196.) 5. Információs rendszer: Az információrendszerek megjelölésére sokszor helytelenül alkalmazott kifejezés. Információs rendszernek nevezzük azokat a rendszereket, amelyek valamely témában tájékoztatást, eligazítást nyújtanak. Az informatika térnyerésével megjelentek a vezetői információs rendszerek, döntéstámogató rendszerek, áttekintő grafikus képernyők (dashboard-ok) is – az információs rendszer tehát az információ-rendszerek egy speciális fajtája. (Vasvári, 2009.). 6. Adatvédelem: Az Avtv.1 jogi keretek között határozza meg az adatvédelem fogalmát. Ennek értelmében az adatvédelem jogi fogalom, amely a személyes adatok kezelésének és védelmének körülményeit szabályozza. Ezért ez a fogalom
1
1992. évi LXIII. törvény a személyes adatok védelméről és a közérdekű adatok nyilvánosságáról
10
az információbiztonság fogalmának megjelölésére illetve annak szinonimájaként semmiképp nem alkalmazható. (Vasvári, 2006: 36.) 7. Informatikai biztonság, IT biztonság: „Az informatikai rendszerekben kezelt adatok, és az azt kezelő rendszer védelmét jelenti.” (Muha, 2010:139.) „Az informatikai biztonság az informatikai rendszer olyan – az érintett számára kielégítő mértékű – állapota, amelyben annak védelme az informatikai rendszerben kezelt adatok bizalmassága, sértetlensége és rendelkezésre állása, valamint a rendszer elemeinek sértetlensége és rendelkezésre állása szempontjából zárt, teljes körű, folytonos és a kockázatokkal arányos.” (Muha, 2010: 145.) 8. Információbiztonság: A 2.1. fejezetben részletesen ismertetett szakterület, amely az informatikai rendszereken „felülemelkedve”, tágabb kontextusban vizsgálja az információk bizalmasságát, sértetlenségét és rendelkezésre állását fenyegető tényezőket és az azokkal szemben hozható védelmi intézkedéseket. „Mivel angolul általában az információvédelemre, illetve az informatikai védelemre, sőt néha a kommunikációs, információs és más elektronikus rendszerek védelmére is az information security kifejezést használják, az egyes fordítások még inkább zavarossá teszik a képet. (A védelem és biztonság kifejezést egymás szinonimájaként használjuk, bár nem azonos a jelentésük.)” (Muha, 2010: 139.) Általánosan
fogalmazva
a
biztonság
a
védelmi
intézkedések
(védelem)
eredményeként előálló állapot, ahogy az informatikai biztonság meghatározásánál is szerepel. 9. Egyenszilárdság: „…egy teljes körű, zárt, folyamatos és kockázatokkal arányos védelmi rendszert egyenszilárdságúnak tekinthetünk, mert az intézkedések minden rendszerelemre nézve pontosan a kockázatokkal arányosak lesznek úgy, hogy közben minden releváns fenyegetés figyelembevételre került.” (ITB, 1996:17.) Kritikus biztonságszervezési alapelv, hiszen nincs értelme annak, hogy egy ponton aránytalanul erős védelmet alakítsunk ki, míg más ponton védelmi rendszerünk könnyebben áttörhető vagy egyszerűen megkerülhető!
11
2.3. Kísérlet az információvagyon meghatározására A Hpt.2 előírja, hogy „a pénzügyi intézménynél mindenkor rendelkezésre kell állnia: az adatgazda és a rendszergazda kijelölését tartalmazó okiratnak” – vagyis adatgazdát kell kinevezni. „A vezetésnek ki kell dolgoznia egy eljárást az adatok tulajdonosainak (adatgazda) és kezelőinek hivatalos kijelölésére vonatkozóan és gondoskodnia kell arról, hogy minden informatikai eszköznek (adatok és rendszerek) legyen egy kijelölt tulajdonosa (adatgazda), aki dönt az osztályozásról és hozzáférési jogosultsági szintekről.” (PSZÁF, 2007:9) Értelmezésem szerint – kölcsönvéve az Avtv. terminológiáját – az adatgazda az adatfeldolgozó (mint szervezet) megbízottja, aki annak nevében az adatfeldolgozással kapcsolatos tevékenységekért felel. E kitétel értelmezése és gyakorlati alkalmazása azonban a komplexebb szervezetek esetében gondot okoz. Ez valójában nem meglepő, hiszen „a támadás, illetve a védelem alapvető tárgya az adat, amely az információkat hordozza. A támadások azonban nem közvetlenül érik az adatokat, hanem az azokat "körülvevő" rendszerelemeken (pl. a hardver és/vagy szoftver elemeken, a környezeti infrastruktúrán) keresztül. […] Az adatot, mint a támadások alapvető célját a következő rendszerelemek veszik körül: •
az informatikai rendszer fizikai környezete és infrastruktúrája,
•
hardver rendszer,
•
szoftver rendszer,
•
kommunikációs, hálózati rendszerek
•
adathordozók,
•
dokumentumok és dokumentáció,
•
személyi környezet (külső és belső).” (ITB 12, 1996:15)
Ennél fogva magának az adatnak lehetséges bár „gazdát” kinevezni, ám akit egy ilyen okirattal – a fenti sajátosság figyelmen kívül hagyásával – egyszemélyes felelőssé tesznek az adat, ennél fogva az összes fent említett, kapcsolódó rendszerelem biztonságáért, szinte biztosan nem fogja tudni, hol kezdjen hozzá. A fenti rendszerelemek mindegyikének biztonsága egy-egy külön szakma!
2
1996. évi CXII. törvény a hitelintézetekről és a pénzügyi vállalkozásokról
12
Vegyük azonban sorban azokat a területeket, ahol a gyakorlati szempontokat figyelembe véve érdemes lehet – külön-külön – „gazdát” keresni! • Termékek, szolgáltatások • Folyamatok (elsődleges üzleti vagy támogató folyamatok is) • Szervezeti egységek • Alkalmazások • Hardverek és operációs rendszerek (rendszerek) • Informatikai és kommunikációs infrastruktúra • Jogosultságok (informatikai szerepkörök) • Adathordozók (elektronikus és papír) • Helyiség (létesítmény) A jogszabályokban foglalt adatvédelmi és biztonsági követelmények komplex értelmezése elengedhetetlen a biztonság szervezése során, hiszen azonosítanunk kell a védelem tárgyát. Az egymást átfedő jogi fogalmak és adatkörök megnehezítik az átfogó szervezést, miután szinte minden, ide vágó jogszabály betartásáért más-más szervezet felel. A bankok, vagy akár a telekommunikációs cégek esetében is, a komplex jogi környezet az adatkörök meghatározásánál is érzékelhető. További, alapvető információbiztonsági feladatunk, ebből kiindulva, az adatok osztályozási rendszerének kialakítása, és ennek alapján a minimum védelmi szintek meghatározása osztályonként – ez a kockázatarányos védelem alapeleme! Az információbiztonság más területeihez hasonlóan adatok osztályozására és védelmére vonatkozóan például a korábban említett ISO 27001 és 27002 szabványok illetve a KIB. 25. sz. ajánlása3 ad útmutatást. Értelmezésem szerint az adatosztályozás egyfajta kockázatelemzés, így a strukturált kockázatelemzési módszerek, mint a CRAMM4, módszertanilag
kiválóan
alkalmazhatóak
az
adatosztályozás
keretrendszerének
kialakításakor.
3
A Közigazgatási Informatikai Bizottság 25. számú Ajánlása, amely az ISO 27002 szabványon alapszik (KIB, 2008.)
4
CRAMM (CCTA Risk Analysis and Management Method) - Az Egyesült Királyság Központi Informatikai és Telekommunuikációs
Ügynöksége által alkalmazott kockázatelemzési módszertan (CCTA - Central Computing and Telecommunications Agency) (CCTA, 1992, idézi ITB, 1994.)
13
2.4. A kontroll fogalmának definíciója A nem kívánt események bekövetkezése ellen védelmi intézkedéseket vezetünk be. Szakterületenként más-más kifejezést preferálnak; a gyakorlatban biztonsággal foglalkozó szakemberek védelmi intézkedésnek, a kockázatkezelők ellenintézkedésnek, az auditorok kontrollnak nevezik – ugyanazt a tevékenységet, melynek lényege nem más, mint a nem kívánt események ellenében hatni. Jelen dolgozatban a „kontroll” kifejezés alatt nem „ellenőrzést” értek, hanem „biztonsági intézkedést”! Bárki, aki egy munkafolyamat során annak érdekében cselekszik, hogy ne történjen nem kívánt esemény, e terminológia szerint „kontrollt” hajt végre. Az Information Systems Audit and Control Association (ISACA) a kontroll fogalmát a következő módon határozta meg: ”Az olyan irányelvek, szabályzatok, eljárások, gyakorlatok és szervezeti struktúrák összessége, melyeket arra hoztak létre, hogy ésszerű bizonyosságot adjanak arra, hogy az üzleti célkitűzések elérhetők, a nemkívánatos események megelőzhetők illetve felismerhetők, és helyesbíthetők.” (ISACA, 2007.) Alább a kontroll-intézkedéseknek kétfajta, legelterjedtebben alkalmazott, és véleményem szerint legcélravezetőbb taxonómiáját fejtem ki. A kontrollok legalapvetőbb megkülönböztetése azoknak a nem kívánt eseményekhez való viszonyán, illetve a kontrollcélnak magának a megfogalmazásán alapszik. Alapvetően háromféle csoportot különböztetünk meg: megelőző, észlelő és helyesbítő, vagyis preventív, detektív és korrektív, ám ezeket a különböző módszertanok továbbiakra bontották. Az alábbiakban a kontrolltevékenységek öt szintjét mutatom be.
A
kontrolltevékenységek efféle osztályozása segít azok priorizálásában. A káros eseményeket leginkább megelőzni akarjuk, ha ez nem kifizetődő, akkor legalább értesülni szeretnénk azok bekövetkeztéről, illetve, ha az esemény megtörtént és értesültünk róla, akkor az okozott kárt csökkenteni, illetve helyreállítani igyekszünk. Az információbiztonsági kontrollok hatásmechanizmus szerinti tipizálását a legátfogóbban a COBIT 4.1 illetve a MEHARI 2010 módszertanok írják le. E források elemzésének és ötvözésének eredményeképpen az alábbi taxonómiát állítottam fel: • Megelőző (preventív): az esemény bekövetkeztének teljes mértékben való megakadályozását célzó intézkedés, amennyiben kifizetődő lenne, minden esetben megelőző kontrollt használnánk. Pl.: a jelszavas védelem célja megelőzni, hogy illetéktelen személyek érjék el az adott rendszert.
14
• Elriasztó (deterrent, dissuasive): Bár nem biztosítja a megelőzést, a nem kívánt esemény bekövetkezésének valószínűségét csökkenti azáltal, hogy a támadó motivációját csökkenti. Pl.: Ha kihirdetjük, hogy minden számítógépes aktivitást monitorozunk, akkor magának az intézkedés bejelentésének tényével, bár meg nem előzzük a visszaéléseket, de jó eséllyel csökkenthetjük azok számát. • Felismerő (detective): Lehetővé teszi, hogy megfelelő gyorsasággal értesüljünk a nem kívánt eseményről, annak érdekében, hogy annak hatását csökkentsük és helyreállítsuk a működést. Pl.: egy ellenőrző összeg egy pénzügyi lista elektronikus átvitele során lehetővé teszi, hogy annak megérkezésekor az esetleges hamisítást vagy rendszerhibát észleljük. • Hatáscsökkentő (mitigating, palliative): Az esemény bekövetkeztekor fellépő negatív hatást csökkenti. Pl.: a biztonsági mentések csökkentik egy bekövetkezett rendszerhiba hatását azzal, hogy rendelkezésünkre áll az adatnak egy korábbi verziója. • Javító, helyreállító (corrective, recuperative): Az eredeti állapot visszaállítását célzó intézkedések. Ezeket is előre meg kell tervezni, sőt erre különös figyelmet kell fordítani, hiszen ahogy az 5.5. fejezetben tárgyalom, a veszteségesemények bekövetkeztének valószínűségét illetve káros hatását hajlamosak vagyunk alábecsülni. Fontos azonban, hogy maguk a helyreállító intézkedések ettől még nem lesznek preventív jellegűek, hiszen az eseményeket nem előzik meg. (IT Governance Institute, 2007.), (Club de la Sécurité de l’ Information Français, 2010.) A kontrolltevékenység „szintjét” tekintve azon intézkedések, melyek közvetlenül csökkentik egy-egy veszélyforrás kockázatát első szintű kontrollnak számítanak. Ezek gyakorlatilag magának a termelő vagy támogató illetve biztonsági folyamatnak a lépései, és végrehajtásukért célszerűen az adott folyamat szereplői felelnek. Annak érdekében, hogy biztonsági folyamataink és eljárásaink működéséről folyamatosan megbizonyosodhassunk, monitorozásra, felülvizsgálatra van szükség; ezt az ún. második szintű kontrollokkal érjük el. A második szintű kontroll elvégzésével bizonyosodunk meg az első szintű, közvetlen kontrollok (kontroll tevékenységek) működéséről és eredményességéről. Például első szintű kontrollnak számít, amikor egy tevékenységet jegyzőkönyveznek, vagy egy vezető jóváhagyja beosztottja hozzáférését egy adott informatikai rendszerhez. Amikor viszont megbizonyosodunk arról, hogy a dolgozó
15
jogosultsága élesítés előtt valóban jóváhagyásra került a megfelelő személy(ek) által, vagy arról, hogy jelen pillanatban is valós üzleti igényen alapszik, ezeket definiáljuk második szintű kontrollnak. Tipikusan a második szintű kontrollok során gyűjtött, a működést és eredményességet relevánsan jellemző és számszerűsíthető információk képezik az alapját a későbbiekben is tárgyalt metrikák és stratégiai mérőszámok rendszerének. Mindemellett definiálhatunk harmadik szintű kontrollt is, amely általában (ha a szervezetben létezik ilyen) a belső ellenőrzés, illetve a SOX5 és hasonló kontrollkeretrendszereknek való megfelelésért felelős szervezet feladata. A harmadik szintű kontroll lényege mind az első, mind a második szintű kontrollok létezésének, helyénvalóságának, dokumentáltságának és nem utolsó sorban valós végrehajtásának, működésének biztosítása. A SOX és egyéb audit terminológia alapján a létezés, helyénvalóság és dokumentáltság biztosítása (vizsgálata) az ún. „test of design” (TOD). A valós működés és végrehajtás vizsgálata a „test of effectiveness” (TOE). (IT Governance Institute, 2006.)
5
Sarbanes–Oxley Act of 2002 – Az amerikai tőzsdén jelen lévő vállalatok belső kontrollkörnyezetének
megerősítését célzó törvény
16
3. Az információbiztonság jelenlegi kihívásai és azok lehetséges okainak elemzése 3.1. Áttekintés Az információbiztonság, mint szakma az ezredforduló után, az informatika fejlődésével párhuzamosan rohamos fejlődésen ment keresztül. Mindazonáltal elérve egy bizonyos érettségi szintet, szembekerült a szervezet más területeivel való együttműködés kihívásaival. Az IT és az információbiztonság már nem az alagsorban rejtőző, teljes titokban működő részleg, ellenkezőleg: a cég folyamatainak integráns része. Az üzleti döntéshozók mindennapjait kitöltő problémák szignifikáns hányada valamilyen formában informatikai és információbiztonsági témákat érint – az üzleti környezet változásainak követése IT változást tesz szükségessé, és fordítva: IT fejlesztéssel üzleti előnyökre tehetünk szert. Ugyanez igaz az információbiztonságra is! A fenti folyamat következményeként az információbiztonsági szakember újfajta kihívásokkal találja magát szembe: nem elég a tűzfal konfigurációját beállítani, és ismerni az egyes informatikai platformok legújabb sérülékenységeit, hanem érteni kell például a kockázatelemzés és –menedzsment módszereihez, a megtérülési számításokhoz vagy a jogszabályi megfelelés témaköréhez is, ismerni kell a szervezet alapvető értékeit, céljait és működését, és nem utolsó sorban képesnek kell lenni a vezetők nyelvén kommunikálni! Sok esetben, amikor az információbiztonság eléri a fenti állapotot, a területért felelő szakember – annak ellenére, hogy ő legjobb tudomása szerint mindent megtett – azt veszi észre, hogy például a felhasználók továbbra is felírják jelszavaikat a billentyű alatt elrejtett cetlire. Emellett az alkalmazás-fejlesztők elfogadhatatlan minőségű és biztonsági szintű kódot szállítanak, szervezeti vezetők nincsenek biztonsági felelősségük tudatában, a felső vezetés pedig egész egyszerűen nem érzi, hogy az információbiztonság bármilyen értéket adna hozzá a szervezet működéséhez. A következőkben e problémák mögött megbújó okokat próbálom feltárni, amelyek hátráltatják
vagy
meggátolják
az
információbiztonsági
17
szakterületnek,
illetve
szakembereknek a szervezet folyamataiban, illetve a vezetőkkel folytatott párbeszédben való érvényesülését – adott esetben magának a párbeszédnek a kialakulását. A problémák általam vélt fő okainak felsorolásával célom azok megoldásának első lépése: a felismerés.
3.2. Szervezeti széttagoltság Az Információbiztonsági csoport ideális esetben szervezetileg független azon területektől, amelyek számára követelményeket definiál, illetve amelyek fölött kontrollfunkciót lát el. Ez a gyakorlatban azt jelenti, hogy az információbiztonsági vezető vagy közvetlenül a szervezet első emberének (vezérigazgató, stb.), vagy legalábbis az egyik olyan felsővezetőnek jelent, aki viszonylag jól elkülönül magától a szervezettől, mint például a jogi igazgató, vagy biztonsági igazgató, ha ilyen a szervezetben van. A fentiek az információbiztonsági vezető feladataiból és felelősségi köréből adódnak. (Muha, 2008:56.) Azonban sok esetben az információbiztonságért felelős vezető, vagy szakember egy másik szervezetnek része, mint például az Informatika (IT). Ez nem szerencsés, mivel érdekellentét léphet fel, amikor az IT-n belüli biztonsági problémákról van szó. „A védelmi intézkedések rendeltetésszerű ellátása ütközhet az informatikai, vagy egyéb vállalati érdekekkel, és ebben az esetben nem érhető el a biztonsági cél.” (Vasvári, 2005.) Egy másik ilyenfajta probléma, amikor az információbiztonság, a fizikai biztonság, a jogszabályi megfelelésért felelős osztály, illetve a bankok esetében a csalások kivizsgálásáért felelős osztály más-más szervezeti egységek részei – ilyenkor a közös célok elérése érdekében szükséges kommunikáció és koordináció igen nehézkes, illetve a szervezeti silókban való gondolkodás és működés miatt nem is valósul meg. Sőt, egyes esetekben az egymásra konkurensként tekintő biztonsági szervezetekben a szándék sincs meg az együttműködésre. (Vasvári, 2005.) (Collette – Gentile – Gentile, 2009:144.) A stratégiai információbiztonság egyik legfontosabb alapköve a holisztikus és rendszerben való gondolkodás. A silókban működő és gondolkodó kontrollszervezetek valójában saját magukat korlátozzák ennek elérésében. Ez a természetes evolúcióval kifejlődött, különböző folyamatok egyvelegében és az ad-hoc problémákra adott, szétszórt megoldásokban mutatkozik meg. (Harries-Harrison, 2008.)
18
3.3. Erőforráshiány Egy jól felépített információbiztonsági rendszer kialakítása megfelelő számú, jól képzett és motivált szakember közreműködését teszi szükségessé. Abban az esetben, ha valamilyen oknál fogva nem áll rendelkezésünkre elegendő idő, illetve elegendő számú szakember, szinte belekényszerülünk a következő fejezetben tárgyalt reaktív működésbe. Ez a probléma nem különbözik attól a kihívástól, amellyel bármely más szakterület képviselői küzdenek – az erőforráshiányt valójában adottságként könyvelhetjük el, így annál fontosabb, hogy rendszeresen kitekintsünk a mindennapi munka során tényleges megoldások helyett alkalmazott gyorssegélyek és köréből! Jól ismert szervezeti sérülékenység a kulcsember esete, amikor egy kritikus szakmai területért vagy munkafolyamatért egyetlen ember felel, ráadásul a releváns szakmai tudás az illető fejében van, nincs kodifikálva. „A kulcsszakértők kiesése a rendszer kiemelt megbízható működési szintű üzemeltetésében komoly gondot tud okozni, pótlásuk külső forrásból általában nehezen megoldható.” (ITB 12, 1996: 94.) Ennek a helyzetnek a valódi kockázata általában akkor érződik, amikor a kulcsember valóban kiesik és pótlására van szükség, illetve amikor csalás történik, amelynek elkövetője vagy résztvevője belső ember.
3.4. Reaktív működés A vélt vagy valós erőforráshiány, és az azzal járó motivációcsökkenés folyamatos „tűzoltáshoz” vezet – csak arra jut időnk, ami már a körmünkre ég. Ez ellehetetleníti bármilyen stratégia kidolgozását. Ennek az állapotnak tipikus tünete, amikor szinte csak az auditokra és az anyavállalat (ha létezik) jelentéskészítési követelményeire reagálunk, saját kezdeményezésekre nem futja erőnkből.
3.5. Széttagolt jelentési rendszerek Egy nagy cégnél, különösen, ha multinacionális cégről, vagy annak leányvállalatáról beszélünk, az információbiztonságért felelős szervezet többfelé kényszerül jelentéseket adni: az anyacég informatikai, biztonsági, kockázatkezelési szervezete, a helyi jogszabályi megfelelésért felelős szervezet, a helyi kockázatkezelésért felelős szervezet – mind a saját formátumában és időzítésével igényli a számára releváns kontrollok állapotának
19
lejelentését. Emellett válaszolnunk kell a különböző audit megkeresésekre, és nem utolsó sorban saját működésünket is össze kell hangolni a társszervezetekével. Ez gyakorlatilag felesleges plusz munkának tűnik, ráadásul ugyanazt az információt akár többször is át kell adnunk a különböző igényekre válaszul – ez többszörös munkát jelent. Ebben az állapotban a jelentések csak azért készülnek, hogy kielégítsük azok igénylőit, és ritkán használjuk fel ezeket konszolidáltan az információbiztonsági terület működésének stratégiai tervezéséhez.
3.6. „Papírgyár” Tipikus eset, amikor egy adott pillanatban, az akkori legjobb gyakorlat szerint megalkotott utasítás, illetve folyamat vagy sablon eleinte használatban van, ám ahogy az idők során tudásunk a témáról növekszik, és esetleg a felelős személyek is lecserélődnek, az utasítás, eredeti formájában már nem olyan jól használható. Ekkor, annak revíziója helyett kialakulnak a „gyakorlatban jobban használható”, dokumentált és jóváhagyott folyamattól eltérő módszerek, és eszközök. Ha egy-két évig nem vagyunk figyelemmel folyamataink és utasításaink frissítésére, egyszerűen elavulnak, és a gyakorlat eltávolodik tőlük. Ennek, azon túl, hogy egy audit során „magas labdának” számítanak, további hátránya, hogy amennyiben valóban személycserék vannak, a gyakorlati tapasztalat, amelyet ideális esetben a dokumentált folyamatunk tartalmaz, elveszhet, hiszen csak a fejekben van jelen. Ennek következménye, többek között, a következő fejezetben tárgyalt „tudásciklusok” kialakulása.
3.7. Tudásciklusok Az általam tapasztalt problémát a következőképpen írnám le. Az éppen aktuális kihívásokra tekintve sokáig hajlamos voltam azt hinni, hogy az adott szervezet egész egyszerűen „itt tart” fejlődésének útján. Vagyis, ha hiányzott például egy incidenskezelési folyamat, vagy a jogosultság-kezelésben voltak alapvető hiányosságok, akkor azt gondoltam, hogy ezek a problémák az adott szervezetben akkor merülnek fel először – ami jogos feltételezésnek tűnt. A probléma kiváltó okát akkor ismertem fel, amikor lehetőségem nyílt átnézni adott vállalatok több, egymást követő IS vezetőjének azon terveit és első lépéseit, amelyeket akkor készítettek, amikor átvették a terület vezetését. Ekkor ugyanis gőzerővel készülnek 20
az átfogó tervek arra nézve, hogy mely fő területeken szükséges javítani, és megtörténik a főbb problémák azonosítása. Azonban legtöbbször ezek a 4.6. fejezetben említett „szakmai” területekre korlátozódnak, és a működés átfogó problémáit csak tüneti kezelésben részesítik. Amellett, hogy több fontos területen kerülnek bevezetésre új megoldások, sok esetben a régi megközelítéseket szinte teljesen elvetik – a problémák egyik fő oka nem kerül napvilágra. Azt tapasztaltam, hogy hat-tízéves távlatból visszatekintve rengeteg a visszatérő elem mind a problémák, mind az azokra adott megoldások terén, például: • Gap-analízis (összehasonlítás) készítése valamely szabvány, vagy éppen az anyacég szabályzatai szerint • Néhány kritikus (sziget-) megoldás stabilizálása/konszolidálása • Az információbiztonsági folyamatok formalizálása • Auditok során talált hiányosságok pótlása Adott esetben 2-4 IS vezető is váltotta egymást egy ilyen időtávban, szerencsétlenebb esetben a csapat fontosabb tagjai is azonos időszakban hagyták el a céget. Ilyen esetekben pontosan látszik, hogy a váltások tájékán valami történik. Az egyébként hasonló képzettségű, frissen kinevezett szakemberek természetesen nagyon hasonló problémákat fedeznek fel – azonban átlag 3 évenként újra és újra! A hiányosságok annál átfogóbbak, minél nagyobb a változás csapat összetételében. Az IS folyamatok és kontrollok ilyen esetben látszólagos és valódi érettségének viszonyát a COBIT érettségi modelljét6 alapul véve, időben az alábbihoz hasonló görbével írhatjuk le:
6
Lásd: 2. melléklet
21
Forrás: saját megfigyelések elemzése 1. ábra: A tudásciklusok és a látszólagos és valós folyamatérettség viszonya
Vagyis az IS szervezet felejt! Ez a tünet arra utal, hogy az IS szabályok és folyamatok nem kellően kerülnek kodifikálásra, nem épülnek be magának a szervezetnek a működésébe – és nem csak az IS, hanem kimondottan a teljes szervezet működésébe. Ehelyett néhány kulcsember működteti őket, akiknek távoztával a hiányos dokumentáltság és a nem megfelelő tudástranszfer következtében a „bevett szokások” kihalnak. Az IS szervezetnek 2-3 éves ciklusokban „újra kell tanulni” ugyanazt – sőt még többet, hiszen a világ nem áll meg. Így hasonló ciklusokban újra és újra feltűnnek ugyanazok a kezdeményezések, majd ismét elhalnak, legalábbis visszafejlődnek, miután nem sikerül azokat a gyakorlati működésbe maradandóan beépíteni.
3.8. A veszélyérzet hiánya A közmondás szerint „A bölcs ember mások hibájából tanul.” Mondhatnánk úgy is, hogy „A bölcs szervezet más szervezetek hibájából tanul.” Sok esetben viszont – akár az egyének – a szervezetek sem viselkednek bölcsen, és egészen addig nem változtatnak kockázatos tevékenységükön, amíg valamilyen konkrét veszteség beruházásra nem készteti őket. Hasonló eset a hamis biztonságérzet, amikor is a vezetők úgy gondolják, hogy bevezetett intézkedéseik megfelelő, egyenszilárd védelmet biztosítanak, és a vizsgálatok során talált biztonsági hibákat „sértésként” fogadják. Úgy tűnik, mintha a vezetés azt gondolná: „Nálunk olyasmi sosem fordulhat elő.” (Vasvári, 2005.) Lehetséges, hogy a döntéshozók nincsenek kellőképpen tájékoztatva a kockázatokat illetően?
22
3.9. Elefántcsonttorony Az alábbiakban kétféle szemszögből írom le ugyanazt a helyzetet. A második leírásban olvashatóak a problémák, amelyek az egyesben – amely egy másik felfogást tükröz – nem szerepelnek. 1. Az információbiztonsági szervezet legjobb szakmai tudása szerint megírja a biztonsági szabályzatokat, azokat a vállalat intranetes dokumentumkezelő rendszerében publikálja. Az informatikusok és a felhasználók napi szinten több kérdéssel fordulnak az információbiztonsági szakemberekhez, akik szintén legjobb tudásuk szerint megválaszolják azokat. Sajnos ez rengeteg erőforrást emészt fel. A vállalat belső ellenőrzése és a vállalat felügyeleti szerve (pl. a Pénzügyi Szervezetek Állami Felügyelete (PSZÁF), de ez szektoronként más) kb. féléves gyakorisággal problémákat talál, amelyeket szintén kb. féléves, esetleg éves határidőkkel a biztonsági szervezet „megold”, de esetleg csak egyszeri akcióval „letud”. Hol a hiba a képen? 2. Az információbiztonság nem folytat részletekbe menő egyeztetést azokkal a (pl. informatikus) szakemberekkel, akiknek az utasításokat nap mint nap használniuk és betartaniuk kellene. Az utasítások nem a napi gyakorlatban betartható, konkrét követelményeket tartalmaznak. Az érintettek sokszor nincsenek tisztában a rájuk vonatkozó követelményekkel. Ezen kívül, mivel nem vagy nagyon nehezen lehet ésszerűen betartani a követelményeket, azokat ignorálják. Ezt megtehetik, hiszen a biztonsági szervezet adott esetben nem hajt végre valós másodszintű kontrollokat, és nem képes megbizonyosodni arról, hogy követelményeit valóban betartják. Amennyiben mégis előkerül egy-egy odavágó követelmény a napi munka során (fejlesztés, rendszerbeállítás), annak nem egyértelmű volta miatt készítőjét – az információbiztonsági szakembert – kell megkeresni magyarázatért, rosszabb esetben döntésért. Ebben az esetben, bár auditkor az szabályzatokat elolvassák, és az esetleges részletekbe menő, szubsztantív teszteléskor sikerül is némi bizonyítékot adni a kontrollok működésére, általában láthatóak a hiányosságok. Így
23
egyre átfogóbb és egyben részletesebb audit megállapítások születnek, melyeket egyre komolyabb erőfeszítés megoldani. (Harries-Harrison, 2008.)
3.10. Másodlagos kontroll hiánya A kontroll-szemlélet hiányának általános tünete, amikor kizárólag a belső ellenőrzési osztályra hagyjuk a biztonsági követelmények teljesülésének ellenőrzését. Az auditor a működés bizonyítékait keresi, és általános kontroll-szemléletet alkalmaz. Csakhogy audit nélkül is felelősségünk, hogy megbizonyosodjunk a szakterületünkön – általunk – definiált kontrollok betartásáról! Ez többek között azért fontos, hogy a visszajelzés alapján, tervezett módon fejleszteni tudjuk biztonsági rendszerünket, és ne csak az auditok és egyéb felmérések, vizsgálatok megállapításaira reagáljunk.
24
4. Analógiák kutatása: más szakterületeken elterjedten alkalmazott eljárások feltérképezése 4.1. Áttekintés Jelen fejezet célja az ezután következő fejezetben foglalt, konkrét módszertani elemzések további megalapozásaként, a továbbiakban felhasznált analógiák rövid bemutatása. Előzetes elemzéseim eredményeit felhasználva, az analóg módszerek bemutatásának részét képezi egy rövid elemzés azok információbiztonsági relevanciáját illetően.
4.2. Közgazdasági vonatkozások Minden biztonsági intézkedést annak érdekében hoz egy szervezet, hogy működését eredményesen, a kockázatok elviselhető szinten tartásával (a kockázatokkal arányos védelem megvalósításával) fenntarthassa. Ezért a biztonsági szakmának elengedhetetlen, hogy alapvető ismeretekkel rendelkezzen a közgazdaságtan elmélete és gyakorlata tekintetében. A gazdasági szereplők (illetve általában a szervezetek), illetve azok vezetőinek döntési mechanizmusainak, illetve átfogó céljainak ismerete elengedhetetlen a biztonság megteremtésére tett intézkedések felelőseinek. A megtérülési számítások és egyéb racionális érvrendszerek a kockázatmenedzsment területének integráns részei. Mindez persze azzal a feltevéssel, hogy a célszervezet racionálisan hozza meg döntéseit – a lehetőségelmélet, például a pszichológia és a gazdaságtudomány ötvözésével radikálisan megváltoztathatja ezt a nézőpontot, és betekintést enged az információbiztonság „eladásának” nehézségeinek okaiba. Az üzleti döntések racionalitásával és a biztonság által termelt (termelhető) értékek témakörével az 5.5. fejezetben foglalkozom.
4.3. Analógiák a pénzügyi controlling területéről „A controllingkoncepció a vállalati gyakorlatban az elmúlt 20 évben folyamatosan fejlődött, és olyan vezetési funkcióvá vált, amelyről már egyetlen vállalkozás sem mondhat le. Ennek ellenére azt tapasztaljuk, hogy mind a gyakorlatban, mind az elméletben még 25
mindig jelentős véleménykülönbségek élnek a controlling fogalmáról. Gyakran követik el azt a hibát, hogy azonosítják a controlling és a kontrollálás (vagyis ellenőrzés7) fogalmát. A controlling azonban több ennél: olyan, funkciókat átfogó irányítási eszköz, amelynek a feladata a tervezés, az ellenőrzés és az információellátás összehangolása annak érdekében, hogy a vállalat elérje a kitűzött eredménycélt. A controller bizonyos tekintetben a vállalkozás »gazdasági lelkiismerete«.” (Horváth&Partners, 1997:15.) A controllingkoncepció információbiztonsági jelentőségét jól megvilágítja, ha biztonsági vezetői szemmel átgondoljuk az alábbi általános controlling alapkérdéseket. 1. „Tudja pontosan, hogy mely termékek hozzák, és melyek viszik a pénzt? 2. Tudja, hogy a különböző intézkedések milyen hatást gyakorolnak az eredményre? 3. Tudja, hogy mekkora eredményt ért el vállalatgazdasági szempontból, vagyis az adózás és a mérlegkészítés torzító hatásai nélkül? 4. Sikerül a tervezés során kihívó célokat kitűzni, és az erőforrásokat ezeknek megfelelően elosztani? 5. Megtudja a kellő időben, hogy minden a terv szerint halad-e, vagy elhagyták a kijelölt pályát? 6. Kiderül még időben, ha döntésre van szükség, és megteszik-e a szükséges intézkedéseket? 7. Át tudja ültetni a vállalati stratégiát konkrét eredmény- és intézkedési tervekbe? 8. Tisztában van azzal, hogy mitől emelkednek folyamatosan az általános költségek?” (Horváth&Partners, 1997:18.) Nyilvánvalóan nem mindegyik szempont alkalmazható közvetlenül, ám érdemes átgondolni, milyen kérdéseket tehetünk fel a controlling szemléletét átvéve az információbiztonság menedzselésével kapcsolatban. A következőkben – a controlling szemlélet IS-re való alkalmazhatóságát vizsgálandó és demonstrálandó – a fentinek megfelelő számozással az IS számára releváns kérdésekké formálom az előbbi kérdéseket. 1. Tudja pontosan, hogy melyik biztonsági intézkedés hozza meg a kívánt eredményt, teremt értéket, és melyik az, amelyik csak viszi a pénzt? 7
A 2.4. fejezetben a kontroll fogalmára ettől eltérő definíciót vezettem be. A controlling leírásában szereplő „kontroll” kifejezés
magyarázata ennek ellent mond, ám a controlling értelmezéséhez e definíció szükséges. Dolgozatom minden egyéb helyén a 2.4. fejezet értelmezését használom.
26
2. Tudja, hogy a különböző intézkedések pontosan milyen hatást gyakorolnak a szervezet
biztonságára?
Milyen
rendszerszintű
hatások
(ellenhatások?)
érvényesülnek? 3. Tudja, hogy milyen mértékben csökken a kockázat a biztonsági intézkedések nyomán? Felismeri azt a pontot, amelyen túl a biztonság további fokozása a védendő folyamatok működését lényegesen lassítja? A kockázat és hatékonyság viszonya az 5.3. fejezetben tárgyalt „biztonság, mint üzleti funkció” megközelítés szempontjából lényeges kiinduló elem. 4. Sikerül a tervezés során valós biztonsági kockázatokat megcélozni, és az intézkedésekre megfelelő erőforrásokat allokálni? 5. Megtudja a kellő időben, ha egy biztonsági incidens történik, illetve kockázatot növelő tendenciák, pl. hackertámadások kezdenek kibontakozni? 6. Kiderül még időben, ha döntésre van szükség, és megteszik az érintettek a szükséges intézkedéseket? 7. Létezik-e IS stratégia, amely összhangban van a szervezet céljaival, és az IT stratégiájával? Át tudja ültetni e stratégiát konkrét eredmény- és intézkedési tervekbe? 8. Tisztában van azzal, hogy mitől emelkednek a biztonsági költségek? Megfordítva: mely IS beruházás hoz fokozatosan csökkenő eredményt? Mit jelent ez? Véleményem szerint azt jelenti, hogy: •
egyrészt a biztonság számokkal, metrikákkal való kifejezése elengedhetetlen. „… ha azt, amiről beszélsz képes vagy mérni és számokban kifejezni, akkor tudsz róla valamit; de ha nem tudod mérni és számokkal kifejezni, akkor ismereteid igen szegényesek és elégtelenek.” (Kelvin, 1883.)
•
Másrészt a biztonságot nem elég pusztán számokkal kifejezni – olyan számokat kell gyűjtenünk, amelyek tükrözik stratégiai céljaink teljesülésének mértékét, transzparenssé teszik az információbiztonság céljait, működését és eredményeit.
Mindez szükségessé teszi a mérendő attribútumok megtalálását működésünkben. A mérőszámok alkalmazásával az 5.6. fejezetben foglalkozom.
27
4.4. A Balanced Scorecard relevanciája A Balanced Scorecard (BSC) rendszerét Robert Kaplan és David Norton dolgozta ki, választ keresve a tisztán pénzügyi mutatószámok elégtelen voltának orvoslására. A pénzügyi mutatók által festett (bizonyos szempontból torz) képet „kiegyensúlyozták”, és további három szempontot dolgoztak ki annak érdekében, hogy egy szervezet stratégiai céljait minél szélesebb körben tudja meghatározni és azok teljesülését minél pontosabban és relevánsabban mérhesse. A közvetlenül pénzügyi mutatókat tartalmazó oldalt kiegészítették egy ellensúllyal: a szervezet belső fejlődését fókuszba helyező nézőponttal. Egy második tengelyre szintén két (látszólag vagy valóban is ellentétes) szempontot helyeztek: az ügyfélorientált működést és a belső folyamatok kiválóságát és pontos végrehajtását. (Kaplan-Norton, 1998.) Ez az eszköz az információbiztonság területére adaptálva új távlatokat nyit a terület stratégiai menedzsmentjének terén. A Balanced Security Scorecard kialakításával az 5.6.2. fejezetben foglalkozom.
4.5. A folyamatszervezés fontossága Annak érdekében, hogy információbiztonsági intézkedéseink a szervezet működésének integráns részeiként érvényesülhessenek, létfontosságú, hogy a statikus követelménydefiníciókon túllépve, a kontrollokat – akár újonnan definiált, akár már létező – folyamatokon keresztül vezessük be. Ideális esetben, bármely biztonsági keretrendszert (COBIT8, ISO2700x9, ITIL10, stb.) is alkalmazzuk, a meghatározott biztonsági intézkedéseket azon területek folyamataiba ágyazzuk, amelyek a végrehajtásért felelnek majd; ilyen területek tipikusan az informatikai üzemeltetés és fejlesztés illetve beszerzés, a személyzeti osztály folyamatai, vagy a beszerzés. Emellett, annak érdekében, hogy működésünk mind időben, mind „térben” egységes képet mutasson, az információbiztonsági osztály által végzett feladatokat, folyamatokat is 8
COBIT: Control Objectives for Information and related Technology – Az IT és ahhoz kapcsolódó technikák
kontroll célkitűzéseit tartalmazó ajánlás. 9
ISO 2700x – az információbiztonsági szakterület legjobb gyakorlatait definiáló szabványcsalád.
10
ITIL (Information Technology Infrastructure Library) – az informatikai rendszerek üzemeltetésének átfogó
irányítási és folyamatrendszerét definiáló iparági ajánlás
28
kodifikálni kell. A „térben” kitétel leginkább azt jelenti, hogy „emberben” – vagyis alapvető, hogy minden résztvevő azonos alapelvek és szabályok mentén döntsön és hajtsa végre feladatát. A folyamatszervezés értelmezhető más felfogásban is. Tapasztalatom szerint egy-egy technikai biztonsági megoldás bevezetésekor az esetek nagy részében kizárólag a technikai bevezetésre koncentrál a projekt. A megoldást körülvevő szervezeti és folyamatbeli változások (változtatások) ilyenkor nem tartoznak a projekt hatókörébe. Ez nagyban csökkenti, sőt sok esetben annulálhatja is azokat a várt előnyöket, amelyek magának a projektnek az életre hívását indukálták. Bármilyen biztonsági megoldás bevezetésekor az alábbi ábrán látható párhuzamos erőfeszítés volna kívánatos: a technikai oldal mellett (az ábra felső része) kötelezően gondoljuk át, és ha szükséges, akár teljesen szervezzük át folyamatainkat (az ábra alsó része) a technikai megoldás lehetőségeit a lehető legteljesebb mértékben kihasználva (vagyis jussunk el az IT fejlődésének 5.3. fejezetben tárgyalt 3. fokára)!
Forrás: IT Governance Institute, 2006:25. 2. ábra: Az informatikai (és biztonsági) megoldások bevezetésének eredményessége érdekében szükséges többoldalú tevékenységek
4.6. Tudásmenedzsment Az információbiztonság, illetve informatikai szakemberek mindig is fogékonyak voltak a tudás megszerzése és átadása iránt. Ez különösen a hacker11 körökben villámgyorsan 11
Hacker – az informatikai és kommunikációs technika átlag feletti ismeretével rendelkező szakember, aki
képes ezen eszközök működésének legrejtettebb hibáit is feltárni. A köznyelv gyakran összetéveszti a cracker-rel, aki mindezt károkozásra használja.
29
terjedő információk esetében figyelhető meg. A legfontosabb azonban az, hogy miután a technika ismerete összefonódott a gyors tanulás és tudásmegosztás módszereinek ismeretével, így azoknak, akik az informatikában otthonosan mozognak, élen kell járniuk a tudás és információk kezelésének és megosztásának terén is, és magukkal kell húzniuk azokat, akik egyszerűen csak felhasználják az informatikát napi munkájukhoz. Vagyis annak érdekében, hogy az információbiztonsággal kapcsolatos tudatosítás, kommunikáció minél hatékonyabb legyen, nem elég „tanítóként” kell fellépni, hanem az eszközöket is biztosítani kell a szervezet felé ahhoz, hogy az IS terület által közölni vágyottakat minél hatékonyabban juttathassuk el a célközönséghez. Ezt a témát annál is inkább kritikusnak érzem, mert sok szervezetben az információbiztonsági csoport még intranet oldallal12 sem rendelkezik. A tágabban vett szervezet biztonsági tudatosságának építése és fenntartása mellett az információbiztonsági szakma másik kritikus területe, ahol a tudásmenedzsment módszerei relevanciával bírnak – többek között a 3.7. fejezetben tárgyalt „tudásciklusok” elkerülése érdekében – magának az IS szervezet tudásának kezelése. Tapasztalatom szerint, mint bármely más szervezetnek, az IS tudásbázisa is két alapvető típusú információból épül fel. Az egyik halmaz nézetem szerint a „tiszta” technikai tudás illetve szakmai tapasztalat – a klasszikus értelemben vett „tudás”. Az IS szervezet tudásának másik fő halmaza pedig magának a szervezetnek az értékei, céljai, folyamatai és eljárásai – amelyek szerint napi szinten működik. Természetesen ideális esetben az utóbbi az előbbin alapszik, mégis úgy gondolom, hogy alapvetően különböző módon kell e két halmazt menedzselni, legalábbis meg kell különböztetni egymástól. Fontos ugyanis, hogy nem minden „best practice” kerül alkalmazásra a gyakorlatban egy adott szervezetnél, viszont a szakmai felkészültség szempontjából alapvető fontosságú a minél bővebb szakmai ismerethalmaz. Az explicit módon megfogalmazott szabványokat, ajánlásokat mindazonáltal bárki elolvashatja, kielemezheti. Ezt nevezném én első szintű explicit13 tudásnak. Ezen tudás gyakorlati alkalmazásában szerzett tapasztalat, amely évek során gyűlik össze a szakember
12
Belső honlap, amelyen a fontos információk, leggyakrabban feltett kérdések, stb. publikálhatóak
13
„Az explicit tudás […] az a fajta tudás, amit birtokosának sikerült megfogalmaznia […]. Így ez a tudás már
(elvileg) közzétehető, másnak átadható.” (Sándori, 2001.)
30
fejében, alapvetően tacit14 tudásként áll ott össze – vagyis az csak általa alkalmazható! Az IS tudásmenedzsmentjének kritikus feladata tehát a szabványok és egyéb „best practice”ek gyakorlati alkalmazása mikéntjének – amely legtöbbször tacit tudásként jelenik meg – a kodifikálása. Ez annál is kritikusabb, mivel nincs két egyforma szervezet: különböznek az alapértékek, a célok, a prioritások, a kockázati étvágy, a szervezeti felépítés, az anyagi lehetőségek, adott esetben pedig még a kulturális sajátosságok is, amelyek a nemzetközi környezetből adódóan jelen lehetnek.
4.7. Tömeges együttműködés A szociológia területével összefüggő, sőt annak eredményeiből levezethető, azokat alátámasztó jelenség a csoportos alkotás, amelyet az ún. Web 2.015 tett lehetővé. E forradalmi eszköz olyan lehetőségeket tárt elénk, amelyek eddig elképzelhetetlenek voltak, másrészt
egyes
esetekben
ellentmondanak
a
hagyományos
közgazdaságtani
és
pszichológiai elméleteknek. „Az ismert mondás: »a tudás hatalom« gyakran arra ösztönzi az embereket, hogy felhalmozzák és visszatartsák az információkat, mert azt képzelik, hogy a visszatartott információk nélkülözhetetlenné teszik őket. Tévedés. A »hatalom« nem a visszatartott, hanem a másokkal megosztott tudásból fakad.” (Gates, 2000:245) Ráadásul nem csak egyéni szinten, hanem szervezetek között is hatalmas fejlődés katalizátora lehet, ha a versenytársak megosztják egymással bizonyos információikat. A történelem során a gazdaság mindig valamilyen fajta hatalom köré szerveződött, voltak vezetők és vezetettek. Bár ez a fajta hierarchia nem tűnt el, egy újfajta gazdasági modell kezd kialakulni, amely 14
Tacit tudás: „A kimondatlan tudás az egyének fejében, személyes tapasztalataikban rejtőzik. Döntő szerepe
van a gyakorlati problémák megoldásában annak ellenére, hogy gyakran nemhogy másoknak, de tulajdonosának sincs tudomása a létezéséről - aztán egyszer csak történik valami és a titkos tudás megmutatkozik. Ezt a fajta tudást sejtik az ösztönös megérzés mögött.” (Sándori, 2001.) 15
Web 2.0 – A web 2.0 (vagy webkettő) kifejezés olyan internetes szolgáltatások gyűjtőneve, amelyek
elsősorban a közösségre épülnek, azaz a felhasználók közösen készítik a tartalmat vagy megosztják egymás információit. Ellentétben a korábbi szolgáltatásokkal, amelyeknél a tartalmat a szolgáltatást nyújtó fél biztosította (például a portáloknál), webkettes szolgáltatásoknál a szerver gazdája csak a keretrendszert biztosítja, a tartalmat maguk a felhasználók töltik fel, hozzák létre, osztják meg vagy véleményezik. A felhasználók jellemzően kommunikálnak egymással, és kapcsolatokat alakítanak ki egymás között. (Wikipédia, 2011.).
31
alapjaiban változtatja meg a lehetségesről vallott nézeteinket. A vezetőknek át kell értékelniük a versenyről és a profitról alkotott elképzeléseiket, el kell sajátítaniuk a Don Tapscott és Anthony D. Williams által wikinómiának nevezett újfajta együttműködés elméletét és gyakorlatát. Ez sokkal több, mint például a nyílt forráskód vagy a crowdsourcing16. „A wikinómia lényegében a vállalatok, sőt az egész piacgazdaság szerkezetében és működési módjában bekövetkező alapvető változásokat foglalja össze, vagyis a piaci verseny olyan új alapelveit tárgyalja, mint a nyitottság, az egyenrangúak együttműködése, a megosztás (a tudás és másfajta erőforrások újfajta megosztása), valamint a globális cselekvés.” (Tapscott - Williams, 2007.) A gyakorlatban ez számomra azt jelenti, hogy a „webkettes” alkalmazások, és az általuk megtestesített filozófia és gyakorlati alkalmazása – bár újfajta kockázatokat is jelentenek – teljesen új lehetőségeket tárnak elénk és semmiképpen nem hiányozhatnak, sem a sikeres vállalat (vagy bármilyen szervezet), sem a sikeres IS vezető eszköztárából!
4.8. A rendszerelmélet alkalmazása Egy vállalat felső vezetése átfogó módon értelmezi és kezeli magát a szervezetet. Mindazonáltal, tapasztalatom szerint, ahogy haladunk az operatívabb megvalósítási szintek felé, ez a holisztikus látásmód elvész, ahogy az egyes területekért felelős vezetők egyedi céljaikat, problémáikat próbálják megoldani. Egyes esetekben a nagyvállalatoknál alkalmazott személyes célok rendszere is ezt propagálja. Ebből következik, hogy a születő megoldások silókban, szigetmegoldásként alakulnak ki – ez a teljes szervezet céljainak elérésének szempontjából sokkal kevésbé eredményes, akár káros is lehet. Nagyon fontos tehát, hogy bármilyen feladattal is foglalkozunk, alkalmazzunk átfogó látásmódot. Erre kiváló eszközt biztosítanak a rendszerelméleti fogalmak. Rendszerelméleti alapokon megfogalmazva a rendszer valamely közös ismérvek alapján összetartozó, kapcsolatban álló (egymásra hatással lévő!) elemek együttese, amely átfogó egészként viselkedik. Fontos tulajdonsága az ilyen formán definiált rendszereknek a közös cél, a rendszer elemeinek definiálása, és az azok közötti kölcsönhatás. A „rendszer” legalapvetőbb tulajdonságai a rendszer és környezete, illetve a rendszer elemei közötti hatások, (feedback, feed-forward) a nyugalmi állapotra való törekvés (equilibrium), illetve a 16
Crowdsourcing – feladatok nyílt felhívással történő „kiszervezése” egy nagy számosságú csoport (tömeg)
számára (Wikipédia, 2011.)
32
késleltetés (delay). A nyugalmi állapotot értelmezhetjük erőegyensúlynak is, hiszen a rendszer elemeinek egymásra hatása ekkor kiegyenlítődik. A rendszer működését befolyásolhatjuk, amennyiben beavatkozunk: csupán bemeneti információkat adva a rendszernek (vezérlés), vagy a rendszer kimeneteinek felhasználásával is (szabályozás). (Kiss, 2001:76.), (Senge, 1998.), (ISACA, 2009.) A rendszerelmélet ezen elemeinek alkalmazása véleményem szerint alapvetően meghatározhatja stratégiánk kialakítását és végrehajtását – átfogó gondolkodásra, és alapvető megközelítésünkben rejlő hibák felfedezésére kényszerítenek. Számomra a rendszerelmélet alkalmazása az alábbi kérdések felvetését alapozza meg: • A fentiek tükrében: Szabályzunk, vagy „csak” vezérlünk? • Mely pontokon törekszik éppen rendszerünk nyugalmi állapotra, vagyis hol és miért van ellenállás egy bevezetett biztonsági intézkedéssel szemben? • Hagyunk-e megfelelő mennyiségű időt, hogy a változás a szervezeten áthaladjon, vagy máról holnapra várjuk az eredményeket? • Figyelembe vesszük-e a rendszer elemei (szervezet szereplői, stakeholder-ek!) közti hatásokat, legyenek azok céljaink szempontjából előnyösek vagy akár hátrányosak? A legújabb kutatások az információbiztonság területén szintén ezen alapelvek minél relevánsabb megfogalmazásával igyekeznek az információbiztonsági szakma kezébe eszközöket adni mind a stratégiai és operatív tervezés, mind pedig a vezetői kommunikáció területén – ezeket az 5.3. fejezetben tárgyalom.
4.9. Marketing és PR, mint a biztonság építői A marketing szó eredete azokból az időkből származik, amikor az eladott/fogyasztott javak gyakorlatilag 100%-a jól megfogható termék illetve szolgáltatás volt, amelyeket piacokon (market) értékesítettek. Ez alapvetően keresleti piac volt; a fogyasztók szükségleteit közvetlenül elégítette ki, túltermelésről szó sem volt, nem is lehetett. Ez a jelleg az ipari forradalom során megfordult: lehetővé vált a tömegtermelés, így árufelesleg alakulhatott ki – ez tette szükségessé a termelők számára a modern értelemben vett marketing kialakítását. A marketing annak tudománya, hogy megtaláljuk, vagy épp megteremtsük piacunkat, megismerjük jelenlegi és potenciális vevőinket, életük megkönnyítését célunkká tegyük, és felépítsük saját „márkánkat”, amely valójában az a valami, amit a vevők megvesznek. Mindezt nem utolsó sorban a józan paraszti ész segítségével műveljük. (Papp-Váry, 2008.)
33
Mivel az információbiztonság szükségessége nem mutatkozik egyértelműnek a döntéshozók fejében, elkerülhetetlen, hogy azt is terméknek (vagy még inkább szolgáltatásnak!) tekintsük, hiszen jól láthatóan szükség van annak „eladására”. Ez a gyakorlatban annyit jelent, hogy muszáj megtalálnunk az információbiztonság helyét a szervezet életében, felépítenünk saját „márkáját” (nem konkrét terméknévre gondolok, inkább annak beégetését vezetőink és dolgozóink tudatába, hogy mivel foglalkozunk, és az miért fontos), és elérni, hogy „vevőink” akarják a biztonságot! Fontos tudni viszont, hogy „márkákat a pr segítségével hozzuk létre. A reklámmal pedig életben tartjuk azokat.” (Ries-Ries, 2005:192.) Ez annyit jelent az információbiztonság esetében, hogy az általános felhasználói és vezetői tudatosító képzések, sőt, egy jól kidolgozott jelentési rendszer is, önmagukban nem hatékonyak azon célunk elérésében, hogy a vezetést és a dolgozókat a biztonság ügyének megnyerjük – ezeket a módszereket ugyanis reklámnak értékelem! A pr eszközei sokkal finomabbak; ott kezdődnek, hogy a tudatosító oktatást nem (kizárólag) elektronikus formában adjuk, hanem az „arcunkat adjuk hozzá”, és mindent megteszünk a személyes
oktatás
lehetőségeinek
felkutatása
és
kihasználása
érdekében.
Ez
„visszalépésnek” tűnhet, sőt egy több tízezres vállalatnál minden egyes dolgozót ilyen formában oktatni nem is lehetséges. mindazonáltal nagyon sokat jelent, ha azt a korlátozott számú vezetőt, akik ügyünk támogatása érdekében fontosak, személyesen „oktatjuk” – és nem csak a felsővezetőket! Egy másik tanulság a pr területéről. Bár mindhárom egyazon cég márkája, „A Lexust, az Acurát és az Infinitit mind különálló márkakánt kezelik, egy hasonló autóról, a Diamantéról azonban azt gondolják, hogy az egy Mitsubishi, mert a Mitsubishi kereskedésben árulják. Ha valami úgy néz ki, mint egy kacsa és úgy is jár, mint egy kacsa, de csirkekereskedésben lehet megvenni, arra azt mondjuk, hogy csirke.” (Ries-Ries, 2005:172.) Ez, a kissé sarkított, és az információbiztonságtól teljesen elrugaszkodott példa arra világít rá, hogy amennyiben szervezetünkben már kialakult egy kép az IT vagy az információbiztonság szakmai alaposságával, hatékonyságával, működési stílusával, hozzáadott értékével kapcsolatban, akkor ezt első sorban meg kell ismernünk. Másodsorban pedig – amennyiben nem a kívánt kép él munkatársainkban és vezetőinkben a területről – mindenképpen fel kell kerekedni, és a pr eszközeivel csirkéből kacsát varázsolni,
annak
érdekében,
hogy
a
vezetők
azt
vegyék
meg,
amit
információbiztonsági szakemberek és vezetők „árulunk”, ne pedig valami teljesen mást.
34
mi,
4.10. Az ügyfélközpontúság kritikussága Az információbiztonsági szervezetre a legegyszerűbb úgy gondolni, mint aki meghatározza, majd betartatja a biztonsági követelményeket. Ám ez önmagában nem elegendő, hiszen azok a biztonsági intézkedések, amelyeket a szervezet igényeinek figyelembe vétele nélkül, csupán a „legjobb gyakorlat” alapján vezetünk be, óhatatlanul veszítenek hatékonyságukból és eredményességükből, amint felhasználóink úgy érzik, azok akadályozzák munkájukat; megkerülik, illetve hatástalanná teszik kontrolljainkat. Így aztán az „erőből” bevezetett biztonsági intézkedések nem érik el a kívánt hatást. E probléma feloldására szükségünk van arra, hogy megértsük a szervezet céljait, és azokkal azonosulva, kontrolljainkat annak megfelelően alakítsuk ki, kommunikáljuk, vagy akár módosítsuk – mintegy „biztonságot szolgáltatva” a bennünket megbízó szervezetnek.
4.11. Szociológiai szempontok „Az emberek kapcsolatba lépnek egymással, és struktúrákat hoznak létre ezekhez az interakciókhoz. A társadalomtudósok az emberek közötti viszonyok természetét igyekeznek felfedezni […]. Rendes körülmények között az emberek megfigyeléseit a körülöttük zajló dolgokról és ezek értelmezését legalább három tényező homályosítja el: (1) nézeteik arról, hogyan kellene lenniük a dolgoknak, (2) a felnőtté válásuk során megtanult tévképzetek és babonák, és (3) a felületes és téves megfigyelések.” (Babbie, 2008:2.) A napi gyakorlatban ezek a „bejáratott” megoldási sablonokhoz való ragaszkodásban nyilvánulnak meg. Egy saját szakterületén elmélyült ismeretekkel rendelkező egyén, szakmai látásmódja miatt még inkább hajlamos téves következtetéseket levonni a vele (jobban vagy kevésbé) együttműködő kollégák, illetve szakterületek reakcióiból, ezért a sikeres együttműködés érdekében még inkább kritikus a szervezetben zajló interakciók és folyamatok objektív értékelése. Minden szervezetnek (vállalatnak) megvan a saját belső demográfiája, amit – mint minden egyéb fontos ismérvet – fel kell mérnünk és meg kell ismernünk ahhoz, hogy hatékonyan működhessünk közre a szervezet céljainak megvalósításában, és ezt a megfelelő együttműködési keretek között tehessük. Ráadásul a „webkettes” világban dolgozóink illetve felhasználóink is összetettebb fenyegetéseknek vannak kitéve, mint akár öt évvel ezelőtt, hiszen a Facebook, LinkedIn,
35
Twitter és egyéb, életünk megnyitására, személyes kapcsolataink, érzéseink, gondolataink megosztására buzdító és lehetőséget teremtő alkalmazások (social media17) teljesen új és eddig ismeretlen lehetőségeket kínálnak az interakcióra. Az információbiztonsági csoport „helyzetének” megállapítására az egyik lehetőség, ha kérdezünk. A legközelebbi érdekeltekkel természetesen személyes kontaktus szükséges, ám nagyon fontos tudnunk azt is, hogyan tekint ránk a szervezet egésze. A szervezettől való „kérdezésnek” talán legkézenfekvőbb és leghatékonyabb módja egy rövid kérdőív, amelyre egy példát az 5.4. és a 8.1. fejezetben (Melléklet) ismertetek.
4.12. Pszichológiai vonatkozások A technika fejlődésével szemben az ember alapvetően több ezer éve változatlan – a túléléshez szükséges képességeket génjeink, alapvető viselkedési mintáinkat neveltetésünk hordozza. Bármilyen, minimálisan meghatározónak mondható változás viselkedésünkben csak generációk alatt lehetséges. Véleményem szerint az ipari forradalom alapvető vívmányait az elmúlt közel száz évben épphogy sikerült beépíteni mindennapjainkba, a „digitális forradalom” pedig jelenleg is tart, ráadásul alig néhány évtizede vette kezdetét, és a „robbanás” egyre gyorsabb. Ezért – akármennyire is szeretnénk – fizikai lehetetlenség volna, hogy az információ- és kommunikációs technológiát használó egyre szélesebb tömegek máris fel legyenek vértezve az informatikai kihívásaira, legyenek azok technikai, pszichológiai, vagy egyéb természetűek. Nem véletlen hát, hogy Bruce Schneier szavaival élve: „Az amatőrök a technikát támadják; a profik az embereket.” (Schneier, 2000.) A jelenséget, illetve a módszereket, amelyeket e mondat remekül jellemez social engineering-nek hívjuk – magyarul egész egyszerűen manipulációnak, megtévesztésnek, átverésnek fordíthatjuk. E fordítások azonban nélkülözik az angol kifejezés gunyoros színezetét, ezért véleményem szerint nem is adják át olyan erővel azt az újfajta veszélyt, amelyet ezen, valójában ősrégi technikák az információ- és kommunikáció technológia fejlődésével az ezeken keresztül hozzáférhető tengernyi mennyiségű adatra nézve jelentenek. Ráadásul az emberi természetből adódóan, ha egy bizonyos szintű kockázatot elfogadottnak tekintünk, akkor egy, a biztonságot növelő intézkedés azzal arányos 17
Social media – webkettes közösségi helyek, az interakció csatornáit biztosító technikai megoldások
36
kockázatkereső viselkedést indukál; például egy légzsákkal és jó futóművel felszerelt autóval gyorsabban hajtunk, mint egy kevésbé jól felszerelt modellel. Ugyanez igaz az információbiztonság
területén:
minél
látványosabbak
a
biztonsági
intézkedések,
felhasználóként annál felelőtlenebbül viselkedünk! (Shostack-Stewart, 2008:96.) Fontos tehát a pszichológia szempontjait figyelembe vennünk – nem csak a külső kockázatok szempontjából, hanem biztonsági intézkedéseink hatásmechanizmusának felderítése és eredményességének növelése érdekében is!
37
5. Szintézis: az információbiztonság új megközelítési lehetőségeinek elemzése 5.1. A problémák kiváltó okainak és lehetséges válaszoknak együttes elemzése Az eddigiek alapján tehát az információbiztonság, mint szakma, és mint szervezeti egység számos kihívással küzd(het), amelyek kiváltó okainak fel nem ismerése 2-3 éves távlatban bizonyosan kudarcra kárhoztatja erőfeszítéseinket – legalábbis a fejlődés marad el, ami véleményem szerint ugyanolyan rossz. Az általam e dolgozatban javasolt módszertani kitekintés összefoglalásaként az alábbi mátrix egységes képet mutat arról, hogy tapasztalatom és elképzeléseim szerint mely területekről származó módszerekkel kerülhetjük el e csapdákat, illetve orvosolhatjuk a már meglévő, de felismert problémákat. 1. táblázat: Az IS problémáinak kiváltó okai és a potenciálisan analóg megoldásokkal rendelkező
X
X
38
X
X X X X X
X X
X X X
X X X X
X X X
Pszichológia
X X X
Szociológia
Rendszerelmélet
Tömeges együttműködés
Tudásmenedzsment
Folyamatszervezés
Balanced Scorecard X X X X
X X
Ügyfélorientált működés
X
X X X
X X X
Marketing
Szervezeti széttagoltság Erőforráshiány Reaktív működés Széttagolt jelentési rendszerek "Papírgyár" Tudásciklusok Veszélyérzet hiánya Elefántcsonttorony Másodlagos kontroll hiánya
Controlling
Közgazdaságtan
szakterületek összefüggési mátrixa
X
X X X X
X X
X
X X
Forrás: saját elemzés saját IS szakismeretek és az egyéb területek lehetőségeinek feltérképezése alapján
A fenti táblázatban minden egyes „X” jel külön, saját jogán teljes dolgozatot érdemlő koncepciót takarhat – például: „A reaktív működés problémájának kezelése a tömeges együttműködés eszközeivel”. Így ezeket jelen dolgozatban bővebben nem fejtem ki, ám ezek szintéziseként átfogó fejlődési irányokat, illetve elgondolásokat, elméleteket, és gyakorlati megoldásokat keresek, amelyek az információbiztonság szervezésének új irányait jelenthetik.
5.2. Az információbiztonság stratégiai megközelítése Az információbiztonság nem önmagáért létezik, és nem légüres térben működik. A biztonságnak minden körülmények között szem előtt kell tartani a szervezet fő céljait, és azok teljesülésének szolgálatába kell állnia, mind rövid, mind hosszú távon. Ezért az információbiztonság szervezéséhez elengedhetetlen a szervezet üzleti illetve informatikai stratégiájának ismerete, és az ahhoz való igazodás. Emellett feladatunk, hogy az információbiztonsági szakterületre magára is stratégiai tevékenységként tekintsünk, és ennek megfelelően menedzseljük. (Pironti, 2010.) Bár valójában minden megbízatás kezdetén rá vagyunk kényszerítve egy ideig arra, hogy akut problémákkal küzdjünk, távolról sem teljes információk alapján, ezen időszaknak nem szabad fél évnél hosszabbnak lennie. Ennyi idő alatt a gyorsan abszolválható kisebb megoldások mellett elő kell állnia egy, az aktuális állapotot alapul vevő stratégiai tervnek és tisztában kell lennünk az éppen folyamatban lévő nagyobb léptékű projektek állapotával is. (Purser, 2004:86-87.) Mindemellett a biztonsági termékek piacán megfigyelhető egy, a fentiekkel szemben ható és káros trend, amelyet Andrew Jaquith (számomra érthető módon) kissé cinikusan „A Fájdalom Mókuskerekének” hív. A legtöbb szállító, aki biztonsági stratégiai terméket árul, legyen az kockázatmenedzsment platform, vagy vulnerability scanner18, általában egy, a Deming-ciklushoz hasonló, amerikai fánk alakú, körkörös diagramon ecseteli terméke által megtestesített, folyamatos fejlődést biztosító folyamatot. E folyamat általában a következő lépésekhez hasonló elemekből áll:
18
Informatikai rendszerek sérülékenységeit felderítő alkalmazás
39
• Detektálás • Jelentés • Priorizálás • Kockázatkezelés Természetesen kivétel nélkül az ajánlott termék lesz a folyamat katalizátora és motorja. Az alábbi ábrán a kockázatkezelési ciklus karikírozott verziója, „A Fájdalom Mókuskereke” látható:
Forrás: Jaquith, 2007:3. 3. ábra: A Fájdalom Mókuskereke – A kockázatmenedzsment „alternatív” vetülete
1. Használjuk a terméket, és ezáltal szembesüljünk azzal, hogy nyakig benne vagyunk. 2. Pánikoljunk! 3. Toporogjunk kényelmetlenül a főnök előtt! 4. Szállítsunk minimál-megoldást (nagy hűhóval). Reménykedjünk, hogy minden szép és jó lesz a jövőben. (Jaquith, 2007.) Valóban előfordul, hogy egy szervezetnek szüksége van valamilyen speciális biztonsági termékre vagy szolgáltatásra. Mindazonáltal hosszútávon a leghasznosabb a problémák elemi természetének megértése és azok kiváltó okainak orvoslása. Az egyéni sérülékenységek
fókuszált,
szigetszerű
40
orvoslása,
elfeledkezve
az
átfogó
információbiztonsági stratégiáról, a kockázat-arányos védelemről és az egyenszilárdság elvéről, téves irányba viheti költségtervezésünket. (Shostack-Stewart, 2008: 29.) Gondolkodjunk globálisan – cselekedjünk lokálisan! (Geddes, 1915.) A továbbiakban tárgyalt módszertanok közös tulajdonsága, hogy globális (holisztikus) látásmódot képviselnek és ok-okozati összefüggéseket keresnek.
5.3. A biztonság, mint üzleti funkció Az informatikai stratégák évekkel ezelőtt felismerték, hogy az informatika nem lehet fekete doboz az üzlet számára, sőt, az információbiztonság magának az üzletnek a része. A Forrester kutatásainak eredményei tovább mennek: azt javasolják, hogy az IS vezető állítson fel hivatalos üzleti kapcsolattartót, akár többet is, akik üzleti területük szakértőivé válva élő kapcsolatot alakíthatnak ki az üzlet és a biztonság között, így valóban az üzleti céloknak megfelelő biztonsági megoldások bevezetését tehetik lehetővé. (Kark, 2009.) Csak egy, de jellemző és friss, saját tapasztalatomon alapuló példa erre a folyamatra a 2010. év egyik legdivatosabb témája, amelyre a 4.7. fejezetben már utaltam: a „webkettes” csatornákon végzett marketing. Ha karban tartjuk üzleti kapcsolatainkat és ott vagyunk, amikor vállalatunk pr és marketing felelősei ilyen irányban kezdenek gondolkodni, akkor már idejekorán kialakíthatjuk ez irányú stratégiánkat és közös munkával formálhatjuk mind külső, mind belső kockázatok kezelésének módját – annak érdekében, hogy cégünk minél sikeresebben alkalmazhassa ezt a technológiát is és minél több rajongót szerezzen ezen a fronton is, a felhasználói magatartás által okozott adatvédelmi és biztonsági kockázatok megfelelő csökkentésével. Annak érdekében, hogy az információbiztonságot üzleti funkcióként kezdjük értelmezni, fontosnak tartom első körben magának az informatikának az üzleti gondolkodásban elfoglalt helyét pontosítani. Célnak tartom ugyanis azt, hogy az információbiztonság az informatika által (mára már többé-kevésbé) bejárt utat kövesse az érdekeltek gondolkodásában. Az informatika az elmúlt évtizedekben fokozatosan vált operatív „kisegítőből” stratégiai fontosságú területté. John Thorp az IT fejlődésének három fázisát különbözteti meg: 1. A munka automatizálása (Automation of Work): ekkor valójában ugyanazt végezzük az informatika segítségével, amit eleddig is, csak hatékonyabban.
41
2. Információmenedzsment (Information Management): ebben a fázisban már az informatika lehetőségeit figyelembe véve alakítjuk át munkafolyamatainkat, másképp végzünk bizonyos feladatokat – a fő cél az eredményesség. 3. Az
üzlet
átalakítása
(Business
Transformation):
A
legmagasabb
szintű
elfogadottság: magának az üzletágnak a szabályait definiáljuk újra, akár teljesen más dolgokat csinálunk, mint eddig – az IT alkalmazásának célja már stratégiai versenyelőny megszerzése. (Thorp, 2003:13.) Tapasztalatom szerint azonban a fenti fejlődés távolról sem homogén! Egyes vállalatoknál végbement e változás, másoknál pedig nem, vagy csak részben. Vagyis leginkább arról beszélhetünk, hogy mely szervezet milyen szinten áll az informatika alkalmazásának terén. Követendőnek tartom tehát a fenti fejlődési irányt. Ennek elérése érdekében meggyőződésem, hogy az IT szakma által alkalmazott „értékteremtési” módszereket és üzleti értékdefiníciót szükséges követni az információbiztonság területén is. A 4.3. fejezetben már utaltam arra az általánosan elfogadott szemléletre, hogy a biztonság növekedése a hatékonyság csökkenésével jár, illetve hogy meg kell találnunk azt a pontot, ahol ez a csökkenés már nem tolerálható. Ezt egy egyszerű ábrán szemléltethetjük:
Forrás: általános felfogás saját ábrázolása 4. ábra: A biztonsági intézkedések hatékonyságra gyakorolt hatásának általános szemlélete
Mindazonáltal eme egyszerű grafikai ábrázolás egy teljesen új irányba mutató gondolatkísérletre ad lehetőséget. Forgassuk a „Biztonsági intézkedés” nyilát felfelé. Ezzel a következő kérdéshez jutunk el: Megtaláljuk azokat a speciális megoldásokat, amelyek a biztonság fokozása érdekében nem áldozzák fel a folyamatok hatékony működését – amikor a kockázat egységnyi csökkenése egységnél kisebb hatékonyságcsökkenést eredményez? Ezt a gondolatot az 5. ábrán szemléltetem.
42
Forrás: saját elemzés 5. ábra: A biztonsági intézkedés a kockázat csökkenéséhez mérten kevesebb hatékonyságcsökkenéssel jár
Folytatva a gondolatmenetet, és a biztonsági intézkedés nyilát tovább forgatva, és a függőlegesen átbillenve a következő kérdéshez jutunk: Mi lenne, ha a hatékonyságot növelni próbálnánk a biztonsági intézkedésekkel? E gondolat mentén teljesen új megközelítésben gondolhatjuk át minden intézkedésünk hatását és üzleti értékét!
Forrás: saját elemzés 6. ábra A biztonsági intézkedés növelje a hatékonyságot!
43
A 80/20-as szabály, vagyis a Pareto-elv szerint eredményességünk aránytalanul nagymértékben függ attól, hogy néhány kulcsfontosságú dolgot jól csináljunk. Többek között Thorp munkája alapján az IT Governance Institute által kidolgozott VAL-IT keretrendszer az alábbi alapkérdéseket teszi fel az informatikára vonatkozólag – amelyeket az információbiztonságra, mint „autonóm” területre szintúgy értelmeznünk kell és módszeresen meg kell válaszolnunk: • Stratégiailag a helyes dolgokat csináljuk? • Helyesen hajtjuk végre azokat? • Eredményesen tesszük a dolgunkat? • Elérjük-e a várt eredményeket (előnyöket)? Alább az eredeti VAL-IT publikációban megjelent ábra látható, amelyet eredetiben az angol megfogalmazások lényegre törő volta miatt tartottam fontosnak beilleszteni.
Forrás: IT Governance Institute, 2006:9. ábra: Aalkalmaz négy „Vajon” (The four „Ares”) A VAL-IT a fenti alapelvek 7. mentén stratégiai megközelítést.
Az ISACA 2010-ben „The Business Model for Information Security” címmel kiadott módszertani publikációjában bemutatott stratégiai modell arra vállalkozik, hogy egy olyan, valóban átfogó kontextust teremtsen, amelyben COBIT, ISO 2700x, és egyéb keretrendszerek egységes egésszé állhatnak össze. A modell alapvetően a 4.8. fejezetben bemutatott rendszerelméleti alapokra építkezik, ám speciálisan az információbiztonság terén releváns fő területeket foglalja magába – az ezek közti dinamikus kapcsolatokat képezi le. A BMIS alkalmazza az IS szervezésében „hagyományos” elemeket (hívhatjuk
44
ezeket erőforrásoknak, vagyonelemeknek is): Emberek (People), Folyamatok (Process) és Technológia (Technology) – ám kiegészíti egy kritikus elemmel, amely maga a Szervezet (Organization). A Szervezet elem kapcsolja az egész információbiztonságot magához a vállalathoz, amelyben létezik: stratégia (hiszen a biztonság nem önmagáért létezik!), formális és informális szervezet (intézkedéseink sikere vagy bukása jelentősen függ attól, milyen mértékben vagyunk képesek azt a szervezettel elfogadtatni). A végpontok, „elemek” közt húzódó dinamikus kapcsolódási pontok a következők: • Kultúra (Culture) • Irányítás (Governing) • Architektúra (Architecture) • Megjelenés (új ötletek, spontán kialakuló megoldások) (Emergence) • Képességek biztosítása és Támogatás (Enabling and Support) • Humán tényezők (Human Factors)
Forrás: ISACA, 2009:14. 8. ábra A BMIS modell áttekintése
A „dinamikus kapcsolat” (fordíthatjuk „átkötésnek” is) nagyon fontos rendszerelméleti alapelv leképezése, hiszen ha egy rendszer egyik elemén változtatunk, akkor az elkerülhetetlenül hatni fog a többi rendszerelemre is. (ISACA, 2009.) Meglátásom szerint ez egy olyan szempont, amit az IS program szervezésekor nagyon könnyű elfelejteni: egy-egy projekt önmagában is olyan mértékű szervezést igényel, hogy annak hosszú távú – szándékolt vagy éppen csak törvényszerű – hatásait sokszor nem
45
vesszük számításba. Fontos megkülönböztetni és felismerni, hogy mi az, amit szándékunkban áll megváltoztatni (általában a projekteknél ezt felmérjük), és mi az, ami ennek hatására törvényszerűen változik akár akarjuk akár nem! Itt az a kérdés, hogy hagyjuk ezeket a változásokat haladni a maguk útján (struccpolitika), vagy proaktívan felmérjük és irányítjuk tevékenységünk minden lehetséges következményét – ebben segít a BMIS koncepciójának alkalmazása. Ez, a korábban tárgyalt szigetmegoldások, a szervezeti silókból és rövidtávú gondolkodásból eredő problémák új szemszögből való megközelítését teszi lehetővé. Természetesen csak akkor, ha erre hajlandóak vagyunk, hiszen a látókör kitágítása, érintettek bevonása és intézkedéseink következményeinek feltérképezése akár hosszú, akár rövid távon, mindenképpen többletmunkát jelent. Ugyanakkor ez, az intellektuális kihívás mellett jól megfogható előnyökkel is járhat, bár kimondottan nem rövid távon (hiszen a rendszerelmélet egyik alapelve a késleltetés). Vagyis ahhoz, hogy maradandó értéket teremthessünk, elengedhetetlen a hosszú távú gondolkodás és a türelem!
5.4. A biztonság, mint szolgáltatás A „szolgáltatás” fogalma alatt itt nem a biztonsági funkció kiszervezését értem, sokkal inkább tevékenységünk kívánatos megközelítésére utal. Maga az „informatika” jó példával jár elöl az ITIL alkalmazásával, ám biztonsági oldalról még sok a lemaradás. Ennek oka lehet az is, hogy nem rendelkezünk egy ITIL-hez hasonló keretrendszerrel az információbiztonság területén (az ISO 27000 szabványcsalád és a COBIT is valójában kontrollok gyűjteménye, a szolgáltatói, ügyfélorientált szemlélet hiányzik belőlük). A 5.3. fejezetben bemutatott BMIS ennek lehet kezdeménye, ám ahhoz, hogy praktikusan alkalmazható legyen, véleményem szerint további strukturálásra, illetve a fent említett keretrendszerekkel való harmonizálásra van szükség a jövőben. Mindenesetre az üzleti partnerség alapelvét alkalmazva arra jutottam, hogy valójában a biztonsági tudatosság és a szolgáltatói szemlélet szorosan összefügg: a humán biztonsághoz kulcs a jó „biztonsági szolgáltatás” hiszen az emberek szeretik, ha kiszolgálják őket. Mindazonáltal az információbiztonság leginkább csak nemet mond a legtöbb üzleti kezdeményezésre, vagy legalábbis finoman ellehetetleníti azt – a „biztonság” érdekében. Természetes: az ironikus mondás szerint is a legbiztonságosabb
46
számítógép az, amely egy zárt betontömbben van, áramtalanítva. Ez a megközelítés azonban nyilvánvalóan nem előremutató, az „üzleti” jelző pedig távolról sem illik rá. Hogyan működik az információbiztonság, mint szervezeti egység, és a teljes szervezet része – tanulságos, ha ezt felmérjük. A 8.1. fejezetben, mellékletként8.1 szereplő, általam készített felmérésben állításokat fogalmaztam meg, amelyekkel ideális esetben azok, akikkel napi munkakapcsolatban vagyunk – illetve akár a teljes dolgozói, felhasználói kör – teljes mértékben egyetért. A kérdésekre adott válaszlehetőségek: Egyáltalán nem ért egyet, kismértékben, nagymértékben, illetve teljes értékben egyetért. A felmérést egy bank szervezetében elvégezve az alábbi eredmények születtek. Azok, a kollégák (beosztottak és vezetők egyaránt), akikkel az IS csoport szorosabb munkakapcsolatban van (kb. 200 fő), főként az alábbi területeket tartották fejlesztendőnek az IS működésében ebben az esetben: • Proaktivitás és üzleti partnerség • Megkeresésekre adott válaszok reakcióideje • Egyértelműbb szabályzatok • Átláthatóbb biztonsági folyamatok A felmérésnek módszertanilag egy további érdekes tanulsága volt. Bár magát a kérdőívet legjobb tudásom szerint strukturáltam és tapasztalatom szerint lényegre törő kérdésekből állítottam össze, a legtöbb értékes visszajelzés a szabadszöveges „Javaslatok” kérdésre érkezett. Méghozzá olyan módon, hogy a strukturált kérdések között adott válasz leginkább semleges volt, míg a szabadszöveges válaszban sokkal direktebben fogalmazódtak meg a fejlesztendő területek. A biztonsági tudatosító tevékenységünk során célunk nem egyszerűen az információk átadása kell, hogy legyen! El kell érnünk, hogy dolgozóink ne csak ismerjék, hanem elfogadják és másoktól is elvárják a biztonsági intézkedések végrehajtását! (Vasvári, 2010.) Ez valójában a szervezeti kultúra átformálását jelenti, amely azután szinte önmagát tartja fenn – természetesen folyamatos tudatosító tevékenység mellett. Mindenesetre egy valóban biztonságtudatos cégkultúrában nem az információbiztonsági tudatosító anyagok halmaza az egyetlen információforrás: a dolgozók egymásnak adják át a biztonságtudatos viselkedésmódokat.
47
5.5. Hogyan adjuk el a biztonságot? Hogyan adjuk el a biztonságot? Röviden: mutassuk meg, hogy értékes. „Az erőforrások értékességét nem lehet más tényezőktől függetlenül felmérni, mert értéküket az határozza meg, hogy a piaci erőkkel milyen kölcsönhatásban állnak. Egy olyan erőforrás, amely egy bizonyos iparágban vagy egy bizonyos időben értékesnek számít, lehet, hogy nem ér ugyanannyit egy másik iparágban vagy időszakban. Bár már sokan kísérleteztek azzal, hogy a homár eladását valamilyen márkanévhez kössék, ez még senkinek sem sikerült. Ennek oka véleményem szerint az, hogy a homár nem rendelkezik univerzálisan megfogható előnyökkel. A márkanév korábban rendkívül fontos volt a személyi számítógépeknél, de ez ma már nem igaz – ezért a felismerésért az IBM nagy árat fizetett. Emiatt az erőforrás-alapú szemlélet elválaszthatatlanul összeköti a vállalat belső képességét (mi az, amit jól csinál) és a külső iparági környezetét (mi az, amit a piac igényel, és amit a versenytársak ajánlanak).” (Collins-Montgomery, 2008.) A stratégiai szempontból értékes erőforrásoknak D.J Collins és C.A. Montgomery szerint öt jellemzője van. A későbbiekben tárgyalt öt jellemzőt két közgazdasági elmélet kombinálásával alakították ki: a szervezet erőforrás-alapú szemlélete (Resource-based view, RBV), és Michael Porter öttényezős modellje alapján. Collins és Montgomery elmélete a stratégiai SWOT elemzéssel analóg módon vizsgálja a stratégiai lehetőségeket: a szervezet belső tulajdonságaira fókuszáló RBV és a külső tényezőket számba vevő Porter öttényezős modell ideális kiegészítői egymásnak, és egy SWOT analízis keretén belül a teljes kép átlátása érdekében alkalmazhatóak. Az RBV modell szerint három alapvető piaci tényező dinamikus kölcsönhatása határozza meg egy belső erőforrás vagy képesség stratégiai értékét: ritkaság, kihasználhatóság, igény. Abban az esetben képvisel tehát valódi stratégiai értéket és jelent versenyelőnyt egy erőforrás, ha mindhárom szempont teljesül, vagyis egy olyan erőforrással rendelkezünk, amely (pl. kiemelt hasznossága miatt) nagyon keresett, ám (talán éppen ezért) hiány van belőle, számunkra azonban rendelkezésre áll! Porter öttényezős modellje ezzel szemben a külső tényezők végiggondolását segíti. Mind az öt szempontot figyelembe kell vennünk, amikor szervezetünk környezetét elemezzük. Az öt szempont:
48
Forrás: Porter, 1985:4. 9. ábra: Az ágazati versenyt alakító öt tényező
Collins és Montgomery a két modell szintézisével a stratégiai szempontból értékes erőforrásokat az alábbi öt jellemzővel írta le: 1. „Nehezen másolhatóak. 2. Lassan devalválódnak 3. A vállalatunkon, és nem az alkalmazottakon, beszállítókon vagy a vevőkön múlik az értékük 4. Nem könnyen helyettesíthetők 5. Felülmúlják a versenytársaink által birtokolt, hasonló erőforrásokat.” (Collins-Montgomery, 2008.) Az alábbiakban Collins és Montgomery szempontjai mentén az információbiztonságot, mint szakterületet – illetve az IS által bevezetett biztonsági intézkedéseket és megoldásokat – stratégiai szempontból értékes, versenyelőnyt biztosító erőforrásként definiálva azon körülményeket és megfontolásokat elemzem, amelyek megváltoztathatják az egyes biztonsági intézkedésekkel, illetve a teljes szakterülettel kapcsolatosan kialakult „költésorientált” szemléletet, és az információbiztonságot stratégiai mércével mérik! E szempontok segítségével értékelhetjük a jelen dolgozatban bemutatott analógiákat, illetve az azok mentén kirajzolódó megoldásokat is!
49
1. Utánozhatatlanság, vagyis: mennyire egyediek biztonsági megoldásaink? Olyan megoldást alkalmazunk, amely az „átlagoshoz” képest érezhetően (és mérhetően!) hatékonyabb és hatásosabb? Tapasztalatom szerint a valóságban leginkább az átlagoshoz közelítő biztonsági keretrendszerünk van és lesz is, főleg ha a neves elemző cégek és piacvezető szállítók útmutatását követjük az 5.2. fejezetben tárgyalt módon. Természetesen szükségünk van információra arra nézvést, hogy merre halad a világ, ám véleményem szerint sosem szabad teljes mértékben a szállítók információira hagyatkozni stratégiánk és operatív céljaink kialakítása során – nagyon fontos, hogy egyéni „ízt” adjunk intézkedéseinknek: egy ötletes biztonsági tudatosító kampány formájában, vagy folyamataink kialakítása során. Ezt annál is inkább fontosnak tartom, mert az IS piacon jelen lévő elemzők és szállítók statisztikái és megoldási csomagjai sok esetben azt sugallják, hogy minden cég egyforma. Ez természetesen sarkított megfogalmazás, de tény, hogy a szoftverszállítók például igen ritkán foglalkoznak azzal, hogy megoldásuk bevezetése milyen szervezeti és folyamatváltoztatással kellene, hogy együtt járjon. Valójában azonban minden szervezet különbözik a másiktól, ezért különféle megoldások lehetségesek (és szükségesek): ami az egyik helyen működik, az a másik helyen eleve bukásra lehet ítélve. Tegyük fel inkább így a kérdést: mitől egyedi cégünk, mennyire tudunk annak identitásával azonosulni, mint az információbiztonság
megteremtésének
és
fenntartásának
felelősei?
Mik
szervezetünk alapértékei: jól bevált konzervatív megoldások híve, vagy a kreativitást, innovációt, felelősségvállalást, a világbékét, netalán kizárólag a profitot tartja szem előtt? Merítsünk ihletet ezekből annak érdekében, hogy biztonsági megoldásaink valóban utánozhatatlanok legyenek! Bónuszként a cég alapértékeinek integrálása minimum egy további előnnyel is jár: kollégáinkkal, akiknek valójában be kell majd tartani a rengeteg biztonsági intézkedést, egy nyelvet fogunk beszélni, amennyiben a szervezet alapértékeire vezetjük vissza kontrolljaink
létjogosultságát.
Az
utánozhatatlanság
egy
teljesen
másik
szemszögből értelmezhető a következőként is: olyan módon kompenzáljuk a külső/belső fenyegetéseket, amelyek a támadók által nehezen kerülhetőek meg („utánozhatóak”)?
50
2. Tartósság, vagyis: milyen gyorsan veszít értékéből biztonsági megoldásunk? Milyen hosszú távú értékkel rendelkezik az általunk bevezetett megoldás vagy intézkedés? A folyamatos reaktív működés általában szigetmegoldásokat eredményez, amelyek azután újabb operatív problémákat generálnak a régiek helyébe. Tüzet oltunk, vagy valóban tartós értéket termelünk? Fenntartható (esetleg akár
önmagukat
fenntartó)
kontroll-folyamatokat
vezetünk
be?
Valóban
„bevezettük” kontrolljainkat – vagyis a kontrollok bevezetése magában foglalja azok definiálását, valós implementálását, folyamatos ellenőrzését és a rendszeres jelentéskészítést? (Singleton, 2009.) 3. Kihasználhatóság, vagyis: kinél jelenik meg a biztonsági megoldásunk által teremtett érték? A biztonsági megoldás valóban a cég érdekeinek felel meg? Ez a kérdéskör tipikusan a „biztonság vs. funkcionalitás” folyamatos ellentétére vonatkoztatható. Közhely, hogy ha például túl komplex jelszavakat kényszerítünk ki, a felhasználók fel fogják azokat írni, mivel nem tudják megjegyezni. Ha megkíséreljük megtiltani egy adott technikai megoldás vagy szoftver alkalmazását, akkor fennáll annak a veszélye, hogy a használatával elérhető termelékenységi javulást vagy egyéb előnyöket nem élvezhetjük, ám a kockázatok mégis megmaradnak. (Jaquith, 2007: 124.) Hiszen könnyen lehet, sőt, tapasztalatom szerint szinte biztos, hogy nem tudjuk 100%-ban „kiirtani” az adott megoldást, illetve Orwell-el szólva mindig vannak „egyenlőbbek”. Egy adott biztonsági intézkedés esetében mindig vannak kivételek, és az sem mellékes, hogy ezeket előre definiált folyamatainkon belül kezeljük, vagy a „kivételezés” látszatát keltjük. Érdemes tehát végiggondolni, melyek azok a technológiák, amelyek az elmúlt évtizedben jelentek meg, és esetleg struccpolitikát folytattunk velük szemben – utasítással tiltjuk, de a betartás ellenőrzése nem teljes körű, illetve néhány dolgozó engedélyt kapott használatára. Az utasítások szintjén való kategorikus tiltásnak nagyon nagy hátránya, hogy ekkor semmilyen óvintézkedést vagy kontrollt nem fogalmazunk meg a tiltott megoldás használatára, tehát az a (szerencsésebb esetben)
néhány
kivételezett,
akik
elkerülhetetlenül
megjelennek,
kvázi
„kontrollálatlanul” alkalmazzák azokat. Ilyen technológiák, megoldások lehetnek például a „webkettes” közösségi oldalak, a különböző platformokat használó mobil
51
eszközök (okostelefonok, tábla PC-k), a felhasználók által fejlesztett, EUC19 alkalmazások, vagy akár az USB20 port „teljes” tiltása – amelyekre mindenképp szükséges valamilyen „megengedő” politika annak érdekében, hogy rögzíthessük a biztonságos használat szabályait. Természetesen a teljes tiltás azért is túlhaladott megoldás, mert maga a technológia teszi lehetővé, hogy az „üzletnek” partnerei legyünk:
beállíthatunk
finomabban
hangolható
tartalomszűrést
a
Webre,
felmérhetjük és konszolidálhatjuk az EUC alkalmazásokat. Valójában az USB port tiltása önmagában nem lesz eredményes, ha minden egyéb adatszivárgási csatornát – például az Internet és e-mail hozzáférést – nem tiltjuk szintén. (Zeltser, 2009.) Ez a legtöbb esetben azonban nem lehetséges, sőt véleményem szerint nem is lehet cél. Továbbá a teljes USB tiltásnak remek (bár komplex felkészülést és bevezetést igénylő) alternatívája mutatkozik a néhány éve fejlődésnek indult DLP21 megoldások képében. 4. Helyettesíthetőség: Porternél is alapvető fontosságú a helyettesítő termékek, illetve versenytársak által gyakorolt nyomás. Mi is a helyettesíthetőség: amikor egy adott problémára nem kizárólag egyetlen termék kínál megoldást – és az általunk kínáltnál
(pl.
ár-érték
arány
szempontjából)
jobb
megoldás
kínálkozik.
Információbiztonsági erőforrásaink és megoldásaink elemzése érdekében ezt a szempontot a „sebezhetőséggel” helyettesíthetjük! Tegyük fel, hogy a probléma, amelyet orvosolni kívánunk egy adott megoldás által nem más, mint valamilyen konkrét kockázat – ez valójában is így van. A külső és belső veszélyforrások (támadók) pedig a konkurenseink – ellenfeleink. Amennyiben egy támadónak ugyanarra a „problémára” jobb megoldása van, akkor a támadás sikeres lesz, rendszerünk, adataink kompromittálódnak! Ebből a gondolatmenetből nem következik más, mint hogy a támadó fejével kell gondolkodnunk, amely, bár alapigazság, szintén elsikkad a mindennapokban.
19
End-User Computing (felhasználók által fejlesztett alkalmazás) – tipiksan Excel és Access alapon a
felhasználók által létrehozott, több dolgozó által használt alkalmazások, amelyek a napi folyamatokat könnyítik meg. 20 21
Universal Serial Bus – Szabványos csatlakozó számítógép-perifériák csatlakoztatására Data Loss Prevention (néhol: Data Leakage Prevention) – az adatok jogosulatlan módon való
felhasználását, pl. kiszivárogtatását megelőző szoftver-rendszer.
52
5. Jobb versenypozíció, vagyis: kinek jobbak a biztonsági megoldásai? A biztonsági intézkedések „jóságát” jelen esetben nem kizárólag a fenyegetések által okozott kockázatok minimalizálásának képességében, hanem azon hozzáadott értékben látom, amellyel az adott szervezet valóban versenytársai előtt tud járni. Manapság mindenkinek van tűzfala és vírusirtója, tehát ezek és az ehhez hasonló „mainstream” megoldások, bár az alap biztonsági szint megvalósításához szükségesek, nem fogják emelni a biztonság szintjét és nem biztosítanak semmilyen versenyelőnyt. Véleményem szerint a versenypozíció javítását szolgáló biztonsági intézkedések kategóriájába tartozik például egy új technológia gyors adoptálási lehetőségének megteremtése annak biztonságos alkalmazási feltételeinek kidolgozásával. Erre egy friss példa az EMV szabványon22 alapuló, chippel felszerelt bankkártyák bevezetése Magyarországon. A chip kártyák rengeteg új lehetőséget biztosítanak a bankoknak a marketing, ezen belül a hűségprogramok terén – ki ne ismerné a Smart kártyát? Miután alapvetően informatikai megoldásról van szó, egy adott bank esetében történő implementálásban kulcsszerepet töltenek be az informatikai és IT biztonsági szakemberek. Ebben az esetben, ha e szakmák képviselői proaktív módon támogatják a bevezetést, akkor annak gyorsabb elvégzése által versenyelőnyhöz juttathatják saját cégüket – hiszen itt is kulcsfontosságú az elsőség, vagy legalábbis az elsők között való bevezetés. 2008. közepén a Magyarországon kibocsátott bankkártyák 34 százaléka volt chippel ellátva. (Keszy-Harmath, 2009.) Legkésőbb 2011-ben (néhány lehetséges szankció miatt) minden bizonnyal minden magyar bank át fog állni. Mindamellett hűségprogramot megvalósító alkalmazásokat a chipekre csak 2010. közepén kezdtek a haladóbb bankok integrálni. Másik, szintén a bankkártyákhoz kapcsolódó, informatikai (technikai) biztonsági szabvány a Payment Card Industry Data
Security
Standard
(PCI-DSS),
amelyet
a
kártyatársaságok
közös
munkacsoportja hozott létre annak érdekében, hogy javítsa a kártyatulajdonosok adatainak védelmét és széles körben, globálisan adoptálható, konzisztens biztonsági módszereket fogalmazzon meg. (PCI Security Standards Council, 2010.) ennek 22
EMV – az elektronikus fizetési műveletekre vonatkozó, az EMVCo nemzetközi konzorcium által
kialakított szabvány, amelynek részét képezi a chip kártyák interoperabilitását biztosító műszaki specifikáció is.
53
bevezetése szintén időszerű a magyar bankoknál. Jó példa lehet a versenyelőny megteremtéséhez egy új technikákon alapuló felhasználói tudatossági kampány is, hiszen ugyanazt és ugyanúgy ismételve nem sok javulást idézhetünk elő a biztonsági
tudatosság
terén
(sem),
ám
új
eszközökkel
kommunikálva
nagyságrendekkel hatékonyabbak és eredményesebbek lehetünk a biztonsági tudatosítás terén – és ez kihat külső ügyfeleink bizalmára is! Ha elfogadjuk, hogy a biztonságra, mint termékre (illetve szolgáltatásra) tekintsünk, felmerül a kérdés, hogyan adjuk azt el az érintetteknek? Természetesen a marketing és sales teljes eszköztárát bevethetjük, ezek részletes tárgyalása túlmutat a dolgozat keretein, ám néhány nagyon fontos szempontot mindenképpen kiemelnék. Az iparágat, amelyben működünk, ezen belül saját szervezetünket, cégünket ismernünk kell, ahhoz, hogy: 1. hatékonyan tudjunk fellépni 2. egyáltalán sikerüljön meggyőzni a vezetést, hogy szüksége van biztonság adott szintjére! Biztonsági szakemberként abból indulunk ki, hogy cégünk vezetése teljesen racionális döntéseket hoz, ezért megteszünk mindent annak érdekében, hogy előálljunk egy forintértékkel, amely a várható veszteséget írja le, és amely összevethető a biztonsági intézkedések árával. Itt a meggyőzés dinamikája ugyanaz, mint amikor egy biztosítási ügynök próbál minket meggyőzni arról, hogy inkább fizessünk most egy kisebb összeget, minthogy esetleg nagyobb kárunk származzon egy esetleges tűz vagy árvíz esetén. A mikroökonómia hasznosságelmélete szerint a fogyasztó, saját preferenciarendszere alapján ugyan, de mindenképpen racionálisan dönt, amikor kiválasztja azt a terméket, amelyik jobban kielégíti adott szükségletét. Ez azt jelentené, hogy minden egyes biztonsági beruházás jóváhagyásra találna, hiszen a racionális gondolkodás alapján „jobb ma egy veréb, mint holnap egy túzok.” Vagyis inkább költsünk ma egy (relatíve) kisebb összeget, semmint a jövőben nagyobb kárt szenvedjünk. Ez a hagyományos közgazdaságtan alapeleme, és feltételezi, hogy akár nyereségről, akár veszteségről van szó, a döntés minden esetben kizárólag a hasznosság mértékén múlik.
54
Nézzük most a következő kísérletet. Vegyünk egy szobányi embert, és osszuk őket ketté. Kérjük meg az egyik csoportot, hogy válasszon két lehetőség közül: biztos 500 dollár nyereség, vagy 50% eséllyel 1000 dollár nyereség. A másik csoportot a következő választás elé állítjuk: biztos 500 dolláros, vagy 50% eséllyel 1000 dolláros veszteség. A két kompromisszum nagyon hasonló, és a hagyományos mikroökonómia szerint a két csoportnak hasonló eredményre kell jutnia, attól függetlenül, hogy nyereségről vagy veszteségről van szó – egyszerűen vannak, akik kockáztatnak, vannak, akik nem. Ám a Daniel Kahneman és Amos Tversky által valóban elvégzett fenti kísérlet eredménye radikálisan mást mutatott. Amikor nyereségről volt szó, az emberek 85 százaléka a kisebb, de biztos nyereséget választotta, viszont amikor veszteségről, az emberek 70 százaléka a kevésbé valószínű, ám nagyobb veszteséget választotta. A fenti kísérlet alapján Kahneman és Tversky által kidolgozott elmélet a kilátáselmélet (prospect theory), amely felismeri, hogy az emberek másképp viszonyulnak a nyereséghez illetve veszteséghez. Gondolkodásunkban kialakult egy páros heurisztika. • Először: a biztos nyereség jobb, mint egy bizonytalan, de nagyobb nyereség (verébtúzok). • Másodszor: a biztos veszteség rosszabb, mint egy bizonytalan, későbbi, ám nagyobb veszteség (Inkább elfutok, és holnap ütközöm meg). Természetesen ezek nem kőbe vésett szabályok, hiszen bolond lenne az, aki elfogadna 100 dollárt ahelyett, hogy 50% eséllyel nyerjen egymilliót. Mindazonáltal, egyébként azonos feltételek mellett nyereség esetén kockázatkerülő, veszteség esetén kockázatkereső módon viselkedünk. Hogyan magyarázza a kilátáselmélet a biztonsági intézkedések vezetőknek történő „eladásának” nehézségeit? Valójában ez is egy választás: egy kisebb, de biztos veszteség (a biztonsági intézkedés vagy termék ára), és egy nagyobb, ám csak valószínű veszteség (pl. egy nagyobb biztonsági incidens miatti pénzügyi veszteség) között. Nyilvánvalóan az információbiztonság esetében a meggyőzés többet jelent: a döntéshozónak például meg kell győződnie a biztonsági intézkedés jövőbeli hatásosságáról ahhoz, hogy egyáltalán szóba jöjjön a megoldás bevezetése.
Mindazonáltal ebben az esetben is inkább
reménykedünk abban, hogy nem történik incidens, mint hogy kifizessük a biztonsági intézkedés költségeit.
55
Az egyik megoldás az, ha a félelemre apellálunk. A félelem sokkal ősibb ösztön, mint a racionális
kompromisszumra
való
készség;
ha
szemléletesen
leírjuk,
milyen
következményekkel járhat, ha egy adott biztonsági incidens bekövetkezik, sokkal jobb esélyünk van arra, hogy az azt megelőző/javító intézkedés költségét jóváhagyják. Mindazonáltal a félelemre és bizonytalanságra épített biztonsági kommunikáció nem igazán etikus, és manapság a FUD23 alapú kommunikációnál többet várnak a döntéshozók, és többet is érdemelnek! Sokkal konstruktívabb és eredményesebb megközelítés, ha a biztonságot nem egyéni („sziget-”) megoldásként vagy termékként képzeljük el, hanem minden, egyébként üzletileg hasznos megoldás integráns részeként, sőt stratégiai tevékenységként. (Schneier, 2008.)
5.6. Hogyan (és miért) mérjük a biztonságot? El kell hát szakadni a korábban említett „FUD” stratégia és a rövidtávú szigetmegoldások alkalmazásától! Ennek egyik legkézenfekvőbb módja, ha a tényekre alapozva tervezzük meg, hajtjuk végre és ítéljük meg a védelmi intézkedések eredményességét, egyenszilárdságát és azok hasznáról is számokban beszélve győzzük meg az érintetteket. Az intézkedések eredményességét „mérni” kell. Fontos, hogy bár mind a kockázatok csökkentésére irányuló intézkedések eredményességét, mind a bekövetkezett veszteségeket mérni szükséges, az előbbiek proaktívabb megközelítést jelentenek. Ez a gondolat logikusan
elvezet
a
mérőszámok
alkalmazásához.
Tapasztalatom
szerint
az
információbiztonság és általában a biztonság eredményességét ritkán igazolják mérésekkel. Vajon miért? Részben azért, mert a biztonsági szakemberek úgy gondolták, hogy a biztonság nem járul hozzá – és soha nem is tudna hozzájárulni – közvetlenül a cég pénzügyi eredményeihez. Részben talán azért, mert - mint ahogy még ma is – a biztonságra, mint egy abszolút állapotra gondolunk, amely vagy van, vagy nincs. Bár a biztonság valóban állapot, az nem kétállapotú (van – nincs), hanem ennek az állapotnak különböző, mérhető szintjei vannak. Szintén történetileg szemlélve a dolgokat, a biztonságot azért nem mérték, mert mint üzleti terület, igencsak éretlen volt. Valóban: egy üzleti funkció érettségét annak eredményességének és hatékonyságának mérésére kialakult módszereken lehet lemérni. Egy biztos: a méréseknek az információbiztonság, és tágabb 23
FUD: Fear, Uncertainty and Doubt (félelem, bizonytalanság és kétség) – gúnyos betűszó a biztonsági szakemberek félelemkeltésre
irányuló kommunikációjára, amely jelzi: rossz irányban tapogatózunk, ha csak ilyen eszközökkel igyekszünk támogatást szerezni biztonsági intézkedéseinknek.
56
kontextusban a teljes szervezet céljainak elérését kell támogatni, az azok felé való haladást megmutatni, ezért mindenképpen egységes rendszerbe kell azokat szervezni. Egy metrikákat alkalmazó keretrendszer bevezetéséhez alapvető fontosságú a vezetői támogatás, (bár önmagunk számára is hasznos számokat gyűjteni). Emellett gyakorlatias biztonsági
szabályzatokkal
kell
rendelkeznünk,
amelyek
olyan
követelményeket
tartalmaznak, melyek teljesülését számokkal is ki tudjuk fejezni, végül pedig ezeket a számokat eredmény- és akcióorientált módon kell értelmeznünk és elemeznünk – a számoknak egyértelműen mutatnia kell, merre van a fejlesztés iránya. Ugyanakkor ahhoz, hogy a teljes szervezetre kiterjedő – az 5.5. fejezetben tárgyaltak szellemében „értékes” – hatása lehessen az információbiztonsági tevékenységnek, a metrikák definiálása, lokalizálása, gyűjtése és gyakorlati hasznosítása terén bizonyos érettséget kell elérnünk; átfogó rendszerben, automatizáltan, folyamatba építve kell kezelni azokat, és a számok alapján valódi fejlődés irányába mutató célokat kell meghatároznunk. (Chew et al. 2008.) A fentiek alapján megállapíthatjuk, milyenek is a jó mérőszámok: stratégiailag fontos értékeket mérnek, automatizáltan gyűjthetőek, az érintettek által könnyen értelmezhetőek, és egyértelműen mutatják, mit is kell tenni. Az egyértelműséget segíti, ha a mérőszámok forrását és fajtáját is pontosan meghatározzuk. Mérőszámok tipikusan az alábbi fajtákba sorolhatóak: • A kontroll meglétét mutató értékek (van/nincs) • kvalitatív értékek, melyek relatív szinteket mutatnak (piros/sárga/zöld) • számértékek (csak darab, nincs teljes képünk) • százalékok (teljesebb kép, de korlátozott lehet a kockázat érzékeltetése) • benchmarkok (mutatják, hogy valójában mennyire jól teljesítünk) • kockázati szintek (nehezen állítható elő) (Axelrod, 2008.) Sok esetben valóban mérjük a biztonsági program működését leíró számértékeket. A kérdés, amelyre a választ keresem azonban az, hogy mit is mérünk valójában? Valóban az információbiztonsági programunk eredményességét mérjük, vagy mindössze a program részeként definiált feladatok végrehajtását mutató értékeket? A második szintű kontrollok, metrikák, KPI-k24 használata csak akkor segít valójában, ha azok tényleg a biztonsági stratégiánkban megfogalmazott céljaink teljesüléséről adnak információt, és nem csak 24
Key Performance Indicator: teljesítménymutató
57
azokat a számokat gyűjtjük, amelyek egyszerűen elérhetőek és számszerűsíthetőek – bár az egyszerű gyűjtés a jó metrikák fontos ismérve. Annak érdekében, hogy mérőszámainkat a vezetőség (és nem utolsó sorban magunk) számára értékessé tegyük, el kell szakadni a szimpla adatgyűjtéstől és az információn és tudáson keresztül el kell jutni a bölcsességig, amikor is elemzéseink és a jövőbeli kockázatokra vonatkozó prognózisaink közvetlenül és egyértelműen mutatnak a megfelelő, megvalósítható döntések irányába. (Sanovic, 2008.) Ez számomra azt jelenti, hogy a biztonsági intézkedések kiválasztásakor és azok eredményességének mérésekor azon szempontokat kell figyelembe venni, amelyek a tágabb üzleti értelmezés során is megállják helyüket, és elősegítik hosszú távú céljaink teljesülését. A Balanced Scorecard megközelítést alapul véve és az információbiztonságra alkalmazva egy olyan rendszert kaphatunk, amely nagy biztonsággal vezet minket előre. Magának a biztonsági szemszögű Balanced Scorecard definiálásának a következőkben tárgyalt két alapvető módja tűnik lehetségesnek.
5.6.1. Az eredeti Balanced Scorecard alkalmazása Az eredeti BSC négy vetületének alkalmazása. Itt a négy fő dimenzió megmarad, és a célok
és
mérőszámok
meghatározásakor
azt
vesszük
figyelembe,
hogy
az
információbiztonsági tevékenység a négy eredeti szempontot milyen módon támogatja – a teljes szervezet szempontjából! Ebben az esetben az információbiztonsági célok és mérőszámok definiálását és „csoportosítását” teljes mértékben alárendeljük az üzleti megközelítésnek, helyesebben annak a szemléletnek, amely az üzleti célok elérése érdekében van „kiegyensúlyozva”. Amennyiben azonban az a célunk, hogy a védelem szintjét felsővezetőknek kommunikáljuk, merőben más megközelítést, illetve nyelvezetet kell alkalmaznunk – méréseinknek például az alábbi szempontokat kell figyelembe venniük: • A márka és a cég értékét veszélyeztető tényezők • Dolgozói morál és biztonsági tudatosság • Versenyelőny és szellemi tulajdon védelme • Biztonsági incidensek pénzügyi hatásai, és biztonsági költések aránya a bevételhez képest • Jogszabályi megfelelés
58
• A biztonsági intézkedések hatékonysága és eredményessége, pl. költések vs. veszteségek • Új fenyegetések támadási módok és sérülékenységek • A biztonság általános szintjében bekövetkezett változások az utolsó jelentés óta, és azok szakértői értelmezése (Murray, 2008.) E megközelítésnek előnye, hogy jól látható, közvetlen kapcsolat alakítható ki az üzleti célok és az információbiztonsági célok között. (Jaquith, 2007.) Meglátásom szerint hátránya viszont, hogy a „súlyponti területek”, magára az IS területre nézve eltérnek azoktól, amelyek egy teljes vállalatra vonatkoztatva relevánsak. Ezért érdemes egy másik megközelítést is számításba venni: a vetületek újradefiniálását.
5.6.2. Biztonsági szempontokból definiált mutatószámrendszer Célszerű megközelítés lehet az információbiztonságra közvetlenül alkalmazható dimenziók definiálása, amelyek a már átgondolt biztonsági stratégia fő elemeit tartalmazzák. Ebben az esetben – valójában az eredeti BSC alapelveit figyelembe véve – egy teljesen egyedi mutatószám-rendszert alakítunk ki, amely nem a teljes vállalatra, hanem csak magára az IS terültre vonatkoztatva van „kiegyensúlyozva”. Ebben az esetben teljesen szabadon definiáljuk mutatószám rendszerünk dimenzióit, akár több, öt vagy hat vetületet is meghatározva. E megközelítés hátránya, hogy adott esetben az IS szemszögből definiált vetületek nem igazán ragadják meg a felsővezetők figyelmét, akik erőforrásokban gondolkodnak (pénz, idő, ember), mindazonáltal számos terület adódik, amelyek igen jól kifejezhetőek számokkal, és amelyeket szükséges is számításba venni és mérni. Tapasztalatom szerint ilyen mérhető területek például: • a rendszerek állapota (pl. sérülékenységi szintje), • a jogszabályoknak, belső szabályzatoknak, illetve üzleti céloknak való megfelelés szintje, • a biztonsági költések szintje és trendje, • az incidensek detektálásának, és lokalizálásának ideje, • az aktuális kockázati szintek és az egyes kockázatok elfogadására tett vezetői nyilatkozatok kockázati szintje illetve száma
59
60
6. Összefoglalás Jelen dolgozat megírása során az információbiztonsági terület különféle problémáinak összegyűjtése és az egyéb szakterületeken analóg, adott esetben megegyező problémákra alkalmazott megoldások két, egymástól gyakorlatilag független halmaza között sikerült átjárást teremtenem. Az 5.1. fejezetben definiált mátrix közvetlenül szemlélteti ezt és számos új gondolkodási irány felismerését teszi lehetővé. Ezen „egyedi” megoldások egységes stratégiába való szervezéséhez tártam fel az 5.2. fejezetben az üzleti stratégiával és célokkal való összehangolás holisztikus módszereit, amelyek a „Merre van előre?” kérdésre segítenek átfogó választ találni. Az üzleti, a marketing és szolgáltatói szemlélet integrálásával született meg az információbiztonságra, mint szervezetre vonatkoztatott ügyfél-elégedettségi felmérés gondolata. A kérdések összeállításában az IS terület, mint speciális szolgáltató szempontjából releváns területekre és tényezőkre fókuszáltam, amelyeknél a magával a szervezettel való összhang – ennél fogva a közvetlen visszajelzés – különösen fontos. Ezek a tényezők alapvetően: a közös munka minősége, az IS követelmények egyértelműsége a dolgozók és társszervezetek szempontjából és az IS szervezet és követelmények általában vett elfogadottsága és üzleti értéke. Nem elhanyagolható természetesen az informális kapcsolatokon keresztül szerezhető visszajelzés, amely sok esetben igen releváns, sőt bizonyos fajta visszajelzésekre más módon szinte nincs is lehetőség. Mindazonáltal a strukturált felmérés lehetővé teszi szélesebb populáció megszólítását, és nem utolsósorban megismételhető, „mérhető” és „prezentálható”. A felmérés eredményeinek vizsgálata után arra a következtetésre jutottam, hogy valójában „ügyfeleink” – bár nem szakmai megközelítést alkalmazva – igen pontosan tudják és meg is határozzák, hogy mely területek fontosak ahhoz, hogy az információbiztonság területéhez az adott szervezetben maradandó értéket adhassunk. Mind a csapatmunka, mind a folyamatszervezés olyan területek, amelyek nem alakulnak ki véletlenül, olyan módon pedig semmiképp, hogy jól is működjenek. Ugyanakkor, ha folyamatainkat az alapvető módszerek betartásával hozzuk létre és azokat a teljes szervezet működésébe beépítjük – akkor véleményem szerint gyakorlatilag kihúzzuk a méregfogát a legtöbb, a 3. fejezetben tárgyalt napi problémának!
61
A felmérés konkrét eredményein túlmutatóan, annak kapcsán világossá vált, hogy bár a „jó gyakorlat” ismerete, sok év gyakorlati tapasztalata és a megfelelő kapcsolati háló (jelen esetben a szervezeten belül) elengedhetetlen – az információbiztonsági célok eléréséhez legalább ennyire fontos saját „valóságunk” megismerése! A továbbiakban a minél közvetlenebb üzleti és stratégiai kapcsolatot keresve jutottam el a Balanced Scorecard módszerének alkalmazásához, és a mérőszámok, metrikák, illetve a BMIS
modell
alkalmazásához.
E
módszertanok
közös
vonásaként
az
átfogó
gondolkodásmódot fedeztem fel, amelynek fontos eleme az egységes terminológia. Számomra fontos tanulság, hogy amennyiben nem „beszéljük ugyanazt a nyelvet” akár csapaton belül, akár a teljes szervezetet, akár országosan (globálisan) magát az információbiztonsági szakmát tekintve – nincs esélyünk maradandó értéket teremteni. Végül pedig a legfontosabb tanulság, melyet levontam: az információbiztonság területén számos szabvány, ajánlás és keretrendszer létezik, amelyek saját területükön nagyon is relevánsak és adott esetben időtállóak, ám önmagukban nem elégségesek a „biztonság, mint üzleti funkció” koncepciójának és problematikájának kezeléséhez. Ezért valóban szükséges a kitekintés, a különböző egyéb szakterületek eszközeinek megismerése, azokkal való analógiák keresése és azok integrálása a továbbiakban is!
62
7. Irodalomjegyzék 1996. évi CXII. törvény a hitelintézetekről és a pénzügyi vállalkozásokról AXELROD, C. WARREN (2008): Accounting for Value and Uncertainty in Security Metrics = ISACA Journal, 2008. Volume 6. pp. 24-29. BABBIE, EARL (2008): A társadalomtudományi kutatás gyakorlata. Budapest, Balassi Kiadó. CHEW, ELIZABETH - SWANSON, MARIANNE, STINE, KEVIN - BARTOL, NADYA - BROWN, ANTHONY - ROBINSON, WILL (2008): NIST Special Publication 800-55 Revision 1: Performance Measurement Guide for Information Security, {online} http://csrc.nist.gov/publications/nistpubs/800-55-Rev1/SP800-55-rev1.pdf, letöltve: 2011.06.04. CLUB DE LA SÉCURITÉ DE L'INFORMATION FRANCAIS (2010): MEHARI 2010: Risk analysis and treatment Guide. In: CLUSIF {online} https://www.clusif.asso.fr/fr/production/ouvrages/pdf/MEHARI-2010-Risk-Analysisand-Treatment-Guide.pdf, letöltés: 2010.10.16. COLLETTE, RON - GENTILE, MIKE - GENTILE, SKYE (2009): CISO Soft Skills: Securing Organizations Impaired by Employee Politics, Apathy, and Intolerant Perspectives. USA, Auerbach Publications. COLLINS, DAVID J. - MONTGOMERY, CYNTHIA A. (2008): Versengés az erőforrások terén = Harvard Business Review Magyar kiadás, 2008 - 2009. (X. évf.) 12. szám - (XI. évf.) 1. szám - összevont kiadás. pp. 61-72. GATES, BILL (2000): Üzlet @ gondolat sebességével: Működik a digitális idegrendszer. Budapest, Geopen Könyvkiadó. GEDDES, PATRICK (1915): Cities in Evolution: An Introduction to the Town Planning Movement and to the Study of Civics. UK, London : Williams. HARRIES, SARAH - HARRISON, PETER (2008): Practical Guidance on Establishing the Val IT Value Governance Process = ISACA Journal, 2008. Volume 6. pp. 18-19. HORVÁTH & PARTNERS (2008): Controlling: Út egy hatékony controllingrendszerhez. Budapest, CompLex Jogi és Üzleti Kiadó.
63
ISACA (2009): An Introduction to the Business Model for Information Security. {online} http://www.isaca.org/Knowledge-Center/Research/Documents/Intro-Bus-ModelInfoSec-22Jan09-Research.pdf, letöltés: 2011.06.04. IT GOVERNANCE INSTITUTE (2006): IT Control Objectives for Sarbanes-Oxley. {online} http://www.isaca.org/Knowledge-Center/cobit/Documents/ITCO-SarbanesOxleyResearch.pdf, letöltés: 2011.06.04. IT GOVERNANCE INSTITUTE (2006): The Val IT Framework 2.0, {online} http://www.isaca.org/Template.cfm?Section=Val_IT3&Template=/TaggedPage/Tag gedPageDisplay.cfm&TPLID=80&ContentID=51867, letöltés: 2010.10.16. IT GOVERNANCE INSTITUTE (2007): COBIT 4.1: Magyar Változat. {online} http://www.isaca.org/Knowledge-Center/cobit/Documents/COBIiT-TranslationsCOBIT-4.1-Hungarian.pdf, letöltés: 2011.06.04. IT GOVERNANCE INSTITUTE (2007): COBIT: Control Objectives for Information and related Technology 4.1. {online} http://www.isaca.org/KnowledgeCenter/cobit/Documents/CobiT_4.1.pdf, letöltés: 2011.06.04. ITB (1994): Informatikai Tárcaközi Bizottság ajánlásai: Informatikai biztonsági módszertani kézikönyv, 8. sz. ajánlás , {online} http://www.itb.hu/ajanlasok/a8/, letöltés: 2010.10.16. ITB (1996): Informatikai Tárcaközi Bizottság ajánlásai: Informatikai rendszerek biztonsági követelményei, 12. sz. ajánlás, 1.0 verzió, {online} http://www.itb.hu/ajanlasok/a12/, letöltés: 2010.10.16. JAQUITH, ANDREW (2007): Security Metrics: Replacing Fear, Uncertainty and Doubt. USA, Addison-Wesley. KAPLAN, ROBERT S. - NORTON, DAVID P. (1998): Balanced Scorecard -Kiegyensúlyozott stratégiai mutatószám-rendszer: Eszköz, ami mozgásba hozza a stratégiát. Budapest, Közgazdasági és Jogi Könyvkiadó. KARK, KHALID (2009): Twelve Recommendations For Your 2009 Information Security Strategy. USA, Forrester Research Inc. KELVIN, LORD (1883): Electrical Units of Measurement. In: PLA, vol.1. 1883. 05.03. KESZY-HARMATH ZOLTÁNNÉ (2009): A fizetési kártya üzletág Magyarországon (2008. év). {online} http://www.mnb.hu/Root/Dokumentumtar/MNB/Statisztika/mnbhu_statisztikai_idos
64
orok/mnbhu_penzadatok/mnbhu_fizkar_2008/a_fizetesi_kartya_uzletag_magyarorsz agon_2008_2009.pdf, letöltés: 2011.06.04. KIB (2008): Közigazgatási Informatikai Bizottság 25. számú Ajánlása, {online} http://www.ekk.gov.hu/hu/kib/KIB-25-0_MIBA_v1_vegl.pdf, letöltés: 2011.06.04. KISS IMRE (2007): Az üzleti informatika elmélete a gyakorlatban. Budapest, Információs Társadalomért Alapítvány. MAGYAR SZABVÁNY MSZ ISO/IEC 27001:2006 Informatika. Biztonságtechnika. Az információbiztonság irányítási rendszerei. Követelmények. Budapest, Magyar Szabványügyi Testület. MUHA LAJOS (2010): Az informatikai biztonság egy lehetséges rendszertana, In: Bolyai Szemle, 2008. (XVII. évf.) 4. szám {online} http://portal.zmne.hu/download/bjkmk/bsz/bszemle2008/4/10_Muha_Lajos.pdf, letöltés: 2011.06.04. MURRAY, WILLIAM HUGH (2008): Measuring Security. In: Fitzgerald, Todd - Krause, Micki (szerk.), CISO Leadership: Essential Principles for Success. pp. 193-208. USA, Auerbach Publications. PAPP-VÁRY ÁRPÁD (2008): Marketing a gyakorlatban. Budapest, Századvég Kiadó. PCI SECURITY STANDARDS COUNCIL (2010): Payment Card Industry (PCI) Data Security Standard: Requirements and Security Assessment Procedures Version 2.0 {online} https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf, letöltés: 2011.06.04. PIRONTI, JOHN P. (2010): Developing an Information Security and Risk Management Strategy = ISACA Journal, 2010. Volume 2. pp. 28-35. PSZÁF (2007): A Pénzügyi Szervezetek Állami Felügyeletének 1/2007. számú módszertani útmutatója a pénzügyi szervezetek informatikai rendszerének védelméről, {online} http://www.pszaf.hu/data/cms179364/pszafhu_utmut_107cobit.pdf, letöltve: 2010.10.16. PURSER, STEVE (2004): A Practical Guide to Managing Information Security. USA, Artech House. RIES, AL - RIES, LAURA (2005): A pr tündöklése, a reklám bukása. Budapest, Geomédia Kiadói Rt.
65
SÁNDORI ZSUZSANNA (2001): Mi a tudásmenedzsment?, In: Magyar Elektronikus Könyvtár {online} http://mek.oszk.hu/03100/03145/, letöltés: 2010.10.15. SANOVIC, RANDY (2008): The Importance of an IT Security Strategy. In: Fitzgerald, Todd - Krause, Micki (szerk.), CISO Leadership: Essential Principles for Success. pp. 163-169. USA, Auerbach Publications. SCHNEIER, BRUCE (2000): Semantic Attacks: The Third Wave of Network Attacks, In: Crypto-Gram Newsletter {online} http://www.schneier.com/crypto-gram0010.html#1, letöltés: 2010.10.16. SCHNEIER, BRUCE (2008): How to sell information Security, In: CIO.com {online} http://www.cio.com/article/367913/How_to_Sell_Security, letöltés: 2010.10.16. SENGE, PETER M. (1998): Az 5. alapelv. Budapest, HVG Rt. SHOSTACK, ADAM - STEWART, ANDREW (2008): The New School of Information Security. USA, Addison-Wesley. SINGLETON, TOMMIE W. (2009): What Every IT Auditor Should Know About Controls: The CDLC = ISACA Journal, 2009. Volume 3. pp. 13-14. TAPSCOTT, DON - WILLIAMS, ANTHONY D. (2007): Wikinómia: Hogyan változtat meg mindent a tömeges együttműködés. Budapest, HVG Kiadó Zrt. THORP, JOHN (2003): The Information Paradox: Realizing the Business Benefits of Information Technology. USA, McGraw-Hill Ryerson. VASVÁRI GYÖRGY (2005): Informatikai biztonsági kockázat példatár {online} http://www.infota.org/biztmen/docs/VF_Peldatar_1.pdf, letöltés: 2010.10.10. VASVÁRI GYÖRGY (2009): Tévhitek az információról, a biztonságról. Budapest, Információs Társadalomért Alapítvány. VASVÁRI GYÖRGY (2010): Vasvári György 2010. 04. 19-én az ISACA rendezvényén a humán biztonságról tartott előadása. Budapest. WIKIPÉDIA (2011): Crowdsourcing, In: Wikipedia, The Free encyclopedia {online} http://en.wikipedia.org/wiki/Crowdsourcing, letöltés: 2011.06.25. WIKIPÉDIA (2011): Web 2.0, In: Wikipedia, The Free encyclopedia {online} http://en.wikipedia.org/wiki/Web_2.0, letöltés: 2011.06.25. ZELTSER, LENNY (2009): How to Suck at Information Security, In: ISC Diary {online} http://isc.sans.org/diary.html?storyid=5644, letöltés: 2010.10 16.
66
8. Mellékletek 8.1. Az információbiztonsági szervezet eredményességének és elismertségének felmérésére összeállított kérdőív
Forrás: saját elemzés.
67
8.2. COBIT érettségi modell A COBIT érettségi modell mind magyar, mind angol verzióját fontosnak tartom bemutatni, az angol szöveg lényegre törőbb és pontosabb volta miatt. Általános érettségi modell 0 Nem létező — Egyáltalán semmilyen felismerhető folyamat sincsen. A vállalkozás még fel sem ismerte azt, hogy létezik egy olyan terület, amellyel foglalkoznia kell. 1 Kezdeti/Ad Hoc jellegű — Vannak jelek arra vonatkozóan, hogy a vállalkozás felismerte, hogy létezik egy olyan terület, amellyel foglakoznia kell. Azonban nincsenek szabványosított folyamatok, helyettük ad hoc jellegű megoldásokat alkalmaznak, egyedileg, illetve eseti alapon. Az általános vezetési módszer rendszertelen. 2 Ismétlődő, de ösztönös — A folyamatok eljutottak arra a szintre, amikor hasonló eljárásokat követnek a különböző, azonos feladatokat végző emberek. A szabványos eljárásoknak nincsen formális oktatása, nincs rendszeres ismertetés es tájékoztatás róluk, es betartásuk az egyének felelőssége. Nagy mértékben hagyatkoznak az egyének tudására, és ezért hibák valószínűek . 3 Szabályozott folyamat — Az eljárások szabványosítottak és dokumentáltak, a megismertetésük képzésen keresztül történik. Előírták, hogy ezeket a folyamatokat követni kell, azonban nem valószínű, hogy az eltéréseket felismerik. Az eljárások maguk nem kifinomultak, hanem a létező gyakorlat formalizált változatai. 4 Irányított és mérhető—A vezetés figyelemmel kíséri, és méri az eljárásoknak történő megfelelőséget, és intézkedik, amennyiben úgy tűnik, hogy a folyamatok nem működnek eredményesen. A folyamatokat állandóan javítják, és azok bevált gyakorlatot testesítenek meg. Az automatizálás, és az eszközök használata korlátozott, vagy a folyamat egyes elemeire terjed csak ki. 5 Optimalizált—A folyamatokat tökéletesítették a bevált gyakorlat szintjéig, a folyamatos javítás és a többi vállalathoz viszonyított érettségi modellezés eredményei alapján. Az informatikát integrált módon alkalmazzák a munkafolyamat automatizálására, és eszközöket adnak a minőség, és az eredményesség javításához, mellyel a vállalkozást képessé teszik arra, hogy gyorsan alkalmazkodjék. Forrás: A COBIT 4.1 magyar változata. (IT Governance Institute, 2007:31.) Generic Maturity Model 0 Non-existent—Complete lack of any recognisable processes. The enterprise has not even recognised that there is an issue to be addressed. 1 Initial/Ad Hoc—There is evidence that the enterprise has recognised that the issues exist and need to be addressed. There are, however, no standardised processes; instead, there are ad hoc approaches that tend to be applied on an individual or case-by-case basis. The overall approach to management is disorganised. 2 Repeatable but Intuitive—Processes have developed to the stage where similar procedures are followed by different people undertaking the same task. There is no formal training or communication of standard procedures, and responsibility is left to the individual. There is a high degree of reliance on the knowledge of individuals and, therefore, errors are likely. 3 Defined Process—Procedures have been standardised and documented, and communicated through training. It is mandated that these processes should be followed; however, it is unlikely that deviations will be detected. The procedures themselves are not sophisticated but are the formalisation of existing practices. 4 Managed and Measurable—Management monitors and measures compliance with procedures and takes action where processes appear not to be working effectively. Processes are under constant improvement and provide good practice. Automation and tools are used in a limited or fragmented way. 5 Optimised—Processes have been refined to a level of good practice, based on the results of continuous improvement and maturity modelling with other enterprises. IT is used in an integrated way to automate the workflow, providing tools to improve quality and effectiveness, making the enterprise quick to adapt. Forrás: A COBIT 4.1 eredeti angol változata. (IT Governance Institute, 2007:19.)
68
Forrás: A COBIT 4.1 magyar változata. (IT Governance Institute, 2007:34.)
69
Forrás: A COBIT 4.1 eredeti angol változata. (IT Governance Institute, 2007:21.)
70
8.3. A
BMIS
modell
elemeinek
összefoglaló leírása
71
és
azok
kapcsolatának
Forrás: (ISACA, 2009:15-17.)
72
