SZTE Információbiztonság Előadás Fólia

UNIVERSITAS SCIENTIARUM SZEGEDIENSIS
SZEGEDI TUDOMÁNYEGYETEM
Szoftverfejlesztés Tanszék
Információbiztonság
1. FEJEZET
Információbiztonság alapjai
Tartalomjegyzék
1. Bevezetés, követelmények
2. Az információbiztonság alapjai. Fogalmak és célok.
Tanszék
Biztonsági alapelvek, területek. Védelmi kontrollok, kockázatok.

3. Fenyegetések, sérülékenységek és kihasználásuk, támadók,
Szoftverfejlesztés
incidensek. Osztályozás, feltárási módszerek, hackerek,

hackelés. Felmérés lépései.
4. Hozzáférés-vezérlés és identitáskezelés. Azonosítás,
hitelesítés, módszerek. Identitáskezelés.
5. Social engineering és fizikai biztonság. Pszichológiai
manipuláció. Fizikai fenyegetések.
6. Kriptográfiai alapfogalmak. Alapfogalmak, titkosítás, kulcsok,
hash-függvények. Elektronikus aláírás.
7. Hálózatbiztonság. Hálózati protokollok, eszközök. Naplózás és
felügyelet.
Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 13

Tartalomjegyzék (folyt.)
8. Alkalmazásbiztonság. Biztonsági kritériumok, fejlesztési

életciklus, biztonságos kódolás.
Tanszék
9. Web-alkalmazások biztonsága. OWASP, tipikus hibák és

védekezés ellenük.
Szoftverfejlesztés
10. Szoftvertesztelés és biztonsági tesztelés. Tesztelési

alapfogalmak, biztonsági tesztelési módszerek.
11. Információbiztonság etikai és jogi kérdései. Személyes
adatok védelme, jogi kérdések, törvény és etika.
12. Szabványok és folyamatok. Szabványosítás, szabványok.
Tanúsítás, képesítés, szervezetek.
13. Üzemeltetés biztonság, vészhelyreállítás és üzleti
folytonosság. Területek, célok és követelmények. Redundancia,
mentések. IT szolgáltatás ipari gyakorlata.

Aktualitások (2019)
 http://thehackernews.com/
 GovCert Hungary (Kormányzati Eseménykezelő
Tanszék
Központ)
Szoftverfejlesztés
 Offensive Security - Exploit Database Archieve

 Adatlopások Infografika
 DoS támadások online térképe
 https://haveibeenpwned.com/
 WP_Top_5_Database_Security_Threats
 SANS superfish-tls-case-study-betrayed-trust-legal-
liability
 Project-security-often-overlooked
 Hackelés gombnyomásra
Bevezetés
Az információ érték, melyet támadnak

és katasztrófák, meghibásodások
Tanszék
fenyegetnek, ezért az információt

Szoftverfejlesztés
védenünk kell.
A kár nem csupán anyagi lehet, hanem
■ üzleti (titkok kikerülése, kiesés),
■ nemzetbiztonsági, politikai,
■ erkölcsi.

Először is egy dilemma
Az információnak illetéktelenek előli elrejtése

jelenti
Tanszék
■ az információ titkos továbbítását,

Szoftverfejlesztés
■ az információ titkos tárolását.

Védelmet kell biztosítani
■ a megsemmisüléstől,
■ az eltulajdonítástól.
Ez a két védelmi szempont egymással
ellentétes:
■ Egy példányban – sok példányban tároljuk az
adatainkat?
Információ- vs. informatikai
biztonság
Előbbi tágabb, katonai fogalom, benne vannak
Tanszék
■ az elhárítás,
Szoftverfejlesztés
■ fizikai védelem,
■ személyi védelem és
■ dokumentumvédelem
■ más aspektusai is.
Utóbbi csak az informatikai rendszerek és a
bennük kezelt adatok védelmét jelenti.

