Cybersecurity forskningsgruppe
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.
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.
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.
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.
På CLOSER-konferansen har jeg nylig presentert artikkelen “Cloud Provider Transparency – A View from Cloud Customers” forfattet av Daniela S. Cruzes og undertegnede. Artikkelen fikk “Best paper award“, og vi spanderer derfor på oss et lite sammendrag her:
Nettskyen kommer med mange fordeler, men bekymringer rundt sikkerhet og personvern gjør at mange potensielle brukere vegrer seg. I prosjektet A4Cloud argumenterer vi for at Accountability (som vi fortsatt ikke har noe godt norsk ord for) kan være det som skal til for å døyve bekymringene.
I 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.
I vår serie om innebygd målbar sikkerhet og BSIMM, skal vi denne gangen skal vi se nærmere på Strategy & Metrics, eller Strategi og Måling. I følge vår undersøkelse blant 20 norske offentlige virksomheter, er dette noe vi er rimelig dårlige på her på berget. Hvorfor?
Hvordan 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.
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.
På Sikkerhetskonferansen 2015 arrangert av Nasjonal Sikkerhetsmyndighet holdt jeg et innlegg om hvordan det er mulig å opprette falske GSM basestasjoner og hvorfor ting fungerer slik de gjør. I dette blogginnlegget skal jeg kort innom historikken til GSM-standarden for mobiltelefoni, beskrive hvilke enheter som inngår i et GSM nettverk, og hva som skjer når du ringer i en mobiltelefon. Deretter blir det litt konkrete detaljer om falske basestasjoner, og noen betraktninger rundt hvilke valg vi tar når vi kommuniserer – hvordan vi forholder oss til sikkerhet kontra brukervennlighet.
Torsdag 12. mars arrangerer ISF, ISACA, og Dataforeningen felles medlemsmøte i Trondheim. Møtet finner sted på DIGS, Olav Tryggvasons gate 30. http://www.digs.no/
Sett av ettermiddagen, og møt opp!
“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”.
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”!
16. desember slo SINTEF Energi og SINTEF IKT sine krefter sammen og arrangerte et tverrfaglig seminar om forsyningssikkerhet i kraftsystemet. Møtet samlet 33 personer fra både kraft- og IKT-miljøer, og rettet fokus mot at forsyningssikkerheten i stadig større grad er avhengig av IKT-systemer for vern, kontroll og automatisering.
I 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.
Den siste uka er det mange som som har uttalt seg harmdirrende om sporing og avlytting av GSM-trafikk via falske basestasjoner. Vi kjenner saken kun fra mediene, og kan ikke si så mye om hva som har skjedd eller ikke skjedd, men for oss fremstår det (på samme måte som for tidligere professor Svein Knapskog) som noe av en storm i et vannglass.
På CSA EMEA Congress i Roma i forrige måned ble det arrangert en paneldiskusjon med et knippe skyleverandører (Atos Canopy, Adobe, Google, Dropbox, Microsoft). Paneldebatter kan være så ymse, men det gir ofte mulighet til å stille åpne spørsmål. Jeg benyttet anledningen til å spørre om hvordan leverandørene håndterer deling av hendelsesinformasjon i leverandørkjeder.
På frokostmø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.
Etter utallige oppfordringer kommer endelig neste episode i vårt dypdykk i BSIMM – akkurat tidsnok til fredagens frokostmøte! Vi starter bakerst, med konfigurasjons- og sårbarhetshåndtering.
En av tesene i BSIMM er at hvis du driver programvareutvikling trenger du en programvaresikkerhetsgruppe (SSG). Kanskje består gruppen kun av en person, men den må være der. BSIMM tar utgangspunkt i SSG og utviklerne rundt den.