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. Les hele innlegget

Sikkerhet og robusthet i IKT-systemer

Norge er i dag fullstendig avhengig av IKT. For at våre IKT-systemer skal fungere er det nødvendig at de er både beskyttet (sikre) og at de fungerer (robuste). Selv om disse to aspektene er like viktige så er de fleste av oss i praksis opptatt av kun det ene eller det andre. training-iconSikkerhetsfolk tenderer til å fokusere på hvordan unngå at sårbarheter kan utnyttes for å angripe et system, og ignorerer ofte andre aspekter som responstid, oppetid og effekten av fysiske feil som kan oppstå i underliggende infrastruktur. Pålitelighetsfolk tenderer til å bara se på tilfeldige feil som oppstår i programvare og maskinvare, og ignorerer dermed konsekvenser av angrep og ondsinnede handlinger. Les hele innlegget

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.

Les hele innlegget

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! Les hele innlegget

Tilbake til røttene: Prinsipper for programvaresikkerhet

BuildingSecureSoftwareProgramvare blir stadig viktigere for alle deler av samfunnet, og det er økende bevissthet om at det er viktig med kvalitet og sikkerhet også i programvare. Sikkerhetsfeil i programvare er roten til mange av sikkerhetsutfordringene man opplever. Det har skjedd mye på programvaresikkerhetsområdet de siste årene, og det har dukket opp mange nye rammeverk og metoder man kan benytte for ulike deler av utviklingsprosessen. Det er bra. Samtidig kan det være nyttig også å se tilbake, for å gjenoppdage noe av det som har formet dette arbeidet og som har stått seg over flere år. I anledning av at vi i disse dager starter opp et nytt forskningsprosjekt innen programvaresikkerhet, gir vi en kort oversikt over 10 prinsipper for programvaresikkerhet, hentet fra en bok som har betydd mye for området, nemlig Viega og McGraws bok “Building Secure Software” fra 2001.

Les hele innlegget

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. Les hele innlegget

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.
Les hele innlegget

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.

Les hele innlegget

Dypdykk i BSIMM del 6 – Security Features & Design

Security Features of the US Twenty Dollar BillI vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Security Features & Design, eller sikkerhetsfunksjonalitet og design. En “feature” er kanskje egentlig heller en egenskap, men i de fleste tilfeller dreier det seg om funksjonalitet, så vi kjører videre med det.

Hovedmålet for denne praksisen er etablering av tilpasset kunnskap om sikkerhetsegenskaper, rammeverk og mønster. Den tilpassede kunnskapen må drive arkitektur- og komponent-beslutninger.

Les hele innlegget

Dypdykk i BSIMM del 4 – Training

joggerHvordan kan du vite at du håndterer en oppgave hvis du aldri har gjort den før? Opplæring er svaret, og Øvelse gjør mester – og den som tror at han er ferdig utlært, er ikke utlært, men ferdig. Programvaresikkerhetsgruppen (SSG) spiller en viktig rolle her!

I vår serie om innebygd målbar sikkerhet og BSIMM, skal vi denne gangen skal vi se nærmere på Training, eller opplæring og øvelser. Hovedmålene for denne praksisen er å utdanne en kunnskapsrik arbeidsstokk og rette opp feil i prosesser. Arbeidsstokken må ha rolle-basert kunnskap som spesifikt inkluderer ferdighetene som kreves for å utføre deres SSDL-aktiviteter på en hensiktsmessig måte. Opplæringen må omfatte spesifikk informasjon om rotårsaker til feil som oppdages i prosessaktiviteter og resultater.

Les hele innlegget

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. Les hele innlegget

Sikkerhet & sårbarhet 2015

stand-dndsos13Konferansen Sikkerhet & sårbarhet arrangeres 5.-6. mai i Trondheim. Denne gang blir SINTEF upåklagelig godt representert, med både tre faglige foredrag og som partner med stand. I følge arrangøren er dette møtestedet for alle som er opptatt av hva god informasjonssikkerhet kan bety for egen virksomhet. Det skulle vel med andre ord være gode muligheter for at vi sees her.

Les hele innlegget

Dypdykk i BSIMM del 3 – Compliance & Policy

checklist“Security Policy” er et av mange ord som ikke har en fullgod norsk oversettelse, noe som medfører at mange bruker bastard-begrepet “sikkerhets-policy”. Muligens kan man oversette det med “sikkerhetsinstrukser og strategi”, men jeg er usikker på om det treffer helt (noen foreslo nettopp “sikkerhetsretningslinjer” – det er kanskje bedre).

I vår serie om innebygd målbar sikkerhet og BSIMM, skal vi denne gangen skal vi se nærmere på “Compliance and Policy”, som vi forsøksvis kunne oversette med “Etterlevelse av regler og retningslinjer”.

Les hele innlegget

Litt statistikk om forskning på cybersecurity i Europa

Bilde fra eurosport.com

Bilde fra eurosport.com

Dr. Florent Frederix fra Trust and Security Unit hos EU-kommisjonen presenterte i januar under et informasjonsmøte i Birmingham for forskningsaktiviteter knyttet til cybersecurity. Norge har gjort det ganske bra, men det viktigste er jo selvfølgelig at vi slår svenskene med god margin! Les hele innlegget

Med BSIMM på øret

Synes du det er vanskelig å få tak på hva BSIMM er for noe? Gary McGraw laget for noen år siden er serie podcaster hvor han intervjuet representanter fra et knippe virksomheter som hadde deltatt i den første BSIMM-studien. Hør hva ekspertene har å si, og bli venn med begreper som “SSG” og “the satellite”!

Les hele innlegget

Privacy by Design – fina ord men lite verkstad?

f-inbyggdintegritet-rund

Bild från www.datainspektionen.se

Privacy by design (PbD), även kallat innebygd personvern på norska (och inbyggd integritet på svenska), är ett begrepp som får mer och mer uppmärksamhet. Min kollega Erlend har i ett tidigare blogginlägg gått igenom konceptet och förklarat vad det innebär. Kort sagt så handlar det om att man ska tänka igenom hur personupplysningar ska kunna skyddas i tex ett nytt IT system, en ny programvara eller en ny app, och det ska man göra redan från förstudie och kravställning, via design och utveckling, till användning och avveckling av systemet/programvaran/appen. Les hele innlegget

Du trenger en programvaresikkerhetsgruppe!

nuclear-forensicsI enhver organisasjon som utvikler programvare må det finnes noen som har ansvaret for programvaresikkerheten. I BSIMM-studien fant de at ALLE virksomhetene som ble undersøkt hadde en programvaresikkerhetsgruppe (software security group – SSG) – den kan være så liten som en person, men den må være der.

Les hele innlegget

Dypdykk i BSIMM del 2 – Attack Models

attack-catfrokostmøtet om måling av sikkerhet fikk jeg et godt spørsmål som jeg ikke kunne svare på: “Hvilket nivå skal man legge seg på?”  Mitt ikke-svar var at “da må du gjøre en risikobasert vurdering”, som egentlig bare er en annen måte å si “det kommer an på”. I utgangspunktet hadde jeg sagt at “alle” burde kunne starte med aktivitetene på nivå 1 i hver praksis, men her skilte aktivitet AM1.1 seg ut i tallmaterialet – bare 21 av de 67 undersøkte bedriftene vedlikeholder en liste av de topp N mulige angrepene mot seg selv. Dette virker som en ganske grei aktivitet å gjøre et par ganger i året, og jeg finner ingen god forklaring på hvorfor det ikke gjøres.

Les hele innlegget