IB alapvető céljai
1. C = Confidentiality (bizalmasság)
Csak azok érhessék el az információt, akik arra jogosultak. Pl.:
Tanszék
titkosított adattovábbítás és tárolás.

Szoftverfejlesztés
2. I = Integrity (sértetlenség)
Védelem az adatok jogosulatlan módosítása ellen, pl.: beszúrás,
törlés, helyettesítés. Pl.: adatbázis-kezelés,
pénzügyi tranzakciók lebonyolítása.
3. A = Availability (rendelkezésre állás)
Az adat vagy szolgáltatás garantált elérhetőségét biztosítja. Pl.:
webszerver, naplózás.
E három legalapvetőbb cél elérése és fenntartása
jelenti az informatikai biztonságot.

További célok
Authentication (hitelesítés, pl. felhasználók

azonosítása)
Tanszék
Privacy (személyes információk/magánélet

Szoftverfejlesztés
védelme, a GDPR 2018. május 25-től kötelező)

Bár az ezt megvalósító adatvédelem (Data
Protection) csak részben tartozik az
informatikai biztonság témakörébe.
■ Általában jogi szabályozás alatt áll.

További célok (folyt.)
 Non-repudiation (Letagadhatatlanság)
Annak elérése, hogy valamelyik fél letagadhassa
Tanszék
korábbi kötelezettségvállalását vagy cselekedetét, mert

vele az ilyen vitákat egy megbízható harmadik fél
Szoftverfejlesztés
(Trusted Third Party) helyesen el tudja dönteni.

Pl.: „ az elektronikus aláírás = az üzenet hitelesítése +
letagadhatatlansága”
 Audit Rediness (Audit-készség) (informatikai
biztonsági) ellenőrzésnél
 Digital Forensics (E-bizonyítás, Számítógépes
kriminalisztika, maradjanak törölhetetlen bizonyítékok)

A ,,kényelmi háromszög”
BIZTONSÁG
Tanszék
Szoftverfejlesztés
KÉNYELEM FUNKCIONALITÁS

Használható biztonság
 „Usable security”
 Fontos kutatási terület.
Tanszék
 Több mint 20 év tapasztalatai alapján, mi az, ami működik

és mi az, ami nem a biztonság megvalósításának
Szoftverfejlesztés
használhatóságát illetően.
 A biztonság nem csak a védelem mértékében, hanem a
használhatóság érdekében is szükségképpen
kompromisszum kell, hogy legyen.
 Pl.: két tipikus terület:
■ a felhasználók azonosítása,
■ e-mail titkosítás.
 Lásd: http://www.cc.gatech.edu/~keith/pubs/ieee-intro-
usable-security.pdf.

IB területeinek csoportosítása
 Fizikai védelem (zárak, beléptető rendszerek,

tűzjelző rendszerek, biztonsági kamerák és
Tanszék
őrök stb.)
Szoftverfejlesztés
 Logikai védelem (titkosítási algoritmusok,

kommunikációs protokollok, tűzfalak, stb.)
 Adminisztratív védelem
(kockázatmenedzsment, biztonsági
szabályzatok, szabványok és ajánlások,
törvényi szabályozás)
,,háromlábú szék, ha egy lába kitörik …”

Operatív modell: PreDeCo
A biztonsági kontrollok csoportosíthatók

funkciójuk szerint:
Tanszék
■ Preventív (megelőző) kontrollok, pl.: (tűz)falak,

Szoftverfejlesztés
zárak.
Hiba, ha csak ezeket alkalmazzák, mert minden
megkerülhető.
■ Detektív (észlelő) kontrollok, pl.: naplók átnézése,
IDS (Intrusion Detection Systems, behatolás-
érzékelő rendszerek), jogosultságok felülvizsgálata,
audit.

Operatív modell: PreDeCo (folyt.)

 Korrektív (elhárító) kontrollok, pl.: katasztrófa-elhárítási
