Nyilvános dokumentum
U tmutató a „Biztonsá gos kó dolá shoz” harmadik fé l á gazatok ré szé re Végleges kiadás: 1.0 Kelt: 2016.10.19. BT Biztonsági Osztály
1
Nyilvános dokumentum
Tartalom 1.
Bevezetés ..................................................................................................................................................................................................... 3 1.1.
Háttér ..................................................................................................................................................................................................... 3
1.2.
Célkitűzések .......................................................................................................................................................................................... 3
1.3.
További anyagok és tanács ................................................................................................................................................................... 4
2.
Rendszertervezés ..................................................................................................................................................................................... 5
3.
Rendszerfelépítés ................................................................................................................................................................................... 13
4.
Rendszerbiztosítás .................................................................................................................................................................................. 19
5.
Függelékek: ............................................................................................................................................................................................. 20
5.1.
Hozzáférés-ellenőrzés ......................................................................................................................................................................... 20
5.2
Titkosítás ............................................................................................................................................................................................. 23
5.2.1
Webes titkosítási szabályok.............................................................................................................................................................. 24
5.2.2
Általános kulcskezelés ................................................................................................................................................................... 255
A dokumentumokra vonatkozó szabályok ....................................................................................................................................................... 27
2
Nyilvános dokumentum
1. Bevezetés 1.1.
Háttér
A jelen dokumentum útmutatást ad a BT részére alkalmazásokat vagy rendszereket szállító harmadik felek által folytatott szoftverfejlesztéssel kapcsolatos legjobb gyakorlatokhoz. Az alkalmazási réteg sérülékenységein keresztül illetéktelen személyek rendkívül hatékony módon férhetnek hozzá az adatokhoz vagy rendszerekhez. Ezért egyre fontosabb, hogy a biztonsági megfontolások a szoftverfejlesztés módjának meghatározásakor központi szerepet játsszanak.
1.2.
Célkitűzések
Jelen dokumentum megkísérel olyan útmutatót adni a szoftverfejlesztéshez, amely által a létrejövő kód megbízható és biztonságos lesz. Egy szoftverfejlesztési projektnek számos vetülete van, továbbá gyorsan változó terület, így amennyire lehetséges, kiemeltünk egy csokor magas szintű alapelvet a szoftverprojektek különböző szintjeihez kapcsolódóan. A dokumentum három fő részből áll: Rendszertervezés Ez a rész útmutatást nyújt egy szoftverprojekt elindításához, és jó néhány területet kiemel, amelyeket még az első leütés előtt végig kell gondolni. Ezeket a lépéseket követve a projekt későbbi szakaszaiban könnyebb lesz biztosítani, hogy a leszállított kód biztonságos legyen. Rendszerfelépítés Ez a rész foglalkozik magával a kódolással. Tartalmaz néhány általános alapelvet (például a forráskódkezeléssel kapcsolatban), továbbá azzal is foglalkozik, hogy hogyan kerülhető el néhány gyakran tapasztalt hiba/probléma. Rendszerbiztosítás Ez a rész foglalkozik a telepítéssel és az Ön által előállított kód kezelésével éles környezetben. Ez a konkrét szerződéstől függően nem biztos, hogy mindig releváns lesz, de Önnek minden esetben meg kell győződnie arról, hogy az alkalmazása vagy rendszere képes ezeknek az irányelveknek megfelelően működni. Emellett számos függeléket is beemeltünk, amelyek a hozzáférés-kezelésre és titkosításra vonatkozó BT-specifikációkat ismertetik. Fontos gondoskodnia arról, hogy az alkalmazása megfeleljen ezeknek a szabályoknak 3
Nyilvános dokumentum
1.3.
További anyagok és tanács
A dokumentumban található hivatkozások szerint.
4
Nyilvános dokumentum
2. Rendszertervezés Hiv. sz. 1.
Szabályozás Az adatokat az Ön szervezetén belül meghatározott Adatminősítési szabványnak megfelelően kell minősíteni. Ez kiterjed a tervezési és fejlesztési információkra (pl. tervek, problémák, követelmények), valamint az alkalmazás adataira is.
Indokolás Ha megérti, hogy milyen típusú adatokat tárol majd az Ön rendszere, akkor megalkothatja a megfelelő rendszervédelmet. A tervezési és fejlesztési információ (különösen az érzékeny ügyek) biztonságba helyezése fontos, mivel az illetéktelen hozzáférés segíthet valakit abban, hogy az alkalmazást célba vegye.
Az adatokat az Információmegőrzési szabályzattal összhangban kell kezelni.
2.
Minden jogszabályi és hatósági követelményt azonosítani kell.
3.
A tervezési folyamat során át kell gondolni, hogy van-e a projekten dolgozó emberekre vonatkozó biztonsági követelmény (pl. csak egyesült királyságbeli lehet, vagy ha biztonsági átvilágítás szükséges). Használjon kockázatelemzési technikákat a biztonsági kockázatok részletes azonosítására és mennyiségi felmérésére. Dokumentálja a kockázatokat és azok javasolt csökkentését.
4.
Bizonyos típusú adatok (pl. hitelkártyaadatok) kezelését végző alkalmazások írása során olyan konkrét jogszabályi/hatósági előírásokat kell követni, amelyek befolyásolják az adatkezelés módját. Az érzékeny vagy kormányzati jelölésű információt kezelő projektekre vonatkozóan érvényben lehetnek a projektben foglalkoztatottakra vonatkozó követelmények. Minden egyes alkalmazás más kapcsolódó kockázatokat hordoz (pl. a környezet, amelyben fut; a kezelt adatok szintje). Fontos gondoskodnia ezek átgondolásáról és az ellenük való védekezési mód meghatározásáról. A kockázatelemzés a környezettől függően változhat, ehhez számos rendelkezésére álló eszköz nyújthat segítséget. Az OWASP létrehozott
5
Nyilvános dokumentum
egy útmutatót a kockázatok azonosításához és elemzéséhez, amely tartalmaz egy hasznos fejezetet az értékelésükre vonatkozóan is. Egy másik lehetőség a Microsoft által kifejlesztett eszköz, amely segít azonosítani az alkalmazást érintő fenyegetéseket, és egy másik, amely segít megérteni a támadási felületeket az új alkalmazások telepítése előtt Kérdés esetén vagy ha a módszerekkel kapcsolatos tanácsra van szüksége, forduljon a szabvány felelőséhez. Megjegyzés: A használandó technika projektspecifikus lehet, például IS1 a HMGakkreditált munkákhoz (HMG – Her Majesty's Government, az Egyesült Királyság kormánya). Ezzel biztosíthatja, hogy a kockázatok listája naprakészen követi az alkalmazást vagy annak környezetét érintő változásokat. Új kockázatokat és azok kezelésére tett intézkedéseket adhat hozzá. Ezzel biztosíthatja, hogy Ön az azonosított kockázatoknál következetesen a megfelelő kezelési módszereket alkalmazza.
5.
Határozza meg és dokumentálja a kockázatok felülvizsgálati ütemtervét
6.
A fent felsorolt kockázatok kezelése érdekében dokumentálja a biztonsági architektúrát Dolgozzon ki biztonsági útmutatásokat az alábbiakra: Alacsony szintű megoldások/megvalósítás Segít továbbá az elfogadási teszt kidolgozásában. Megbízható könyvtárak Elfogadható rejtjelkulcsok Elfogadható hash algoritmusok Minimális kulcshosszúságok Kulcskezelési eljárások Tárolás elkülönítése/titkosítása Belépési adatok hozzáférhetősége/továbbítása 6
Nyilvános dokumentum
Elfogadhatatlan protokollok 7.
8.
Határozza meg és foglalja írásba a fejlesztési életciklust
Egy kidolgozott fejlesztési életciklus azt jelent, hogy van egy következetesen ismételhető megközelítés, amellyel a követelményektől/problémáktól kiindulva eljuthatunk a gyártási megoldáshoz. Enélkül a biztonsági problémák megoldása bonyolult és időigényes lehet.
Dokumentálja és vezesse be a következő tervezési eljárásokat: Hozzáférés-kezelés (ki melyik részéhez fér hozzá az alkalmazásnak, a hozzáférés igénylésének, karbantartásának és visszavonásának módja) – ha ezt nem kezelik, akkor valószínű, hogy a végén az emberek nem a megfelelő hozzáféréssel rendelkeznek majd (pl. a felhasználók képesek lesznek rendszergazdai feladatokat ellátni, vagy munkahelyváltás után megmarad a hozzáférés). Óraszinkronizáció – ha az órák nem pontosak, az nagyon megnehezíti a problémák naplófájlokon keresztüli azonosítását, különösen ott, ahol más rendszereken folytatott tevékenységekkel kell korrelációt teremteni. Adatátvitelek – az átvitel során az adatokat a minősítésüknek megfelelő védelemmel kell ellátni. 7
A Microsoftnak van egy modellje, amely kiindulási pontként használható. Az alkalmazás biztonsága erősen függ attól, hogy éles környezetben hogyan kezelik. A javasolt folyamatok meghatározásával és bevezetésével Ön gondoskodhat arról, hogy a tervezési és a bevezetési fázisban végzett munka ne vesszen kárba az alkalmazás futtatása során. Ezek közül sokat a „józan ész” diktál, és természetszerűleg követi az ember. Azonban fontos explicitté tenni ezeket a folyamatokat, és gondoskodni arról, hogy azokat az alkalmazás élete során végig kövessék (például akkor is, ha a támogató csapat változik).
Nyilvános dokumentum
Eszközök és technikák a rendszer elleni támadáshoz – ez kezdetektől fogva segít majd Önnek megelőzni a próbálkozásokat, és enyhíteni azok hatását. Vészhelyreállítás/tartalék eljárás – ezt egyértelműen meg kell határozni és tesztelni kell, hogy a rendszer képes legyen reagálni a váratlan helyzetekre. Dokumentálja és valósítsa meg a következő fejlesztési eljárásokat: Tesztelő eszközök beemelése a folyamatos integrációba – egy automatizált build környezet lehetővé teszi, hogy mielőtt az alkalmazást kiadják, minden build automatikus tesztelésen essen át a gyakori hibákra vonatkozóan. Statikus és dinamikus biztonsági elemzési eszközök alkalmazása a fejlesztési folyamatban – ez segíti a sérülékenységek felderítését a fejlesztés korai szakaszában. Biztonsági problémák címkézése a forrásadattárban és a problémakövetésben – a biztonsági hibák címkézésével felmérhetővé válik az enyhítő/megoldó intézkedések hatékonysága. Emellett a projekt kockázatelemzéséhez is visszacsatolhatnak, és más fejlesztőkkel is megoszthatják a gyakori hibákat, növelve ezzel az általános éberséget. Szakmai ellenőrzési folyamatok alkalmazása – a kód szakmai ellenőrzése olyan hibákat is azonosíthat, amelyek automatikusan nem deríthetők fel, és 8
Nyilvános dokumentum
megelőzheti a kódolási hibákból eredő sérülékenységeket, például a logikai hibákat. Telepítés jogtiszta build környezetből – egy jogtiszta, megbízható build környezet használata csökkenti annak kockázatát, hogy az output olyan kártékony szoftverrel, nem kívánatos/régi könyvtárakkal vagy komponensekkel legyen fertőzött, amelyek hibákat eredményezhetnek vagy sérthetik a programbiztonságot. A legjobb gyakorlatok és tapasztalatok megosztása – ez segíthet a közösségnek elkerülni a sérülékenységet eredményező gyakori hibákat. Dokumentálja és valósítsa meg az alábbi, éles környezetben alkalmazandó kezelési eljárásokat: Biztonsági javítások időszerű alkalmazása, beleértve a harmadik fél által gyártott komponensekét is – ez megoldja az olyan biztonsági problémákat, amelyek az alkalmazás és az alkalmazásadatok feltöréséhez vezethetnének. Hardver- és szoftverkarbantartás – fontos megtervezni a támogatott hardverek és szoftverek folyamatos rendelkezésre állását, hogy Ön javíthassa a hibákat, és megkapja a biztonsági frissítéseket. Alkalmazás indítása/leállítása – egy nem teljes alkalmazásleállás váratlan viselkedést, illetve az alkalmazásobjektumok megmaradását eredményezheti. Alkalmazás és feladatmenedzsment – 9
Nyilvános dokumentum
9.
10.
meg kell határozni azt a módot, ahogy az alkalmazás a feladatokat kezeli, különösen szokatlanul nagy terhelés esetén. Monitoring és riasztások – meg kell határozni és be kell vezetni a naplók és egyéb outputok monitorozásának és a reagálásnak a módját. Archiválás/adattisztítás – lehet, hogy az adatok kezelése során szükségessé válik azok eltávolítása vagy archiválása, ha már nincs rájuk szükség. Ezt az adatvédelmi jogszabályok is megkövetelhetik. Migráció – ez teszi lehetővé a szolgáltatás folytatását a frissítések – például egy biztonsági problémák megoldására kiadott frissítés – után. Változáskezelés – fontos, hogy az alkalmazás változtatásai ellenőrzött körülmények között történjenek, így lehetőség nyílik megérteni, hogy a változtatások szabályszerűek-e, és ha bármilyen probléma merül fel, akkor annak lehetséges okai is vizsgálhatók. A biztonsági architektúrát minden ciklusban vagy iterációnál felül kell vizsgálni és frissíteni kell. Az alkalmazás tervezett változtatásait felül kell vizsgálni és gondoskodni kell arról, hogy azok ne sértsék a biztonsági követelményeket. Ahelyett, hogy saját maga tervezne ilyet, használja az aktívan karbantartott, iparági szabványnak megfelelő biztonsági eszköztárakat. 10
Ezzel biztosítható, hogy az alkalmazás mindig követi a projekt követelményeiben vagy megvalósításában bekövetkezett változásokat.
Az általánosan használt eszköztárakat alaposan tesztelték, illetve kevésbé jellemző, hogy jelentős hibákat tartalmaznak, és bármilyen probléma felmerülése esetén gyorsan létrehozzák a
Nyilvános dokumentum
szükséges javításokat. És még időt is spórol vele!
11.
12.
13.
Csak a termékfunkciók működéséhez szükséges komponenseket és szolgáltatásokat használja. Csak annyi felületet adjon, amennyi feltétlenül szükséges. Harmadik feleknek csak olyan könyvtárait vagy komponenseit használja, amelyeket aktívan karbantartanak és támogatnak – kereskedelmi alapon támogatott szoftver esetén ez azt jelenti, hogy támogatási szerződést kell kötnie a beszállítóval az alkalmazás élettartamára.
A biztonságot kikényszerítő funkciókat a kódban a lehető legkevesebb, egyértelműen kijelölt és dokumentált helyen kell kialakítani. Dokumentálja a biztonságot kikényszerítő funkciók helyét
14.
Győződjön meg arról, hogy a harmadik féltől származó komponensek aktuális, tesztelt verzióit használják és karbantartják.
15.
A rendszerhez való hozzáférés során be kell tartani a lenti Hozzáférés-ellenőrzés és -kezelés részben meghatározott szabályokat. 11
Például: OpenSSL, OpenSSH, Solaris KCF, Windows Cryptography API, Active Directory, OpenLDAP. A szükségtelen funkciók minimálisra szorításával csökkentheti az alkalmazás kitettségét, és enyhítheti a megtalált hibák hatását. Ez annyit tesz majd, hogy ha biztonsági problémákat találnak, akkor Ön képes lesz frissíteni az alkalmazása által használt komponenseket. Nyílt forráskódú szoftver esetén ezt néha nehéz lehet felmérni, mivel a karbantartás a közösségi aktivitáson alapul. Ha kétségei vannak, akkor csak olyan esetben használja a komponenst, ha annak karbantartását maga is el tudja végezni. A változtatások hatása könnyebben felmérhető, és a biztonsági réseket is könnyebb befoltozni. Azzal, hogy a biztonsági funkciókat minimális mennyiségű helyre szorítja, egy nagy kódbázisban könnyebb lesz megérteni és tesztelni, mint ha sok helyre szórná szét. A régebbi verziók gyakran tartalmazhatnak hibát vagy biztonsági réseket, amelyek hibákat vagy illetéktelen hozzáférést eredményezhetnek az alkalmazásban. Ez biztosítja, hogy csak az arra felhatalmazott személyek férjenek hozzá az alkalmazásadatokhoz.
Nyilvános dokumentum
16.
A rendszer alapértelmezett telepítése csak minimális hozzáférési jogok megadásával járhat.
17.
A szoftver csak a meghatározott feladatának végrehajtásához szükséges hozzáférési jogokkal fusson.
18.
19.
20.
Ahol emelt szintű hozzáférési jog szükséges, ott azt egy jól ismert módon kelljen megszerezni, a biztonsági architektúrában dokumentáltak szerint, majd a lehető leghamarabb meg kell azt szüntetni. A folyamatosan magas szintű hozzáférési jogokat követelő feladatokat el kell választani a fő alkalmazásszoftvertől, és a legszigorúbb szakmai ellenőrzésnek kell alávetni. Fordítson különösen nagy figyelmet azokra a feladatokra, amelyek nem megbízható szoftver(ek)re hivatkoznak/hivatkoznak vissza. Hozzon létre egy tesztelési tervet az alkalmazásához, beleértve az Ön által bevezetett biztonsági szabályok vagy intézkedések kipróbálására kihegyezett teszteket is. Határozzon meg olyan biztonsági határokat, amelyek lehetővé teszik az alábbiak szabályozását: Adathozzáférési jogosultságok Üzenetek hitelessége és integritása Az inputok és outputok ellenőrzése
12
Ez csökkenti annak a kockázatát, hogy egy alapértelmezett telepítés szükségtelenül magas szintű hozzáférést eredményez. Ha magas szintű hozzáférés szükséges, akkor azt külön engedélyezni kelljen, ami megakadályozza, hogy a telepítés során megfeledkezzenek róla. Azzal, hogy minimális hozzáférési jogokkal fut, csökkentheti a biztonsági hibák vagy rések hatását, mivel azok kihasználása csak minimális hozzáférést eredményez.
Ezzel az intézkedéssel a fő alkalmazás egyetlen biztonsági hibája vagy rése sem eredményez majd magas szintű hozzáférést. Ha csökkenti a magas szintű hozzáféréssel futó kódok számát, azzal csökkenti annak az esélyét, hogy egy biztonsági hiba vagy rés magas szintű hozzáférést eredményez.
Ez biztosítja, hogy az alkalmazáson belül a szabályozásokat a megfelelő helyeken alkalmazzák az adatok védelme érdekében. Ha nem sikerül a szabályokat a megfelelő helyeken alkalmazni, az illetéktelen adathozzáféréshez vagy adatmódosításhoz vezethet.
Nyilvános dokumentum
21.
A rendszereknek biztosítaniuk kell az adatok integritásának karbantartását és megőrzését.
Az adatintegritás feletti gyenge ellenőrzés csaláshoz és az olyan hatósági követelmények vagy iparági szabványok nemteljesítéséhez vezethet, mint a Sarbanes-Oxley törvény, illetve a PCI DSS szabvány.
3. Rendszerfelépítés Hiv. sz. 22.
23.
24.
Szabályzat Tárolja a forráskódját korlátozott hozzáférésű környezetben annak érdekében, hogy csak az arra felhatalmazott személyek változtathassanak rajta.
Biztosítsa, hogy az összes kódváltoztatás egy nevesített személyhez köthető legyen. Minden egyes változtatásnak ellenőrizhetőnek kell lennie; az ellenőrzésnek meg kell tudnia állapítani, hogy ki, mit, mikor és hogyan csinált. Kövesse a fejlesztési környezetéhez vagy alkalmazástípusához kapcsolódó legjobb gyakorlatról szóló útmutatókat.
Gondoskodjon arról, hogy tisztában legyen a használt platformmal vagy nyelvvel kapcsolatos gyakori problémákkal.
Indokolás Ez csökkenti az illetéktelen vagy rosszindulatú kódváltoztatások kockázatát, amelyek sérthetik az alkalmazás biztonságát. Ezt a szabályozást a legkönnyebben egy olyan verziókezelő rendszer használatával érheti el, mint a Git vagy az SVN, és amelyhez a hozzáférés nevesített személyek csoportjára korlátozódik. Ez azt jelenti, hogy bármilyen kódváltoztatás (pl. olyan változtatás, amely nemkívánatos funkciót vezet be) legyen visszavezethető egy személyhez. Ezt a szabályozást a legkönnyebben egy olyan verziókezelő rendszer használatával érheti el, mint a Git vagy az SVN, és amelyhez a hozzáférés nevesített személyek csoportjára korlátozódik. Ezeket az eszköztárak beszállítói vagy más, harmadik fél csoportok gyakran publikálják; ezeket megismerve és követve könnyebben elkerülheti a gyakori problémákat. Gyakran használt útmutatók például az alábbiak: Webes alkalmazások: az OWASP top 10 a gyakori web-app sérülékenységeket ismerteti. 13
Nyilvános dokumentum
25.
26.
Használjon dokumentált, konzisztens kódszerkesztési stílust.
Használjon támogatott, megbízható eszközláncokat.
Android alkalmazások: CERT android biztonságos kódolási szabvány: Windows/Windows Phone: iOS / Mac OS X: Apple biztonságos kódolási útmutató: Linux: További információért vagy tanácsért forduljon a szabvány felelőséhez. Az alkalmazás kódbázisában következetlenül alkalmazott kódszerkesztési stílusok nehezen érthetővé tehetik az alkalmazás logikáját, és megnehezíthetik a nemkívánatos viselkedést eredményező problémák felfedezését. A legtöbb beszállító szerkesztési útmutatót is készít a nyelvhez/környezethez; ha más követelmény nincs, akkor érdemes azt használni. Néhány javasolt szerkesztési útmutató: Java – SEI CERT Oracle kódolási szabvány a Java nyelvhez C/C++ – a CERT biztonságos kódolási útmutatója vagy a MISRA-C útmutató C#: Python – PEP8 php – a CodeIgniter szerkesztési útmutatója Támogatott eszközök a készen kapható és aktívan karbantartott eszközök (egy külön beszállítótól, pl. Microsoft Visual Studio, vagy egy közösségtől, pl. GNU Compilers Collection). Megbízható eszközök a megbízható fél (pl. Microsoft, Ubuntu) által rendelkezésre bocsátott (és aláírt) eszközök, illetve azok, amelyek széles körben hozzáférhetők és jól ismert hash-ek segítségével ellenőrizhetők (pl. GCC forrásletöltések). 14
Nyilvános dokumentum
Támogatott eszközök használatával Ön megkapja a hibákat javító és más biztonsági problémákat kezelő frissítéseket. Az Ön által használt eszközök megbízhatóságának ellenőrzésével biztosítja, hogy az eszköztárak nem adnak kéretlen funkcionalitást az alkalmazáshoz. 27.
Ügyeljen az eszközláncok karbantartására.
28.
Használja azokat a nyelvi és eszközláncfunkciókat, amelyek segítenek az egyszerű problémák azonosításában és megoldásában.
29.
Használja az operációs rendszer azon funkcióit, amelyek a gyakran használt támadási vektorok elleni védekezést szolgálják.
A használat előtt gondoskodjon a build eszközökre kiadott összes biztonsági frissítés alkalmazásáról. Ez az eszközláncon belüli olyan hibák kijavítását célozza, amelyek nemkívánatos viselkedést eredményezhetnek az output binárisokban. A fordító vagy futtató környezet figyelmeztetéseit engedélyezve idejekorán felismerheti azokat a problémákat, amelyek biztonsági réseket vagy hibákat eredményezhetnek (pl. az -fstack protector a gcc-ben figyelmeztet a potenciális puffertúlcsordulási helyzetekre; vagy a /GS, illetve a /SafeSEH a VisualC++-ban, amelyek megnehezítik a veremalapú puffertúlcsordulások kihasználását). Ez operációsrendszer-specifikus, de engedélyezze az elérhető biztonsági funkciókat – pl. ASLR vagy DEP –, ezzel növelve az alkalmazása biztonságát. A Microsoft alapú operációs rendszerek támogatása elérhető itt: A linux esetében az ASLR és a DEP alapértelmezett beállításként engedélyezett (a 2.6.12 utáni kernelek esetében). A SELinux a hozzáférési szabályzatok kikényszerítésének egyik módja, és egy biztonsági rés kiaknázásának hatását lehet vele csökkenteni. A Redhat jó útmutatót készített a fejlesztési szabályzatok 15
Nyilvános dokumentum
30.
A feldolgozás előtt – a biztonsági architektúrának megfelelően – tegyen minden inputot fertőzésmentessé. A fertőtlenítés előtt konvertálja az inputokat kanonikus alakba.
31.
A biztonsági architektúrának megfelelően fertőtlenítsen minden olyan outputot, amely más rendszer inputja lesz.
32.
Alkalmazza a titkosítást a lent található titkosítás részben foglalt szabályozásoknak megfelelően.
33.
Vezessen be olyan mechanizmusokat, amelyekkel elkerülheti a kockázatos memóriaműveleteket. Lásd: OWASP
34.
A kockázati felülvizsgálatban megjelölt helyeken használjon piszkálás elleni védelmet nyújtó anti-tampering eszközöket.
témakörében. Ha a felhasználói input képezi a parancsok vagy az adatbázis-műveletek alapját, akkor az inputot nemkívánatos művelethez is felhasználhatják, ilyen pl. az SQL injection. Az inputok gyakran szokatlan alakot ölthetnek – például szerializált java objektumok –, tehát fontos, hogy átgondolja az összes olyan esetet, ahol egy felhasználó/közvetítő képes lehet tartalmat módosítani vagy injektálni. A nem konvertált inputok elkerülhetik a fertőtlenítést olyan karakterkészletek felhasználásával, amelyek kezelésére a fertőtlenítés nincs felkészítve. Ha a felhasználói inputot outputként használják (egy másik alkalmazáshoz vagy vissza a felhasználóhoz), akkor az inputot úgy manipulálhatják, hogy az az outputot fogadónál nemkívánatos viselkedést okozzon (pl. cross-site scripting támadás). A titkosítás bonyolult lehet, és megfelelő elvégzése nehéznek bizonyulhat. A vonatkozó szabályozásokat követve Ön biztos lehet abban, hogy az Ön által használt titkosítási szint megfelelő az Ön által védett információhoz. Néhány memóriaművelet azt eredményezheti, hogy egy hozzáférési jogosultsággal nem rendelkező felhasználó manipulálni tudja a memóriatartalmat. Egyes kontextusokban ez a programfutás manipulációjához (pl. ellenőrzések kihagyásához) vagy egy tetszőleges kód futtatásához vezethet. Ha megengedi a firmware vagy az alkalmazáskód módosítását, azzal lehetővé teszi a biztonsági funkciók megkerülését. Ez vonatkozhat a mobileszközökre, ahol érdemes lehet megakadályozni az alkalmazás futtatását a „rootolt” vagy 16
Nyilvános dokumentum
35.
A kockázati felülvizsgálatban megjelölt helyeken használjon visszafejtés elleni technikákat.
36.
Kerülje az ideiglenes fájlok használatát. Ne használja a tmpnam()-ot vagy más hasonló módszert a fájlnevek generálásához.
37.
Ne használjon előre definiált (nem változtatható) jelszavakat.
38.
Vezessen be olyan mechanizmusokat, amelyek megakadályozzák a hozzáférést a memóriában található adatokhoz.
„Jailbreakelt” eszközökön. Ezt érdemes megtennie, hogy megnehezítse a felhasználók számára az alkalmazás funkcionalitásának visszafejtése céljából végzett futtatókörnyezet-elemzést/hibakeresést. A visszafejtés felfedheti a biztonsági funkciókat. Azonban ne felejtse el, hogy a legtöbb visszafejtés elleni technika csak a visszafejtéshez szükséges időt tudja növelni, azt teljesen megakadályozni nem tudja, ezért nem lehet ez az egyetlen biztonsági védelem. Az ideiglenes fájlok használata az adatok széles körben történő szórásához vezethet egy lemezen, és kinyerhető lehet, ha illetéktelen személyek hozzáférnek a rendszerhez. A tmpnam() kerülendő, mivel a név generálása és a fájl megnyitása közé egy másik folyamat illeszthető be, amely a tmpnam felhasználásával egy ugyanolyan nevű fájlt hoz létre. Ez azt eredményezheti, hogy a másik folyamat képes befolyásolni a tárolt adatok integritását, vagy leolvashatja azokat az adatokat, amelyekhez nem szabadna hozzáférnie. Az alkalmazásban előre definiált jelszavak általában jól ismertté válnak, és a felhasználók megosztják azokat egymás közt. Ezzel illetéktelen felhasználók is hozzáféréshez juthatnak, illetve – mivel a jelszavak nincsenek személyhez rendelve – nehéz lesz kideríteni, hogy ki fért hozzá. Emellett a nem változtatható jelszavak nem frissíthetők és kezelhetők a fiókkezelésre vonatkozó BT útmutatónak megfelelően. A használt platformtól és kockázati felülvizsgálattól függően előfordulhat, hogy lépéseket kell tennie annak megakadályozására, hogy az alkalmazását futtató 17
Nyilvános dokumentum
39.
A hibajelentéseknek elég információt kell tartalmazniuk a probléma okának azonosításához. Azonban ahol a hibák a felhasználók előtt megjelennek, ott nem szabad túl sok információt kiadni a alkalmazás belső részeiről.
40.
41.
42.
Például ne használjon generikus kivételtípusokat konkrét hibaállapotok ismertetéséhez. A migráció előtt minden szoftvert tesztelni kell az éles környezetben.
géphez hozzáféréssel rendelkező személy érzékeny adatokat nyerjen ki a memóriából. Ezt teheti: • a már nem használt memóriarészek felülírásával; • memóriarögzítéssel; • információk védelmére létrehozott keretrendszerutasításokkal, pl. a SecureString osztály a .Net-ben. A hiányos hibajelentések problémává változtathatják a vizsgálatokat, és elrejthetik a jogosulatlan tevékenységeket. Egy kiaknázás a hozzáférés megszerzése során a korai fázisokban gyakran generál hibákat, és ha ezeket megfelelően naplózzák, akkor az segítheti a probléma vizsgálatát. Ha csak egy generikus kifejezést tartalmaz a napló, akkor nehéz lesz megérteni a hibaállapot okát. Ha a hibaállapotot egy támadás okozta, akkor nehezebb kikövetkeztetni, hogy milyen műveleteket hajtottak végre.
A teszteletlen szoftver: elfogadhatatlan biztonsági kockázatokat eredményezhet; Hajtsa végre az alkalmazástervezés nem biztos, hogy a követelményeknek során létrehozott tesztelési tervet. megfelelően működik, különös tekintettel a biztonsági regisztrációban meghatározott biztonsági követelményekre; negatív hatást gyakorolhat a már létező műveletekre. Minden biztonsági szabályt külön tesztelni A biztonsági szabályok közötti azonosítatlan kell, hogy biztosítsuk a sérülékenységeket kihasználhatják az éles megkerülhetetlenségüket. környezetben. A tesztadatokat az adatfelelős által
A tesztadatok megosztása betekintést nyújthat a 18
Nyilvános dokumentum
meghatározott időtartam letelte után törölni kell.
donorrendszer működésébe.
4. Rendszerbiztosítás Hiv. sz. 43.
Szabályozás
Indokolás
A kódban vagy annak bármelyik komponensében található azonosított biztonsági sérülékenységek a BT sérülékenységértékelési követelményeinek megfelelően kategorizálandók.
A kezeletlen sérülékenységeket az alkalmazás vagy rendszer elleni támadás során felhasználhatják.
A sérülékenységeket ezt követően az adott kategóriához rendelt időrenddel összhangban ki kell javítani. Ez lehet rugalmas is, az alkalmazás által használt platform kockázati állapotától függően. 44.
45.
46.
A változáskezelésben kifejezetten kövesse nyomon és jelölje a biztonsági problémák kijavítása érdekében tett változtatásokat. Olyan alkalmazásverziókat telepítsen, amelyeket a forrásból kiindulva, folyamatos integrációval építettek. Gondoskodjon arról, hogy az alkalmazás és az általa használt, harmadik féltől származó komponensek legfrissebb verzióját használják.
A biztonsági javítások nyomon követésével Ön képes lesz gyorsan ellenőrizni az alkalmazását/környezetét, és bizonyíthatja, hogy a változtatásokat bevezették. Telepítés egy jogtiszta build környezetből: az alkalmazás működési ciklusát egy ismert kódkészletből indulva kezdi, a problémák pedig visszavezethetők az őket létrehozó forráskódig. A harmadik féltől származó komponensek frissítésével csökken annak az esélye, hogy egy komponens biztonsági problémáját kihasználják. 19
Nyilvános dokumentum
47.
Az alkalmazás üzemeltetési környezetéhez kiadott javításokat a javítási szabályzattal összhangban alkalmazza.
48.
Az alábbi folyamatterületeket kell meghatározni és dokumentálni: A biztonsági javítások alkalmazása Hozzáférés-ellenőrzés Indítás/leállítás Időszinkronizálás, alkalmazás- és feladatkezelés Adatátvitelek Monitoring és riasztások Probléma- és eszkalációkezelés Biztonsági mentés és visszatöltés Archiválás Migráció Változáskezelés Vészhelyreállítás/tartalék eljárás Hardver- és szoftverkarbantartás Napló, felülvizsgálat és intézkedés szokatlan helyzetekben
Fontos, hogy rendszeresen alkalmazza a biztonsági javításokat, mivel a régi szoftververziók gyakran célponttá válnak. Az üzemeltetési környezet biztonsági problémája kockázatot jelenthet az alkalmazásadatokra nézve. A dokumentált működési eljárások hiánya gyakran azt jelenti, hogy fontos folyamatokat hanyagolnak el, vagy az ezek végrehajtására vonatkozó ismeret nem áll a csapat rendelkezésére.
5. Függelékek:
5.1.Hozzáférés-ellenőrzés
Hiv. sz.
Szabályzat
Indokolás 20
Nyilvános dokumentum
49.
Határozza meg a rendszerhozzáférési jogokat a felhasználók és a kapcsolódó rendszerek számára.
A rossz szerepkör-meghatározás véletlen vagy rosszindulatú műveletek végrehajtását eredményezheti a rendszerben.
A hozzáférési jogokat az alábbiak alapján kell kiosztani: A rendszer által végrehajtandó műveletek Rendszer-rendszer interakció A felhasználó információ- és rendszerhozzáférésére vonatkozó szabályzat A felhasználóknak rendelkeznie kell a munkakörük ellátásához minimálisan szükséges jogokkal 50.
A megosztott hozzáférésű emelt szintű jogokkal* rendelkező fiókokat a meghatározottak szerint kell kezelni.
Hivatalos szabályozás nélkül nehéz nyomon követni, hogy ki a felelős a biztonságot befolyásoló változtatásokért.
51.
Úgy tervezze meg az alkalmazás folyamatait, hogy azok a helyes működéshez szükséges minimális hozzáférési szinttel fussanak.
A túlzott jogosultsággal futó alkalmazásokat kihasználhatják abból a célból, hogy adatokhoz férjenek hozzá vagy rendszerjogosultságokat szerezzenek.
A rendszer által végrehajtandó műveletek Rendszer-rendszer interakció Ne használjon emelt hozzáférési szintű fiókokat az alkalmazási folyamatokhoz Dokumentálja az összes emelt szintű hozzáférést 21
Nyilvános dokumentum
A jogosultságkiterjesztés csak ismert APIkat használhat A jogosultságkiterjesztést a szükséges minimális időtartamra kell szorítani. 52.
A felhasználói munkameneteket legfeljebb 30 perc inaktivitás után meg kell szakítani. Amikor időtúllépés történik, akkor a képernyőről el kell tüntetni az összes kijelzett adatot.
Ha a rendszert felügyelet nélkül hagyják, akkor az időtúllépések korlátozzák az illetéktelen hozzáférések lehetőségét.
53.
Egy felhasználói munkamenet nem lehet hosszabb, mint 12 óra.
Ez biztosítja, hogy a felhasználók legalább 12 óránként bejelentkeznek és újra hitelesítik az adataikat.
54.
A szerepkör- és jogosultságalapú hozzáférés-kezelést minden kezelőporton biztosítani kell, legyen az helyi (Craft/konzolterminál vagy terminálszerver) vagy távoli (EMS útján)
A kitett kezelési felületek illetéktelen hozzáféréshez használhatók fel.
Az ACL-eket az összes (IP) kezelőfelületen alkalmazni kell, korlátozva a forráscímet és portot, valamint az igénybe vett protokollt; különösen az ICMP, a HTTP, a SNMP, az FTP, a TFTP, az SSH és a Telnet, valamint a fejlett útválasztó protokollok – például OSPF – hozzáférését kell korlátozni. 55.
Csak biztonságos hitelesítéssel rendelkező protokollokat használjon, pl.
A nem biztonságos kezelési protokollokat illetéktelen hozzáféréshez használhatják fel.
22
Nyilvános dokumentum
SNMP v3 (minimum AuthnNoPriv) SSHv2 – lásd a titkosításról szóló részt HTTPS – lásd a titkosításról szóló részt
5.2 Hiv. sz.
Titkosítás Szabályzat
Indokolás
56.
Az aktuális titkosítási könyvtárakat kell használni.
A titkosítási könyvtárakat rendszeresen frissítik. A szoftvercsomagok frissítése mellett az alvállalkozó útmutatása szerint el kell végezni a titkosítási csomagok rendszeres felülvizsgálatát és frissítését is.
57.
Csak az iparági normáknak megfelelő, A jóváhagyással nem rendelkező rejtjelkulcsok jóváhagyott rejtjelkulcscsomagokat sebezhetővé teszik az információkat. használjon a titkosításhoz. Például a TLS vagy SSLv2 protokollokhoz. Fogadja meg a fenti tanácsot. Kétség esetén forduljon az ITSAC-hoz tanácsért.
58.
Az új telepítésekhez a TLS legfrissebb verzióját kell használni. Az SSL V1, 2 és 3 használata tilos.
A korábbi verziók – a TLS1.0-ig bezárólag – már nem tekinthetők biztonságosnak.
59.
A perfect forward secrecyt (a sérülés utáni titkosságvédelmet) engedélyezni kell.
A perfect forward secrecy algoritmusok akkor is megakadályozzák az elkapott üzenetek dekódolását, ha a jövőben a titkos hitelesítési kulcsot feltörik.
60.
Önaláírt tanúsítványok használata tilos.
Az önaláírt tanúsítványok semmissé teszik a végponti hitelesítés előnyeit, emellett jelentősen csökkentik a magánszemélyek képességét arra, hogy egy 23
Nyilvános dokumentum
közbeékelődéses támadást felfedezzenek. 61.
A jelszavakat irreverzibilis, egyirányú Az eltárolt jelszóvédett fájlokból az információ kinyerhető, matematikai függvények (pl. hash így minden bejegyzést védeni kell a tiszta szöveges algoritmus) felhasználásával, jelszónként jelszavak kinyerése ellen. egyedi véletlenszerűségi tényezővel (Salt) kell védeni.
62.
A védett jelszavakat a rendszer konfigurációs fájljaitól elkülönítve kell tárolni, és hozzáférés-ellenőrző rendszert kell bevezetni annak érdekében, hogy a tartalmakat csak a megfelelő jogosultságokkal rendelkező felhasználók tudják olvasni és másolni.
Soha nem válhat lehetségessé a védett jelszavak megszerzése könyvtárbejárásos (directory traversal) támadással, SNMP walk útján, a beállítások kiírásával vagy egyéb olyan mechanizmussal, amely lehetővé teszi az offline feltörési próbálkozásokat.
5.2.1 Webes titkosítási szabályok
Hiv. sz.
Szabályzat
Indokolás
63.
Az eltárolt, illetve a bizalmas vagy magasabb besorolású adatok hozzáféréséhez használt sütiket biztonságosan kell továbbítani.
A sütiket számos módszerrel ellophatják, például XSStámadással vagy szaglászással (sniffing).
64.
A biztonságos és a nem biztonságos tartalmakat nem szabad egy oldalon belül keverni.
A nem biztonságos tartalom a biztonságos információ ellopását eredményezheti a tartalomból.
65.
Minden bejelentkezési és hitelesített oldalhoz TLS-t kell használni.
A TLS-használat elmulasztása a bejelentkezési kezdő oldalon lehetővé teszi, hogy a támadók úgy módosítsák a bejelentkezési űrlapműveletet, hogy az a 24
Nyilvános dokumentum
A bejelentkezési oldal és az azt követő minden hitelesített oldal kizárólag TLS-en keresztül legyen hozzáférhető. A bejelentkezési oldal és az azt követő minden hitelesített oldal kizárólag TLS-en keresztül legyen hozzáférhető.
bejelentkezési adatokat egy tetszőleges helyre küldje. A TLS-használat elmulasztása a hitelesített oldalakon a bejelentkezés után lehetővé teszi, hogy a támadók megtekintsék a titkosítatlan munkamenet-azonosítót, és feltörjék a felhasználó hitelesített munkamenetét.
66.
Az ügyfeleket figyelmeztetni kell, hogy ne tároljanak érzékeny adatokat a gyorsítótárban.
A TLS protokoll az adatoknak csak továbbítás közben biztosít titkosságot, de nem véd a potenciális ügyféloldali adatszivárgások ellen.
67.
Használjon nemzeti és nemzetközi szinten elfogadott digitális aláírási szabványokat
A nem szabványos digitális aláírási technikák méltatlan bizalmat kelthetnek az aláírás iránt; a nemzeti és nemzetközi előírások világszerte érvényes szabályokat határoznak meg a digitális aláírásokra, összefogva az import, export és belföldi titkosítási szabályozásokat.
68.
Wildcard tanúsítványok semmilyen körülmények között nem használhatók.
A wildcard tanúsítványok vonzóbb célpontot jelentenek. Ezek nem szándékolt tanúsítást nyújthatnak egy szervernek, és sérülékennyé tehetnek egy titkosítási tartományt.
A TLS-használat elmulasztása közbeékelődéses támadást eredményezhet.
Ha egy szervert vagy altartományt feltörtek, akkor az összes altartományt feltörhették. Ha a wildcard tanúsítványt vissza kell vonni, akkor az összes altartományhoz új tanúsítvány kell.
5.2.2 Általános kulcskezelés Hiv. sz.
Szabályzat
Indokolás 25
Nyilvános dokumentum
69.
Az új telepítésekhez használt titkosítási kulcsoknak meg kell felelniük a minimumkövetelményeknek, vagy túl kell teljesíteniük azokat.
A rövid vagy gyenge kulcsokat könnyen feltörhetik az adatok élettartama alatt.
70.
A szimmetrikus és aszimmetrikus kulcsokat jóváhagyott eszközökkel és könyvtárakkal kell generálni
A jóváhagyással nem rendelkező eszközök és könyvtárak potenciálisan gyenge kulcsokat generálnak.
71.
A titkosítási kulcsok használatához szükséges jelszavaknak a kulcsokéval megegyező szintű védelmet kell nyújtaniuk.
A gyenge jelszavak semmissé teszik a titkosítási kulcsok erejét.
72.
A kulcsok és a kapcsolódó anyagok biztonságáért a BT-n belül egy felső vezetőt kell felelősnek kijelölni.
Egy ilyen személy rendelkezik a kulcsok által védett adatok biztonságának jelentőségéhez mérhető tekintéllyel, lehetőségekkel és megbízhatósággal.
73.
A szenior kulcskezelőnek gondoskodnia kell arról, hogy a Részletek oszlopban felsorolt felelősségi körök végrehajtását megfelelő hátterű és megfelelően képzett személyekhez rendeljék.
Felelősségi körök Kulcskezelési szabályzat Kulcsgenerálás vagy kulcsszerzés A kulcselosztás, a kulcsidőszakok, a visszavonás és az elszámolási struktúra kialakítása Kulcskezelési eljárások létrehozása A kulcskezelés működtetése A titkos kulcsok és a kapcsolódó anyagok védelme Vészhelyzeti eljárások, például visszavonás Kulcsműveletek ellenőrzése Kulcsok visszaállítása 26
Nyilvános dokumentum
Kulcsok megsemmisítése
A dokumentumokra vonatkozó szabályok
Útmutató a „Biztonságos kódoláshoz” harmadik fél ágazatok részére Szerző: BT Biztonsági Osztály Kiadás: 1., kiadva 2016. október
27
