Penetrasjonstesting

Ifølge Gary McGraw hviler programvaresikkerhet på tre pilarer:

  1. Anvendt risikostyring: Ta på deg den svarte hatten din for å avdekke alle mulige trusler. Utfør risikoanalyse på arkitekturnivå, dvs. trusselmodellering med mere. Risiko må spores og motvirkes kontinuerlig gjennom hele utviklingslivssyklusen.
  2. Trykkpunkter for programvaresikkerhet: Identifiser kjerneaktiviteter som bidrar til forbedret programvaresikkerhet, og sørg for at sikkerhet blir tatt hensyn til i hvert steg av programvareutviklingssyklusen. Microsoft sitt Tiltrodde databehandlingsinitiativ (Trustworthy Computing Initiative) fra 2002 er et eksempel, som resulterte i Microsoft SDL (og senere SDL Agile).
  3. Kunnskap og god praksis: Alle utviklere må ha et minimum av sikkerhetskunnskap, og kunne bruke sjekklister som OWASP Top 10.
Les hele innlegget

Smidig utvikling og programvaresikkerhet

Smidighetsbevegelsen representerer alternativer til tradisjonell prosjektledelse i utviklingsprosjekter. Smidige metoder brukes typisk for å la utviklingsorganisasjoner respondere på usikkerhet og uventet hendelsesforløp. Scrum er den mest populære måten å introdusere smidighet, på grunn av sin enkelhet og fleksibilitet.

Les hele innlegget

Innebygget sikkerhet

I en artikkel i IEEE S&P for mange år siden diskuterte Bruce Schneier hva som gjør at vi “kjøper” sikkerhet. Hvorfor får sikkerhetsoppgaver alltid lavere prioritet enn andre oppgaver? Hvorfor er utviklere generelt så lite interesserte i sikkerhet? Eksperter forteller stadig vekk utviklere at de må tenke er på sikkerhet, så hvorfor gjør ikke alle det? Hvorfor innser ikke ledere at de må sørge for å ha sikkerhetseksperter i utviklingsgruppen, på samme måte som de gjør med testere?

Les hele innlegget

Risiko og programvaresikkerhet

Risiko er noe vi må leve med, men dessverre er det også noe de fleste av oss er veldig dårlige til å vurdere. En vanlig måte å beregne risiko på er å multiplisere konsekvensen av en hendelse med sannsynligheten for at den sal oppstå. Man illustrerer dette gjerne i en risikomatrise, der sannsynlighet er en akse, og konsekvens er den andre. I World Economic Forums risikorapport for 2019 finner vi cyberangrep langt opp til høyre i matrisen, kun slått av klimaendringer, ekstremvær og naturkatastrofer (som for meg egentlig høres ut til å være det samme).

Les hele innlegget

Den som tror han er ferdig utlært er ikke utlært, men ferdig

I høst underviser jeg et nytt fag med den fengende tittelen “DAT250 Informasjons- og programvaresikkerhet” ved Universitetet i Stavanger. Som i fjor vil jeg lage norske sammendrag av utalgte forelesninger og legge ut her.

Faget baserer seg delvis på bøkene Software Security av Gary McGraw, Security Engineering av Ross Anderson, og OWASP Testing guide – men jeg kommer til å trekke inn diverse annet stoff ved behov.

Temamøte om ikke-funksjonelle krav

Sammen med kolleger fra SINTEF arrangerte vi 26/9 et temamøte med det klingende navnet “Ikke-funksjonelle krav i smidige prosjekter” hos KnowIt i Oslo. Møtet hadde deltakere fra bedrifter som deltar i forskjellige forskningsprosjekter med SINTEF Digital i Trondheim, og fokuset var på sikkerhet (security), trygghet (safety) og skalerbarhet (scalability).
Les hele innlegget

When the going gets tough, the tough go to the pub

Vi innleder juni med en Hacker’s Pub i samarbeid med Dataforeningen på Work-Work. Temaet er “Mobile applications and security”, og vi fører an med innlegget “Static Analysis Tools for analysing Security in Mobile Applications”, presentert av vår post doc. Tosin Oyetoyan og gjesteforsker Marcos Chaim fra Brasil.