terv készítése, biztonsági mentések, visszatérés
Tanszék
korábbi biztonságol állapotra, stb.

Szoftverfejlesztés
Ezek egymást is befolyásolják, körbe-

körbe:
Pre->De->Co->Pre->De->…

Operatív modell: PreDeCo (folyt.)

VÉDELEM =
MEGELŐZÉS + FELISMERÉS + VÁLASZ
Tanszék
Szoftverfejlesztés
A kockázatkezelésre van azért más lehetőség is, pl.:

 Elrettentés (Deterrent)
■ bannerben figyelmeztető információk,
■ szankciók a biztonsági szabályzat megszegőivel
szemben,
■ biztonsági kamerák, stb.
 Átruházás (Transfare)
■ Pl. biztosítás, vagy külső szolgáltatás vásárlása.
Elfogadás (Accept)
Biztonsági kontroll időrendben
1. Tervezés (Design)
2. Megvalósítás (Implementation)
Tanszék
3. Üzemeltetés (Operation)
Szoftverfejlesztés
Mindhárom szakaszban elkövetett hibák kritikusak

lehetnek. Például egy ajtózár esetében:
1. Lehet könnyen feltörhető a zár szerkezete (tervezési
hiba).
2. Silány anyagból vagy hanyag megmunkálással
készülhet a zár (megvalósítási hiba).
3. A tulajdonos a lábtörlő alatt tartja a kulcsot
(üzemeltetési hiba).

IB területei
A CISSP(Certified Information System Security

Professional) képesítés 10 nagy témaköre:
Tanszék
1. Access Control (hozzáférés-vezérlés)

Szoftverfejlesztés
2. Telecommunications and Network Security

(telekommunikációs és hálózati biztonság)
3. Information Security Governance and Risk
Management (az informatikai biztonság irányítása és
kockázatmenedzsment)
4. Software Development Security
(a szoftverfejlesztés biztonsága)
5. Cryptography (kriptográfia)

IB területei (folyt.)
6. Security Architecture and Design

(biztonságos architektúrák és tervezésük)
Tanszék
7. Operations Security (üzemeltetés-biztonság)

Szoftverfejlesztés
8. Business Continuity and Disaster Recovery

Planning (üzletmenet-folytonosság és katasztrófa-
elhárítás tervezése)
9. Legal, Regulations, Investigations and Compliance
(jogi kérdések, szabályozások, vizsgálatok és
megfelelőség)
10. Physical (Environmental) Security (fizikai
/környezeti/ biztonság)
Biztonsági alapelvek
1. A biztonság relatív fogalom, avagy

a kockázatarányos védelem elve
Tanszék
 Nem lehet önmagában kijelenteni, hogy egy rendszer

Szoftverfejlesztés
biztonságos. Mindig attól függ, milyen fenyegetés

ellen, mennyi ideig szeretnénk védelmet biztosítani, és
■ milyen értéket (rendszert, információt) kívánunk megóvni.
 Ez dönti el mennyi időt, energiát, pénzt stb. érdemes a
védelemre áldozni. A biztonsági megoldások széles
skálája áll rendelkezésre, de kompromisszumot kell
kötni, mi éri meg.
 Ez a kockázatmenedzsment feladata.

2. A jó védelem rétegzett.
(Layered Security, Defense in Depth)
Tanszék
Szoftverfejlesztés
Egyetlen védelmi megoldás sem 100%-os.

A védelmet úgy kell kialakítani, hogy sok-sok
kontroll védje az értékes rendszert vagy adatot.

3. Változatos legyen a védelem

(Diversity of Defense)
Tanszék
A rétegek ne legyenek hasonlóak, mert az

Szoftverfejlesztés
jelentősen könnyíti a támadó dolgát.

Pl.: ha két tűzfal van egymás után, az legyen
két különböző gyártótól, különböző
hardverarchitektúrán és operációs rendszeren
futtatva.

4. A legkevesebb jogosultság elve

