Nincs adat- és információfeldolgozás szoftver nélkül. A szoftverfejlesztés elsősorban az algoritmusok feladatspecifikus működésére koncentrál. Ma már azonban jól ismert az a tény, hogy a programkód rossz megírása gyakran biztonsági problémákat is okoz, mint például hibás hozzáférés-szabályozás, SQL-injekció, helytelen munkamenet-kezelés és hitelesítés, cross-site scripting stb.

A biztonságos kódolási gyakorlatok nagy jelentőségét az ISO/IEC 27002 és az ISO/IEC 27001:2022 frissített információbiztonsági szabványok is kiemelik. Új információbiztonsági intézkedésként (ellenőrzés) a "Biztonságos kódolás" elvei a szoftverfejlesztésben bekerülnek az ISO/IEC 27001 A. mellékletének intézkedéskatalógusába. Olvassa el blogbejegyzésünkben, hogy milyen jelentőséggel bír ez az intézkedés az információbiztonság szempontjából, és mit jelent ez a jövőbeni auditok szempontjából.

Biztonsági rés a kódban

Az operációs rendszer szoftver, az alkalmazásszoftver vagy a beágyazott rendszerben lévő firmware minden digitális infrastruktúra elemi összetevője. A digitalizálási projektek egyre növekvő gyorsulása és a határidőkre nehezedő nyomás azonban gyakran vezet a feltétlenül szükséges információbiztonsági szempontok elhanyagolásához. A szoftverekkel szemben támasztott fejlesztési követelmények általában funkcióközpontúak és a konstruktív szempontokat hangsúlyozzák, így a potenciális biztonsági sebezhetőségek destruktív szemlélete többnyire szöges ellentétben áll a tényleges fejlesztési célokkal: sok programozónak egyszerűen szintén hiányzik a kiberbiztonság strukturált és kiélezett szemlélete.

Ilyen körülmények között a fejlesztőcsapatok nehezen tudják folyamatosan felülvizsgálni és következetesen biztosítani szoftvereik kódolását, amit jól mutat az a sok sebezhetőség, amelyet a non-profit MITRE Corporation minden évben közzétesz a CVE (Common Vulnerabilities and Exposures) listáján. Még a jól ismert szoftvergyártók rendszeres biztonsági javításai is jelzik, hogy milyen sziszifuszi feladat a biztonság szempontjából fontos hibák bezárása, nem is beszélve azok azonosításáról, még mielőtt a szoftverek piacra kerülnének.

Nyílt forráskód - egy különleges eset

Saját fejlesztésű szoftverek kódolásakor a programozók szívesen nyúlnak nyílt forráskódú könyvtárakhoz és modulokhoz. A gyakorlati előnyök nyilvánvalóak: ha nem kell újra és újra feltalálni a kereket, akkor előnyös ez a technológiai lökés, a gyorsabb fejlesztés, az alacsonyabb fejlesztési költségek, a nyílt forráskód révén nagyobb átláthatóság, valamint a nyílt szabványok és interfészek révén nagyobb interoperabilitás.

Azt is gyakran mondják, hogy a nyílt forráskódú kód nagyfokú biztonságot nyújt, mivel a kódot sok felhasználó validálta, és a nyílt forráskódú közösség rajos intelligenciája gyors és hatékony hibajavítást tesz lehetővé.

A gyakorlatban ezt a bizalmat most differenciáltan és kritikusan kell értékelni. A legsúlyosabb példa erre a 2021 novemberében felfedezett nulla napos biztonsági rés, a Log4Shell a Java alkalmazásokhoz széles körben használt Log4J naplózási könyvtárban, amelyet 2021 novemberében fedeztek fel. Bizonyára hallott már a német Szövetségi Információbiztonsági Hivatal (BSI) által a Log4Shellre kiadott vörös riasztási fokozatról. A Log4J könyvtár, amelyet megbízhatóan működő kvázi-szabványként az Apache Alapítványon keresztül terjesztenek, 2013 óta számos rendszerben - köztük olyan jól ismert webes szolgáltatásokban, mint az Amazon AWS - meghonosodott.

