For å feire sikkerhetsmåneden har Synopsys nettopp gitt ut siste versjon av BSIMM-rapporten – vi er nå oppe i BSIMM9.
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).
En ny aktivitet i BSIMM7
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.
BSIMM på norsk
Som de fleste lesere av bloggen har fått med seg, har jeg i løpet av et års tid langsomt oversatt aktivitetsbeskrivelsene fra BSIMM til norsk. For å feire at jobben er fullført, har vi funnet ut at vi skal samle alle beskrivelsene i ett dokument som kanskje er mer hendig enn 12 frittstående bloggposter.
Cyberforsikring – hva vet vi fra forskningen?
Det å kjøpe cyberforsikring er et mulig tiltak for å håndtere risiko i en virksomhet. Det kan imidlertid være krevende å vurdere cyberforsikring opp mot andre tiltak: Når bør man velge å forsikre, og når bør man heller gå for andre strategier? Vi har laget en rapport som oppsummerer forskningen på cyberforsikring som en risikohåndteringsstrategi.
Hva er nytt i BSIMM6?
Siste utgave i rekken, BSIMM6, ble offentliggjort for en drøy uke siden. Fans av dypdykkserien kan puste ut; det er bare små endringer i de tekstlige beskrivelsene av selve aktivitetene.
Dypdykk i BSIMM del 12 – Software Environment
I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til det siste avsnittet, nemlig Software Environment eller “Programvaremiljø” som vi har kalt det på norsk.
I vår modenhetsstudie av programvaresikkerhet i offentlige virksomheter fant vi at de aller fleste hadde god tiltro til egen modenhet på dette feltet. Dette er ikke overraskende, ettersom det stort sett dreier seg om tradisjonelle mekanismer for sikring av datamaskiner og nettverk, noe som i langt større grad er en del av vanlig praksis enn det programvaresikkerhet er.
Dypdykk i BSIMM del 11 – Security Testing
I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Security Testing, eller “Sikkerhetstesting”.
Hovedmålet for praksisen Sikkerhetstesting er kvalitetskontroll som gjøres i løpet av utviklingssyklusen. De som utfører sikkerhetstesting må sørge for at sikkerhetsfeil oppdages og korrigeres. Programvaresikkerhetsgruppen (SSG) må sørge for at standarder blir fulgt og at godkjente sikkerhetsmekanismer gjenbrukes.
Dypdykk i BSIMM del 10 – Penetration Testing
I vår modenhetsstudie av programvaresikkerhet i offentlige virksomheter pekte penetreringstesting seg ut som en aktivitet som generelt sett ikke gjøres som en del av utviklingen – dette er overraskende når man tenker på hvor mange verktøy som er fritt tilgjengelige. Noen kunne hevde at den jevne utvikler ikke har tilstrekkelig kompetanse til å drive penetreringstesting, men vårt svar er at da er det på tide at de lærer seg noen nye triks!
Dypdykk i BSIMM del 9 – Code Review
I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Code Review, eller kodegjennomgang.
Hovedmålet for praksisen “Kodegjennomgang” er kvalitetskontroll. De som utfører kodegjennomgang må sørge for at sikkerhetsfeil oppdages og korrigeres. SSG må sørge for at standarder blir fulgt og at godkjente sikkerhetsmekanismer gjenbrukes.
Dypdykk i BSIMM del 8 – Architecture Analysis
I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Architecture Analysis, eller Arkitekturanalyse.
Hovedmålet for praksisen Arkitekturanalyse er kvalitetskontroll. De som utfører arkitekturanalyse må sørge for at strukturelle sikkerhetsfeil oppdages og korrigeres. Programvarearkitekter må sørge for at standarder følges, og at godkjente sikkerhetsløsninger gjenbrukes.
Dypdykk i BSIMM del 7 – Standards and Requirements
I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Standards and Requirements, eller Standarder og krav.
Hovedmålet for praksisen “Standarder og krav” er å lage retningslinjer for alle interessenter. Ledere og programvaresikkerhetsgruppen (SSG) må dokumentere programvaresikkerhetsvalg, og formidle dette materialet til alle som er involvert i livssyklusen for sikker programvareutvikling (SSDL), inkludert eksterne aktører.
Hvordan står det til med programvaresikkerheten i norske offentlige virksomheter?
På oppdrag fra Difi har vi har fått 20 offentlige virksomheter til å fylle ut en egenerklæring om hvilke programvaresikkerhets-aktiviteter de utfører som en del av sine egne systemutviklingsprosesser.
Det offentlige gjennomfører en rekke digitaliseringsprosjekter, og utfører dermed mange aktiviteter knyttet til utvikling og anskaffelse av nye digitale løsninger. For at disse løsningene skal kunne håndtere de digitale sikkerhetstruslene, er det viktig at det jobbes systematisk med sikkerhet i utviklingsprosessen.
Hva var nå de derre BSIMM-greiene igjen?
Hvor god er sikkerheten – på en skala fra en til ti?
Informasjon er etter hvert blitt en av de mest sentrale verdiene i de fleste virksomheter. Man er avhengig av tilgang til og beskyttelse av regnskapsdata, kundedata, teknisk dokumentasjon, prosessbeskrivelser, osv. Man er også avhengig av systemer for å kommunisere og dele informasjon. Dette gjør informasjonssikkerhet til en essensiell oppgave. Likevel kan det være utfordrende for de med informasjonssikkerhetsansvar å vise hva deres arbeid bidrar med for virksomheten, og om sikkerhetsarbeidet drives på en effektiv måte.
For de som er opptatt av å følge sikkerhetsstandarden ISO 27001, er det et krav om å gjennomføre måling for blant annet å kunne vurdere om sikkerhetsaktivitetene blir utført etter hensikten, om sikkerhetstiltakene er virkningsfulle og om styringen av sikkerhetsarbeidet er effektiv. Men hvordan bør man egentlig gå frem når man skal måle, og hvilke ressurser kan være til hjelp i arbeidet?