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

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.

Cyberforsikring – hva vet vi fra forskningen?

report-frontpageDet å 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.

Dypdykk i BSIMM del 12 – Software Environment

LibertyBudget.com-Install-Computer-Software-CD-2400pxI 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

johnny-automatic-hydraulic-press-testingI 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

penetrationI 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

code-reviewI 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

laurent-comparaison-art-roman-art-gothiqueI 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

2A0---A4I 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 interes­senter. Ledere og programvaresikkerhetsgruppen (SSG) må dokumentere programvaresikkerhetsvalg, og formidle dette materialet til alle som er invol­vert i livssyklusen for sikker programvareutvikling (SSDL), inkludert eksterne aktører.

Hvordan står det til med programvaresikkerheten i norske offentlige virksomheter?

BSIMM3-logoPå 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.

Hvor god er sikkerheten – på en skala fra en til ti?

Flickr-user whoswho: Measurement (Creative Commons with attribution)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?