Turvaline süsteemiarendus ehk ainult krüptograafiast ei piisa

1. Turvaline süsteemiarendusehkainult krüptograafiast ei piisa Margus Freudenthal

2. Sisukord • Üldine jutt: miks ja milleks • Turvalise süsteemiarenduse põhimõtteid • Näide: raamatupidamine ja pangandus

3. Algatuseks: vaatlusobjekt • Käesolevas loengus vaatleme (info)süsteemi selle mõiste laias tähenduses, mis hõlmab • Rakendustarkvara • Süsteemitarkvara • Riistvara • Kasutajaid • Juhtkonda • Organisatsiooni kliente ja partnereid • Ümbritsevat keskkonda (meediat, konkurente, seadusi)

4. Algatuseks: turvameetmete roll • Turvalisus ei ole eesmärk iseeneses, vaadelda tuleb (info)süsteemi rakendava organisatsiooni eesmärke • Firmade eesmärk on valdavalt kasumi teenimine • Turvarisk on sarnane muude äririskidega (börsikrahh, seaduste muutumine, jms.)

5. Turvameetmete roll jätkub • Turvalisem süsteem ei pruugi olla kasulikum süsteem • Näide: supermarketid • Varastatakse oluliselt rohkem kui väikestes poodides • Suurema efektiivsuse tõttu on tulusamad • Meeldetuletus: turvameetmed üldjuhul midagi sisse ei too

6. Turvalisus = riskihaldus • Turvainseneri ülesandeks on piirata tekkida võivat kahju • Süsteem on turvaline siis, kui riskid on kontrolli all

7. Inimene on kõigi asjade mõõt • Meie süsteemi kasutavad inimesed • Inimestel on tegutsemismotiivid, harjumused • Infosüsteemi projekteerimisel esitada alati küsimusi: • Milline on X huvi seoses antud tegevusega (andmeelemendiga)? • Mida võidab Y, kui juhtub Z?

8. Otsi huvide konflikte • Turvaprobleemid algavad huvide konfliktist • Näide: • Minu huvides on olla oma auto ainuvaldaja • Varga huvides on olla minu auto ainuvaldaja • Veel näiteid: • Veebipoe kliendi huvides on ostu eest mitte tasuda • Töötaja huvides on eemale juhtida maksimaalses koguses firma raha

9. Turvameetmete planeerimisest • Mida me kaitseme? • Mille eest? • Kelle eest? • Millised on motiivid? • Pahade motiivid • Heade motiivid • Milline on turvameetmete hind?

10. Süsteemiarenduse printsiipe • Ära kuhja sihtmärke kokku • Ühe turvameetme lahti murdnud ründaja võiks ligi pääseda vaid ühele varale • Näiteks NATO reeglid keelavad raha ka konfidentsiaalseid andmeid koos transportida

11. Printsiip: KISS • Kett on sama tugev kui kõige nõrgem lüli • Teeme hästi lühikese keti

12. Printsiip: defence in depth • Teineteist dubleerivad turvamehhanismid • Tulemus on sama tugev kui kõige tugevama keti nõrgim lüli • Raske on teha nii, et dubleerivad mehhanismid ei omaks ühiseid nõrkusi • Konfliktis KISS printsiibiga

13. Turvapoliitika kolm vaala • Ära hoidmine (prevention) • Avastamine (detection) • Taastamine (recovery) • Nõrkusi ühes valdkonnas on võimalik kompenseerida teises valdkonnas

14. Eelduste haldus • Oluline turvarikete allikas: arendajate poolt tehtud eeldused ei ole täidetud • Keskkonna muutus võib muuta eeldused valedeks • Näide: algselt firma sisemiseks tarbeks arendatud teenus muudetakse avalikuks • Eeldused tuleb ilmutatult kirja panna ning aeg-ajalt uuesti üle vaadata

15. Turvamehhanismide omadused • Tee endale selgeks, mida turvamehhanism tegelikult pakub • Näide: kiipkaart pakub enam-vähem turvalist võtmehoidlat ning RSA signatuuri arvutamise keskkonda • Titanicu efekt: mingile popile tehnoloogiale lootma jäämine

16. Trust no one • Ära usalda protsesse, mis ei ole sinu kontrolli all • Näiteks ära looda, et kliendi brauseris töötav JavaScript teeb sisendi kontrolli korrektselt

17. Mõtle inimestele • Enamik turvarikkeid on seotud inimeste omadustega • Tee turvameetmed kasutajasõbralikuks • Muuda turvameetmed tööprotsessi loomulikuks osaks • Motiveeri inimesi turvameetmeid kasutama • Näide: aeglukustusega seifid kaitsevad inimröövide eest

18. Turvaomaduste pingerida • Kõik andmed peavad olema terviklikud • Kõik andmed peavad olema käideldavad • Mõned andmed peavad olema konfidentsiaalsed

19. Oluline mõte • Whoever thinks his problem can be solved using cryptography, doesn’t understand his problem and doesn’t understand cryptography. Roger Needham / Butler Lampson

20. Näide: raamatupidamine ja pangandus • Väga vanad turvameetmed • Turvanõuded: • Konfidentsiaalsus ei ole oluline • Terviklus on oluline • Kord salvestatud andmete hilisema muutmise vältimine on oluline • Insaiderid on oluline (olulisim) risk

21. Kahekordne kirjendamine • Iga transaktsioon kantakse kahte erinevasse raamatusse • Perioodi lõpus peavad arved klappima • Raamatuid peavad harilikult erinevad inimesed • Vastutuse jagamine – pettus eeldab kahe raamatupidaja koostööd • Arvutipõhistes süsteemides kahjuks nii hästi ei tööta

22. Kohustuste lahutamine • Topeltkontroll • Mitu isikut peab autoriseerima sama tehingu • Kohustuste funktsionaalne lahutamine • Üks tehing käib läbi mitme erineva isiku käest

23. Pettuste statistika • 82 protsenti pettustest sooritasid oma töötajad • Pooled neist olid samas kohas töötanud üle viie aasta • Kolmandik neist kuulus juhtkonda

24. Pettuste statistika • Õnnestunud pettused kasutasid põhiliselt ära protseduurilisi nõrkusi • Garantiikirjade võltsimine • Fiktiivsed toetuste/kindlustuse saajad • Programmeerijate poolt teostatavad ründed kukkusid sageli läbi protseduuride ja auditeerimisreeglite mittetundmise tõttu

25. ATM pettused • Sisemised ründed • Teadete või PIN-ide krüptimiseks kasutatavate PIN-ide teada saamine programmeerijate/administraatorite/osakonnajuhatajate poolt • Välised ründed • Võltsautomaatide üles seadmine • Kaartide vargus/PIN-ide piilumine

26. Olulisi tähelepanekuid • Alati on olemas ametikohti, kelle pettusi on raske avastada • Turvapoliitika ei ole 100% range, alati tehakse neisse praktika tõttu mugandusi. • Mõned neist mugandustest on turvaaugud • Sageli on raske eristada pettusi vigadest • Mida vähem loomulikke vigu, seda lihtsam on avastada pettusi. • Tehnilised ja protseduurilised kontrollid ei tohiks kattuda

27. Kõik Küsimusi, kommentaare?