Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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:
Dr. Kiss Ferenc
Farkas Imre László
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
5
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ófa-
helyzetek 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
6
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
7
pszichológia, a szociológia, a tudásmenedzsment és csoportmunka vagy a marketing és pr
módszertani területeitől.
8
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
9
• 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.
10
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
11
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ő!
12
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
13
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.)
14
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.
15
• 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ó
16
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ó kontroll-
keretrendszereknek 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
17
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 szakterületnek, illetve
18
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.)
19
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
20
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
21
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
22
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?
23
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
24
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.
25
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
26
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.
27
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.
28
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ény-
definí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
29
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.
30
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.)
31
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.).
32
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.)
33
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.)
34
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 mi,
információbiztonsági szakemberek és vezetők „árulunk”, ne pedig valami teljesen mást.
35
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,
36
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
37
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!
38
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ő
szakterületek összefüggési mátrixa
Köz
gazd
aság
tan
Con
trol
ling
Bal
ance
d Sc
orec
ard
Foly
amat
szer
vezé
s
Tud
ásm
ened
zsm
ent
Töm
eges
egy
üttműk
ödés
Ren
dsze
relm
élet
Mar
ketin
g
Ügy
félo
rien
tált
műk
ödés
Szoc
ioló
gia
Pszi
chol
ógia
Szervezeti széttagoltság X X X X Erőforráshiány X X X X X X X X Reaktív működés X X X X X X X X X Széttagolt jelentési rendszerek X X X X "Papírgyár" X X X X Tudásciklusok X X X Veszélyérzet hiánya X X X X X X Elefántcsonttorony X X X X X Másodlagos kontroll hiánya X X X
39
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
40
• 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ű orvoslása, elfeledkezve az átfogó
41
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.
42
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.
43
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!
44
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.
A VAL-IT a fenti alapelvek mentén alkalmaz 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
Forrás: IT Governance Institute, 2006:9.
7. ábra: A négy „Vajon” (The four „Ares”)
45
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
46
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
47
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.
48
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:
49
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!
50
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”)?
51
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
52
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 Universal Serial Bus – Szabványos csatlakozó számítógép-perifériák csatlakoztatására 21 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.
53
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.
54
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.
55
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éb-
tú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.
56
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.
57
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ó
58
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
59
• 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
60
61
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!
62
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!
63
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-Analysis-
and-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ó.
64
ISACA (2009): An Introduction to the Business Model for Information Security. {online}
http://www.isaca.org/Knowledge-Center/Research/Documents/Intro-Bus-Model-
InfoSec-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-Sarbanes-
OxleyResearch.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-Translations-
COBIT-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/Knowledge-
Center/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
65
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.
66
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-gram-
0010.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.
67
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.
68
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.)
69
Forrás: A COBIT 4.1 magyar változata. (IT Governance Institute, 2007:34.)
70
Forrás: A COBIT 4.1 eredeti angol változata. (IT Governance Institute, 2007:21.)
71
8.3. A BMIS modell elemeinek és azok kapcsolatának
összefoglaló leírása
72
Forrás: (ISACA, 2009:15-17.)