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.
7 trykkpunkter for programvaresikkerhet
Programvaresikkerhet 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.
DevOps og/eller sikkerhet?
Første gang jeg hørt uttrykket “DevOps” var i en samtale med Gary McGraw under AReS-konferansen i Wien i 2011 – jeg tenkte ikke mye over det da, men i de siste par årene virker det som om DevOps har klatret til toppen av hype-syklusen, og det dukker opp over alt.
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.
Statisk analyse for smidig utvikling – er det mulig?
Som et slags bidrag til nasjonal sikkerhetsmåned, arrangerer vi 25. oktober nok et frokostmøte i samarbeid med Dataforeningen i Trondheim. Temaet denne gang er statisk analyse for sikkerhet.
Arkitekturanalyse som risikosport
Arkitekturanalyse (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.
Dra i gang høsten!
De fleste nyter nok en velfortjent sommerferie, men det skader ikke å tenke noen uker framover! Ta løpefart på høsten med faglig påfyll i august!
Protection Poker: Spill deg til bedre programvaresikkerhet!
Prof. 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.
Risikovurdering eller sjekkliste – hva er best?
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.
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.
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.
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. 
Sikkerhetsfolk 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.
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!
Tilbake til røttene: Prinsipper for programvaresikkerhet
Programvare 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.
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.
Vitenskaplig sikkerhet i smidig utvikling
Vi har nettopp fått finansiert et nytt forskningsprosjekt av Norges Forskningsråd – prosjektet SoS-Agile skal utforske hvordan man kan ivareta informasjonssikkerhet under smidig utvikling.