(Principle of Least Privilege)
Tanszék
Minden személy, folyamat, alkalmazás stb.

Szoftverfejlesztés
csupán annyi jogosultságot kapjon, amennyi a

feladatainak ellátásához feltétlenül szükséges.
Pl. ne böngéssz és csevegj rootként.
Csak a pénzügyi munkatársak és a
felsővezetés férhessen hozzá a dolgozók
bérjegyzékéhez, a rendszergazdák ne, stb.

5. A feladatkörök szétválasztása
(Separation of Duties)
Tanszék
Fontos dolgokért ne egy ember legyen a

Szoftverfejlesztés
felelős.
Az üzleti életben már rég bevált technika: más
adja fel a rendelést és más engedélyezi annak
kifizetését.
Megvalósítása nyilván hátrányokkal is jár, mind
pénzben, mind időben.

6. Az implicit tiltás elve

(Implicit Deny)
Tanszék
Valamikor az internet kutatók barátságos

Szoftverfejlesztés
játéktere volt, ahol senkinek sem jutott eszébe

keresztbe tenni a másiknak, de ma …
Ezért, amire nem vonatkoznak szabályok, az
legyen alapból TILOS (fehérlistázás).
Szemben a feketelistázással, mely könnyebben
megkerülhető.

7. A homály nem teremt biztonságot

(No Security Through Obscurity)
Tanszék
 Nem alapozhatjuk egy rendszer biztonságát arra, hogy

Szoftverfejlesztés
a környezetet és a védelmi mechanizmust nem hozzuk

nyilvánosságra.
 Ez olyan, mintha a lábtörlő alá dugott kulcstól
remélnénk a lakásunk védelmét.
 Sajnos vannak negatív példák: pl. Mifare Classic chip-
kártyák titkos Crypto-1 biztonsági protokollját
visszafejtették és feltörték.

8. Maradjunk az egyszerűségnél
(Keep It Simple)
Tanszék
 A biztonság és a bonyolultság egymás ellenségei.

Szoftverfejlesztés
 Számos hatékony biztonsági kontroll elegáns és

egyszerű.
 Abból, hogy valami bonyolult, még nem következik,
hogy nem lehet egyszerű módon kijátszani vagy
feltörni.
 Soha ne egy protokoll vagy kriptorendszer
komplexitásától reméljük a biztonságot.

9. Minden lánc csak annyit bír,

amennyit a leggyengébb láncszeme
Tanszék
képes megtartani
Szoftverfejlesztés
A leggyengébb láncszem pedig általában

■ nem a kriptográfiai algoritmus,
■ inkább a protokoll,
■ még inkább annak implementációja, de
■ leginkább a hanyag rendszergazda, vagy mondjuk
egy titkárnő, aki egy ügyes telefonbeszélgetéssel
rávehető, hogy árulja el a főnök jelszavát:
az EMBER!!!

10. Nincs 100%-os biztonság, rések

mindig is voltak és lesznek
Tanszék
 Miért?
Szoftverfejlesztés
 A gyártóknak sokszor nem érdekük a termékük

biztonsága, fontosabb a gyorsaság és a kényelem.
 A rendszereket emberek tervezik, implementálják és
üzemeltetik. Márpedig
„Errare humanum est.” – „Tévedni emberi dolog.”
 Ha belegondolunk, igazából a múltbeli tapasztalataink
alapján a jelen technológiával és tudással szeretnénk a
jövőbeli fenyegetésekkel is szembenézni.
Ez pedig nem túl biztató …
Hivatkozások
 Virrasztó Tamás: Titkosítás és adatrejtés: Biztonságos

kommunikáció és algoritmikus adatvédelem,
Tanszék
NetAcademia Kft., Budapest, 2004.

 Papp Pál, Szabó Tamás: A kriptográfiai biztonság
Szoftverfejlesztés
megközelítési módjai, Alk. Mat. Lapok, 23(2006) 207-