Les hele innlegget

7 trykkpunkter for programvaresikkerhet

figProgramvaresikkerhet er nødvendig for all programvare! Imidlertid må vi innse at sannsynligheten er liten for at alle utviklere skal hive seg på alle de 113 aktivitetene i BSIMM på en gang. Hvor kan man da begynne? Gary McGraw lanserte for over 10 år siden en samling med god praksis for programvaresikkerhet som kanskje kan være et godt utgangspunkt.

Les hele innlegget

En ny aktivitet i BSIMM7

docker

Cigital feirer (inter)nasjonal sikkerhetsmåned med å slippe en ny versjon av BSIMM-studien – versjon 7!

Denne utgaven har med data fra 95 forskjellige virksomheter, og totalt 237 forskjellige målinger. Nytt av året er aktiviteten  [SE3.4] “Use application containers” (som vi kan oversette til “Bruk applikasjonscontainere” – f.eks. Docker). Det er tydelig at BSIMM ønsker å ligge litt i forkant her, ettersom det er ingen av de undersøkte virksomhetene som så langt rapporterer at de gjør denne aktiviteten.

Les hele innlegget

Arkitekturanalyse som risikosport

architecturalriskArkitekturanalyse (Architectural risk analysis) er en av de viktigste programvaresikkerhetsaktivitetene man kan gjøre – Gary McGraw har uttalt at hvis du bare kan gjøre én ting, bør du satse på arkitekturanalyse.

Imidlertid er det et begrep som mange har vanskeligheter med å få fatt på. Navnet er i seg selv en utfordring – på norsk skulle det kanskje ha vært “arkitektonisk risikoanalyse”, men det ble nesten for meget av det gode. I denne artikkelen skal vi gjøre et forsøk på å gi et litt klarere bilde av hva vi legger i begrepet.

Les hele innlegget

Protection Poker: Spill deg til bedre programvaresikkerhet!

bilde_pp-kort_mindreProf. Laurie Williams og hennes gruppe ved North Carolina State University har utviklet en enkel, rask og engasjerende måte å vurdere risiko på spesielt for smidige utviklingsteam: Protection Poker! I dette innlegget vil vi fortelle hvordan man kan starte å spille Protection Poker, samt noe om bakgrunnen for spillet og hvilke erfaringer som ble gjort da Laurie og hennes team testet spillet i Red Hat IT.

Les hele innlegget

Risikovurdering eller sjekkliste – hva er best?

Lisence Creative Commons Attribution 2.0 Generic , Michael Coté (flickr)

Creative Commons Attribution 2.0 Generic , Michael Coté (flickr)

Samme hvor gjerne vi måtte ønske oss sikre systemer, så er det i praksis umulig å forhindre alle sikkerhetsfeil. Man har begrenset med tid, penger og ekspertise, og man trenger systemer som er enkle å bruke og vedlikeholde. Spørsmålet man da trenger svar på er hvor mye sikkerhet man skal ha, og hvor man skal satse de sikkerhetsressursene man har.

Det finnes generelt to hovedtilnærminger til å bestemme hvilket nivå man skal legge seg på angående sikkerhet, og hvilke tiltak man skal prioritere:

  • en risiko-basert tilnærming
  • overholdelse av regler og god praksis (compliance)

Disse er ikke i direkte motsetning. Som eksempel så vil man gjerne ta hensyn til regler og god praksis i vurdering av risiko, og god praksis innebærer gjerne at man har oversikt over risiko. Men hvilken av disse hovedtilnærmingene man vektlegger sterkest påvirker hvordan man jobber med sikkerhet, og de har begge sine fordeler og ulemper. Kort sagt så vil en risiko-basert tilnærming være bedre for å oppnå kostnadseffektiv sikkerhet, men det krever mer kompetanse enn om man går for sjekkliste-versjonen av sikkerhet. Vi vil nå forklare dette nærmere.

Les hele innlegget