Vår avhengighet av systemer som styres av programvare øker raskere enn vår evne til å sikre systemene. En løsning er å bygge inn sikkerhet som en del av programvareutviklingen. Det er utfordrende å måle programvaresikkerhet, men modenhet på programvaresikkerhetsarbeidet kan måles med BSIMM-rammeverket.
9. SINTEF
IKT
Trender
• Økning
i
DDoS
• Innloggingsinformasjon
på
avveie
• Flere
alvorlige
sårbarheter
• Destruk`v
skadevare/løsepengevirus
• Vannhullsangrep
og
spearphishing
Slid
e 9
10. SINTEF
IKT
Hva er truslene?
10
Spionasje
Sabotasje
Økonomisk krim
Rampestreker
Krise / Krig
Politiske protester
Kaosaktører
Kompetente, ressurssterke aktører
11. SINTEF
IKT
Noen
ubordringer
• Proprietære
løsninger
som
ikke
har
bliW
kvalitetssikret
• Sikkerhetsmekanismer
er
`lstede,
men
vanskelige
å
konfigurere
eller
ikke
slåW
på
som
standard
• Standard
eller
hardkodede
passord,
dårlig
nøkkelhåndtering
• Ikke
implementert
`lfredss`llende
mekanismer
eller
ru`ner
for
programvare-‐oppdatering
• Produkter
med
lang
leve`d
blir
hengende
eWer
i
forhold
`l
nye
sikkerhetsmekanismer
og
utviklingen
i
trusselbildet
12. SINTEF
IKT
SLIK
STOPPER
DU
DATAANGREPENE
• Oppgrader
program-‐
og
maskinvare
• Installer
sikkerhetsoppdateringer
så
fort
som
mulig
• Ikke
>ldel
slu?brukere
administrator-‐reAgheter
• Blokker
kjøring
av
ikke-‐autoriserte
programmer
• Ak`ver
kodebeskyWelse
mot
ukjente
sårbarheter
• Herde
applikasjoner
• Bruk
klientbrannmur
• Bruk
sikker
oppstart
og
diskkryptering
• Bruk
an`virus
/
an`-‐malware
• Ikke
ta
i
bruk
flere
applikasjoner
og
funksjoner
enn
nødvendig
Slid
e 12
Kilde:
hWp://nsm.stat.no/blogg/enkle-‐`ltak-‐mot-‐dataangrep/
14. SINTEF
IKT
² Safety-‐By-‐Design
² Tredjeparts
samarbeid
² Bevissikring
² Sikkerhetsoppdateringer
² Segmentering
og
isolering
14
5-‐Stjerners
rammeverk
(automo`ve)
ü Innse
at
det
vil
gå
galt
og
planlegg
håndtering
ü Kjenn
dine
allierte
før
det
går
galt
ü Finn
problemet
og
lær
av
dine
feil
ü Ta
tak
i
hendelsen
og
fiks
problemet
ü Unngå
at
problemet
påvirker
flere
deler
av
systemet
OversaW
fra:
hWps://www.iamthecavalry.org/domains/automo`ve/5star/
15. SINTEF
IKT
• Det
handler
ikke
bare
om
å
bli
kviW
“bugs”,
også
feildesign
• Sikkerhet
bygges
ikke
kun
av
sikkerhetsfunksjoner
• F.eks
ved
å
“legge
`l
krypto”
• Sikkerhet
angår
alle,
ikke
bare
sikkerhetsfolk
og
systemadministratorer
• Sikkerhetskrav
bør
likes`lles
med
kvalitetskrav
• Ikke-‐funksjonelle
krav
er
essensielt!
• Oppe`d
• Kapasitet
Sikker
programvare
krever
fokus
på
sikkerhet
gjennom
hele
utviklingsløpet!
15
Hvordan
“bygge
inn”
sikkerhet?
16. SINTEF
IKT
• Det
holder
ikke
å
bare
telle
antall
bugs
per
1000
linjer
kode
• Utbredelsen
av
produktet
teller
• Har
angriper
et
stort
insen`v
for
å
utnyWe
sårbarhetene?
• Spesielt
for
programvare:
• Programvare
“slites”
ikke
over
`d
• Ingen
“mean
`me
to
failure”
• Ingen
grunn
`l
at
det
skal
eksistere
flere
bugs
i
et
populært
produkt
• I
stedet
for
å
måle
kodekvalitet
kan
man
måle
kvalitet
på
utviklingsprosessen
• Hva
er
beste
praksis?
• I
hvor
stor
grad
følges
beste
praksis?
16
Hvordan
måle
sikker
kode?
17. SINTEF
IKT
17
Sikker
programvareutvikling
• Building
Security
In
Maturity
Model
• Basert
på
etablert
praksis
hos
78
selskaper
• 112
ak`viteter,
12
praksiser
• Måler
modenhet
på
praksis
• SoDware
Assurance
Maturity
Model
• Beskriver
beste
praksis
• En
av
flere
eksempler
på
metodikk
hWp://www.opensamm.org
hWps://www.bsimm.com
19. SINTEF
IKT
BSIMM
SoDware
Security
Framework
Kilde:
hWp://www.informit.com/ar`cles/ar`cle.aspx?p=1271382,
hWp://bsimm.com
Se
også
norsk
versjon:
hWp://infosec.sintef.no/informasjonssikkerhet/2014/03/dypdykk-‐i-‐bsimm-‐del-‐0/
20. SINTEF
IKT
20
Eksempel:
Konfigurasjonsstyring
og
sårbarhetsstyring
Nivå
1:
• OppreW
eller
oppreW
kontakt
med
hendelseshåndtering
• Iden`fiser
programvarefeil
som
oppdages
ved
overvåkning
av
driDen,
og
mat
disse
`lbake
`l
utviklingsavdelingen
Nivå
2:
• Ha
et
system
for
å
gjøre
hur`ge
krise-‐endringer
i
koden
når
en
applikasjon
er
under
angrep
• Hold
styr
på
programvarefeil
som
er
funnet
i
driDen
gjennom
hele
opprerngsprosessen
• OppreW
en
katalog
over
applikasjoner
for
driDen
Nivå
3:
• Fiks
alle
programvarefeil
som
oppdages
i
driDen
• Utvid
organisasjonens
SSDL
`l
å
forhindre
feil
som
oppdages
i
driDen
• Simulér
programvarekriser
• Skuddpremie
på
programvarefeil
21. SINTEF
IKT
BSIMM
Scorecard
(n=78)
1. Bruk eksterne penetreringstestere for å finne
problemer. (69)
2. Sørg for at grunnleggende system- og
nettverkssikkerhetsmekanismer er på plass. (69)
3. Identifiser programvarefeil som oppdages ved
overvåkning av driften, og mat disse tilbake til
utviklingsavdelingen. (73)
4. Identifiser beslutningpunkter, samle
nødvendige artefakter. (66)
5. Foreta gjennomgang av sikkerhets-
mekanismer. (67)
6. La sikkerhetsmekanismer og sikkerhetskrav
drive testene. (66)
7. Lag og publisér sikkerhetsfunksjonalitet. (61)
8. Identifisér krav til personvern. (61)
9. Tilby sikkerhetsbevissthetsopplæring. (59)
10. Bruk automatiserte verktøy sammen med
manuell gjennomgang. (55)
11. Lag et graderingssystem for data og
katalogiser. (51)
12. Lag sikkerhetsstandarder. (57)
22. SINTEF
IKT
22
Måling
av
20
norske
offentlige
virksomheter
hWp://infosec.sintef.no/informasjonssikkerhet/2015/04/hvordan-‐star-‐det-‐`l-‐med-‐programvaresikkerheten-‐i-‐norske-‐offentlige-‐virksomheter/
28. SINTEF
IKT
Vår
avhengighet
av
systemer
som
styres
av
programvare
øker
raskere
enn
vår
evne
>l
å
sikre
systemene
• En
løsning
er
å
bygge
inn
sikkerhet
som
en
del
av
programvareutviklingen
• Programvare
vil
all`d
inneholde
bugs
• Det
er
ubordrende
å
måle
programvaresikkerhet
• Modenhet
på
programvaresikkerhetsarbeidet
kan
måles
med
BSIMM
28
Konklusjon