294
 William Stallings: Cryptography and Network Security,
4th Edition, Prentice Hall, 2006.
 Alfred J. Menezes, Paul C. van Oorschot and Scott A.
Vanstone : Handbook of Applied Cryptography, CRC
Press, 1996, online elérhető:
http://www.cacr.math.uwaterloo.ca/hac/ (Chapter 1)
 KIKERES Fogalomtár 3.0 www.fogalomtar.hu
Hivatkozások (folyt.)
 W. A. Conklin, G. White, D. Williams, Ch. Cothren, R.

Davis, CompTIA Security+ All-in-One Exam Guide,
Tanszék
McGraw-Hill Osborne, 2011.

Szoftverfejlesztés
 B. D. Payne, W. K. Edwards, A Brief Introduction to

Usable Security
http://www.cc.gatech.edu/~keith/pubs/ieee-intro-usable-
security.pdf .
 Richard E. Smith, Elementary Information Security,
Jones & Bartlett Learning, 2011.
 Information Security and Risk Management in Context,
Washington University,
https://www.coursera.org/course/inforiskman.

SZTE Információbiztonság Előadás Fólia

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SZTE Információbiztonság Előadás Fólia

Uploaded by

Copyright:

Available Formats

UNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Biztonsági alapelvek, területek. Védelmi kontrollok, kockázatok.

incidensek. Osztályozás, feltárási módszerek, hackerek,

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 13

8. Alkalmazásbiztonság. Biztonsági kritériumok, fejlesztési

9. Web-alkalmazások biztonsága. OWASP, tipikus hibák és

10. Szoftvertesztelés és biztonsági tesztelés. Tesztelési

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 14

 Offensive Security - Exploit Database Archieve

Az információ érték, melyet támadnak

fenyegetnek, ezért az információt

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 16

Az információnak illetéktelenek előli elrejtése

■ az információ titkos továbbítását,

■ az információ titkos tárolását.

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 18

titkosított adattovábbítás és tárolás.

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 19

Authentication (hitelesítés, pl. felhasználók

Privacy (személyes információk/magánélet

védelme, a GDPR 2018. május 25-től kötelező)

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 20

korábbi kötelezettségvállalását vagy cselekedetét, mert

(Trusted Third Party) helyesen el tudja dönteni.

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 21

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 22

 Több mint 20 év tapasztalatai alapján, mi az, ami működik

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 23

 Fizikai védelem (zárak, beléptető rendszerek,

 Logikai védelem (titkosítási algoritmusok,

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 24

A biztonsági kontrollok csoportosíthatók

■ Preventív (megelőző) kontrollok, pl.: (tűz)falak,

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 25

Operatív modell: PreDeCo (folyt.)

korábbi biztonságol állapotra, stb.

Ezek egymást is befolyásolják, körbe-

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 26

Operatív modell: PreDeCo (folyt.)

A kockázatkezelésre van azért más lehetőség is, pl.:

Mindhárom szakaszban elkövetett hibák kritikusak

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 28

A CISSP(Certified Information System Security

1. Access Control (hozzáférés-vezérlés)

2. Telecommunications and Network Security

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 29

6. Security Architecture and Design

7. Operations Security (üzemeltetés-biztonság)

8. Business Continuity and Disaster Recovery

1. A biztonság relatív fogalom, avagy

 Nem lehet önmagában kijelenteni, hogy egy rendszer

biztonságos. Mindig attól függ, milyen fenyegetés

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 31

Egyetlen védelmi megoldás sem 100%-os.

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 32

3. Változatos legyen a védelem

A rétegek ne legyenek hasonlóak, mert az

jelentősen könnyíti a támadó dolgát.

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 33

4. A legkevesebb jogosultság elve

Minden személy, folyamat, alkalmazás stb.

csupán annyi jogosultságot kapjon, amennyi a

Információbiztonság - © 2015-2019 SZTE TTIK Informatikai Intézet 34