Ezeknek a jól kidolgozott és egyben karbantartott könyvtáraknak a komplexitása implicit módon olyan erős funkcionalitásokat biztosít, amelyekről az importáló fejlesztő a saját kombinált új fejlesztésében gyakran nem is tud, de a támadók számára kihasználhatók.

A nyílt forráskódú komponensek másik bizonytalansági tényezője az úgynevezett ellátási lánc támadás, azaz a nyílt forráskódú közösség részének adják ki magukat és a kódfejlesztésben közreműködnek rosszindulatú szereplők által szándékosan beépített sebezhetőségek. Az ilyen sebezhetőség rendkívül hatékony módja annak, hogy a hackerek nagyszámú későbbi felhasználó szervezetet támadjanak meg. Nem csoda tehát, hogy ez a támadási vektor gyorsan növekszik: a Sonatype tanulmánya 650%-os növekedést diagnosztizált 2020 és 2021 összehasonlításakor.

whitepaper-ISO 27001-faq-dqs-cover picture
Loading...

ISO/IEC 27001:2022 Gyakran ismételt kérdések

"Az új" információbiztonsági irányelv: 38 kérdés és válasz


Amit az információbiztonság "újdonságáról" tudni kell: szakértőnk 38 válasza 38 felhasználói kérdésre, mint például:
- Miről szólnak az új ellenőrzések?
- Mikor kell áttérni az új szabványra?
- Hol találom a régi vs. új megfeleltetések listáját? 
- ... valamint további 35 kérdésre! 

Információbiztonsági ellenőrzés 8.28 biztonságos kódolás

A szoftverfejlesztési folyamatok időben történő védelme érdekében a Nemzetközi Szabványügyi Szervezet (ISO - ISO/IEC JTC 1/SC 27 bizottság) az új ISO/IEC 27002 és ISO/IEC 27001:2022 szabványok A. mellékletének 8.28-as új vezérlőelemeként a "biztonságos kódolást" vette fel. A biztonságos kódolásra vonatkozó technikai intézkedés célja a szoftverek megelőző védelme.

Az eljárási szabályok alapján már az írás szakaszában megteremtik a biztonság minimális szintjét, így minimalizálják a szoftverben a potenciális biztonsági rések számát. A biztonságos kódgenerálásra vonatkozó szabályozási keretet holisztikusan kell alkalmazni mind a vállalat saját programkódjára, mind a harmadik féltől származó szoftverekre és a nyílt forráskódú szoftverekre. A megvalósítás során említésre méltó elvek a Security by Design és a Least Privilege, amelyeket a kódolás során is figyelembe kell venni.

A biztonságos kódolás alapelvei

A 8.28. intézkedés többször foglalkozik a biztonságos kódolás úgynevezett elveivel. Arra vonatkozóan, hogy mik lehetnek ezek, számos szervezet és intézet ad útmutatást, amelyek rendszeresen adnak ki útmutatókat és legjobb gyakorlatokat a biztonságos kódoláshoz. Ezek közé tartozik például az OWASP Alapítvány biztonságos kódolási gyakorlata, a Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) biztonságos kódolási szabványai, valamint a német BSI webes alkalmazások biztonságára vonatkozó intézkedéskatalógusa. A különböző források ellenére a kidolgozások számos párhuzamot mutatnak, például a következő pontok tekintetében:

  • Az adatbevitel validálása
  • Hitelesítés és jelszókezelés biztosítása
  • Biztonságos hozzáférés-szabályozás
  • Egyszerű, átlátható kód
  • Fenntarthatóan tesztelt kriptográfiai intézkedések és összetevők
  • Hibakezelés és naplózás
  • Adatvédelem
  • Fenyegetésmodellezés

Az ISO/ISO 27002:2022 szabványban a 8.28. ellenőrzéshez javasolt intézkedések három szakaszra oszlanak: "Tervezés és előkódolás", "A kódolás során" és "Ellenőrzés és karbantartás", amelyek alapvető tartalma az alábbiakban kerül ismertetésre.

dqs-shutterstock-1702088602.jpg
Loading...

Nézze meg most! Mi változik az új ISO/IEC 27001:2022-vel?


