Hogyan építsünk ki magas biztonsági szintet?

Az ezredforduló elején, az elektronikus kereskedelem robbanásakor a különféle kártyatársaságok egyenként saját maguk dolgozták ki és fejlesztették folyamatosan a kártyakezelés informatikai biztonságát. A programok célja az volt, hogy egy világos és lényegre törő biztonsági követelmények kidolgozásával technikailag, valamint a megfelelőség számonkérésével jelentősen emeljen a kártyás fizetések biztonságán.

A Visa, Mastercard, American Express, Discover és JCB azonban úgy döntöttek, feleslegesen redundáns munkát végeznek, így egyesítették erőfeszítéseiket, hogy összehangolják ezeket a programokat. Ennek eredményeként született meg a Payment Card Industry Security Standards Council (PCI SSC) szervezet, amely 2004 végén kiadta a PCI Data Security Standardet (PCI DSS), kodifikálva az előírásokat, amelyeknek a bankoknak, mint kibocsátóknak, a tranzakciókat kezelő szolgáltatóknak és a kereskedőknek is meg kell felelniük - a PCI DSS mindenkire vonatkozik, aki bármilyen formában kártyákat kezel.

Itthon alig ismerik

A rendszeresen frissített PCI DSS az elmúlt évek az egyik leggyakrabban hivatkozott IT-biztonsági sztenderdje, amelynek megléte esetén a mai napig nincs egyetlen ismert eset sem, mikor adatlopás történt volna, mondta el Krasznay Csaba, a HP biztonsági tanácsadója. Ennek ellenére a hazai cégek részéről csekély az érdeklődés a PCI DSS iránt, amit az április végén Budapesten megrendezett nemzetközi PCI DSS képzésen megjelent magyar szakemberek csekély száma is jelez. Ez főként azért is furcsállható, mert a kártyákkal kapcsolatba kerülő cégek, kereskedők, bankok és IT-üzemeltetők súlyos, akár több tíz- vagy százmillió forintos büntetéseket kockáztatnak, ha kiderül, hogy egy adatlopás áldozatául esnek, miközben IT-rendszerük biztonsága nem felelt meg a PCI DSS előírásainak.

A helyzetért az is felelős lehet, hogy miközben Magyarországon rendkívül szigorú szabályozás alakult ki a személyes adatok kezelésével kapcsolatban, addig nem kötelező nyilvánosságra hozni azokat az incidenseket, amelyekben személyes adatokat loptak el, mondta el Wollner László, a HP biztonsági és kockázatkezelési üzletágának vezetője. Az Egyesült Államokban tavaly 1,8 millió személyes rekordot tulajdonítottak el az Identity Theft Resource Center statisztikái szerint. Wollner hozzátette, hogy a döntéshozók hajlamosak ráadásul a biztonsági szintet fokozó aspektusokat elsőként kihúzni a fejlesztési projektekből, mivel úgy érzik, már elegendőt költött a vállalat a területre. Krasznay szerint sok helyen még mindig úgy gondolják, hogy a biztonság egyenesen arányos a telepített tűzfalak számával.

A PCI DSS alkalmazása beoltható az átfogóbb és általánosabb ISO 27002-be, de annál fókuszáltabb és konkrétabb, így sokkal többet segít abban, mit is kellene tenni a biztonság elérése és fenntartása érdekében. Összesen 12 fő pontba (és több mint 300 alpontba) szedi össze a PCI DSS a biztonság alapvető követelményeit, amelyek elvárása valójában triviális, átgondolt implementációja azonban rengeteg átgondolást, tervezést és munkát követelhet meg. A PCI DSS nem terjed ki a biztonság minden területére és részletére, azonban erős alapot jelent.

Az alapok

Wollner szerint a biztonság alappillérei közül az első az átfogó, minden felhasználóra kiterjedő azonosság- és jogosultságkezelés a korlátozás és elszámoltathatóság érdekében. Mint mondja, \"ha ez nincs meg, nem tudni, ki és mit tesz a rendszerben\". A második a kiterjedt naplózás és naplóelemzés, amely az utólagos detektívmunkát teszi lehetővé, a harmadik pedig a biztonságos adatkezelési mechanizmusok kidolgozása - erősen titkosított adattárolás és adatátvitel.

Mint minden biztonsági \"best practice\", úgy a PCI DSS egyik sarkalatos pontja is, hogy a szoftverekhez mindig telepíteni kell a biztonsági foltozásokat, valamint meg kell bizonyosodni, hogy azok nem esnek áldozatul az ismert támadási technikáknak, mint például az SQL injekció, URL paraméterezés vagy a webes XSS támadások. Ehhez kapcsolódik, hogy a biztonságot szem előtt tartó fejlesztési modellt kell követni, Krasznay szerint ez azonban Magyarországon lehetetlen, alig páran vannak, akik a biztonságos szoftverterek tervezésének és fejlesztésének akár minimumával is tisztában lennének, és a cégek sem fizetik meg ezt a tudást.

Ha támadható az alkalmazás, de a szállító nem biztosít még vagy már patchet hozzá, vagy az alkalmazáshoz nem lehet vagy érdemes hozzányúlni, akkor sincs minden veszve. Ekkor az úgynevezett támadási vektorokat kell megszüntetni, vagyis a támadható alkalmazás köré egy védelmi vonalat húzni, amely kiszűri például a rosszindulatú kódokat, parancsokat. Az egyik bevált megoldás, mondta el Wollner, hogy egy vállalati alkalmazást azért alakítanak webes felületűvé, hogy így szigeteljék el azt és akadályozzák meg a nem kívánt működést egy sokkal szigorúbb webes szabályozással.

Bár a PCI DSS megfelelőségnek nincsenek fokozatai, vagyis vagy megfelel a rendszer, vagy nem, rossz válasz, hogy egy adott szoftver vagy hardver sebezhetősége esetén azt azonnal el kell dobni, ha nem teljesíti a követelményeket - különösen igaz ez az előbb említett alkalmazások esetében. A biztonsági szakembereknek tudniuk kell priorizálni, és fejlesztési tervet készíteni, amely fokozatosan csökkenti a kockázatokat, véli Wollner, aki szerint sok helyen látszatbiztonságot tartanak fenn feleslegesen összevásárolt biztonsági termékek telepítésével. Ugyanakkor a HP Magyarország sem rendelkezik PCI DSS megfelelőséggel, mivel nem végez kártyás értékesítési tevékenységet.

A PCI DSS részletes követelményei, valamint az implementációt segítő támogató anyagok szabadon letölthetőek a PCI SSC weblapjáról.