Turvaline süsteemiarendusehkainult krüptograafiast ei piisa

Margus Freudenthal

Sisukord Üldine jutt: miks ja milleks Turvalise süsteemiarenduse

põhimõtteid Näide: raamatupidamine ja

pangandus

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)

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.)

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

Turvalisus = riskihaldus Turvainseneri ülesandeks on

piirata tekkida võivat kahju Süsteem on turvaline siis, kui riskid

on kontrolli all

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?

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

Turvameetmete planeerimisest Mida me kaitseme? Mille eest? Kelle eest? Millised on motiivid?

Pahade motiivid Heade motiivid

Milline on turvameetmete hind?

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

Printsiip: KISS Kett on sama tugev kui kõige

nõrgem lüli Teeme hästi lühikese keti

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

Turvapoliitika kolm vaala Ära hoidmine (prevention) Avastamine (detection) Taastamine (recovery)

Nõrkusi ühes valdkonnas on võimalik kompenseerida teises valdkonnas

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

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

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

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

Turvaomaduste pingerida Kõik andmed peavad olema

terviklikud Kõik andmed peavad olema

käideldavad Mõned andmed peavad olema

konfidentsiaalsed

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

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

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

Kohustuste lahutamine Topeltkontroll

Mitu isikut peab autoriseerima sama tehingu

Kohustuste funktsionaalne lahutamine Üks tehing käib läbi mitme erineva

isiku käest

Pettuste statistika 82 protsenti pettustest sooritasid

oma töötajad Pooled neist olid samas kohas

töötanud üle viie aasta Kolmandik neist kuulus juhtkonda

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

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

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

Kõik

Küsimusi, kommentaare?