Az ISO/IEC 27001 új, a mai információs kockázatokhoz igazított változata október 25-én jelent meg 2022-ben. Mit jelent ez a szabvány felhasználói számára? Ingyenes webináriumunk felvételén megtudhatja a következőket 

  • Az ISO/IEC 27001:2022 új jellemzői - Keretrendszer és A melléklet 
  • ISO/IEC 27002:2022-02 - szerkezet, tartalom, attribútumok és hashtagek 
  • Az átállás ütemezése és a következő lépések

Tervezés és előkódolás

Mind az új kódfejlesztés, mind a kód újrafelhasználása megköveteli a biztonságos kódolási elvek alkalmazását - függetlenül attól, hogy a kódot belső szoftverhez vagy külső termékekhez és szolgáltatásokhoz írják. Ehhez előzetesen ki kell értékelni a szervezet-specifikus elvárásokat és meg kell határozni az elismert elveket. Emellett a tervezésre és az előkódolásra ajánlott intézkedések figyelembe veszik az ismert általános és múltbeli kódolási gyakorlatokat és hibákat, amelyek sebezhetőségekhez vezethetnek.

A fejlesztőeszközök konfigurációjának, például az integrált fejlesztőkörnyezetekben (IDE) szabályalapúnak kell kikényszerítenie a biztonságos kód létrehozását. Nagyon fontos a fejlesztők képzettsége és a biztonságos architektúrák és programozási szabványok ismerete. Az információbiztonsági szakértelem bevonása a fejlesztői csapatba magától értetődő.

A kódolási folyamat során

A kódolási folyamat során a kódolási gyakorlatok és a strukturált programozási technikák elsődleges szerepet játszanak, figyelembe véve az adott felhasználási esetet és annak biztonsági igényeit. A nem biztonságos tervezési technikákat - például a keményen kódolt jelszavakat - következetesen tiltani kell. A kódot megfelelően dokumentálni és felülvizsgálni kell a biztonsággal kapcsolatos hibák legjobb kiküszöbölése érdekében. A kód felülvizsgálatára a fejlesztés során és azt követően is sor kell, hogy kerüljön, statikus alkalmazásbiztonsági tesztelés (SAST) vagy hasonló módon. A statikus tesztelési módszerek támogatják a balra tolódó megközelítést ("teszteljünk korán és gyakran") azáltal, hogy az életciklusban balra tolódva a látható kódot korán tesztelik a szabályoknak való megfelelés szempontjából.

Ez lehetővé teszi a szennyezett kód, a fájlokhoz vagy bizonyos objektumosztályokhoz való kapcsolódások, illetve az alkalmazásszintű rések korai azonosítását, amelyek kihasználható sebezhetőségként harmadik fél programjaival való észrevétlen interakcióra használhatók fel. A szoftver üzembe helyezése előtt a 8.28-as ellenőrzés megköveteli a támadási felületek értékelését és a legkisebb jogosultság elvének megvalósítását. Értékelni kell a leggyakoribb programozási hibákról elvégzett elemzést és azok kijavításának dokumentálását.

dqs-abstract image of a code with the lettering cyber attack
Loading...

Ez is érdekelheti:

Felderítés és megelőzés az információbiztonság kezelésében

Ellenőrzés és karbantartás

A biztonságos kódolás témája a szoftver éles üzembe helyezése után is aktuális marad. Ez magában foglalja a biztonságos frissítéseket, valamint a saját kód ismert sebezhetőségének ellenőrzését. Ezenkívül a hibákat és a feltételezett támadásokat dokumentálni kell, hogy a szükséges kiigazításokat azonnal el lehessen végezni. A forráskódhoz való illetéktelen hozzáférést minden esetben megbízhatóan meg kell akadályozni megfelelő eszközökkel.

Nyílt forráskód

Az ellenőrzés és karbantartás területén a 8.28. intézkedés ezen felül kifejezett utasításokat tartalmaz a külső eszközök és könyvtárak, például a nyílt forráskódú szoftverek használatára vonatkozóan. Ezeket a kódkomponenseket leltárban kell kezelni, frissíteni és karbantartani. Ez történhet például egy szoftver-anyagjegyzék (SBOM) segítségével. Az SBOM egy formális, strukturált nyilvántartás a szoftver csomagjairól és könyvtárairól, valamint azok egymáshoz és az ellátási láncon belüli kapcsolatairól, különösen az újrahasznált kód és a nyílt forráskódú komponensek nyomon követése érdekében. Az SBOM támogatja a szoftver karbantarthatóságát és a célzott biztonsági frissítéseket.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Az ISO 27001 szerinti tanúsítás

Milyen erőfeszítésekkel kell számolnia ahhoz, hogy az ISO 27001 szerinti ISMS-t tanúsíttassa? Tájékozódjon ingyenesen és kötelezettség nélkül.

Várjuk a beszélgetést.

Következtetés

A biztonságos kód elemi alapja a potenciális támadások megállításának. Az új Control 8.28 figyelembe veszi ezt a régóta hangoztatott felismerést, és felértékeli a biztonságos kódolás kulcsfontosságú szerepét az információbiztonság szempontjából. Mivel azonban az intézkedés számos részletes intézkedési ajánlást tartalmaz és technikailag igényes, végrehajtása viszonylag nagy erőfeszítéssel jár - ezt már a tervezés során figyelembe kell venni.

Tapasztalt auditoraink szakmai véleményével támogatjuk Önt az intézkedés szabályszerű végrehajtásában. Több mint 35 éves auditálási és tanúsítási szakértelmünkkel ideális kapcsolattartó partnerei vagyunk, és szívesen segítünk Önnek az információbiztonság és az ISO/IEC 27001:2022 szabvány szerinti tanúsítás témájában.

Az ISO 27001 felülvizsgálata: Mit jelent a frissítés az Ön tanúsítása szempontjából?

Az ISO/IEC 27001:2022 szabványt 2022. október 25-én tették közzé. Ez a következő határidőket és időkereteket eredményezi a felhasználók számára az átállásra:

A "régi" ISO 27001:2013 szerinti kezdeti/újratanúsítási auditok utolsó dátuma. 

  • 2024. április 30. után a DQS kizárólag az új ISO/IEC 27001:2022 szabvány szerinti kezdeti és újratanúsítási auditokat fog végezni.

A "régi" ISO/IEC 27001:2013 szabvány szerinti összes meglévő tanúsítvány átállítása az új ISO/IEC 27001:2022 szabványra.

  • 2022. október 31-től hároméves átmeneti időszak áll rendelkezésre.
  • Az ISO/IEC 27001:2013 vagy DIN EN ISO/IEC 27001:2017 szerint kiadott tanúsítványok legkésőbb 2025. október 31-ig érvényesek maradnak, vagy ezen a napon vissza kell vonni őket.

DQS: A biztonság egyszerű kihasználása

Az átmeneti időszakok miatt a vállalatoknak elegendő idejük van arra, hogy az új követelményeknek megfelelően átalakítsák és tanúsíttassák ISMS-üket. Nem szabad azonban alábecsülni a teljes átállási folyamat időtartamát és erőfeszítéseit - különösen, ha nem rendelkezik elegendő szakképzett személyzettel. Ha biztosra akar menni, inkább előbb, mint utóbb foglalkozzon a kérdéssel, és szükség esetén hívjon tapasztalt szakembereket.

Több mint 35 éves tapasztalattal rendelkező auditálási és tanúsítási szakértőként szívesen támogatjuk Önt a jelenlegi állapot értékelésében, esetleg egy delta audit keretében. Számos tapasztalt auditorunktól tájékozódjon a legfontosabb változásokról és azok jelentőségéről az Ön szervezetére nézve. Együtt megbeszéljük a fejlesztési lehetőségeket, és támogatjuk Önt, amíg meg nem kapja az új tanúsítványt. Használja ki információbiztonsági kompetenciánkat! Várjuk, hogy jelentkezzen.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Kérdése van?

Vegye fel velünk a kapcsolatot!

Kötelezettség nélkül és ingyenesen.

Szerző
Markus Jegelka

A DQS szakértője az információbiztonsági irányítási rendszerek (ISMS) területén, valamint az ISO 9001, az ISO/IEC 27001 és a német energiaipari törvény (EnWG) 11.1a. bekezdése szerinti IT biztonsági katalógusok tapasztalt auditora.

Loading...