Noen og enhver kjenner sikkert på følelsen av «zoom fatigue», men i mangel av fysiske møteplasser arrangerer vi nok et virtuelt fellesmøte med ISF, ISACA, CSA Norge og Dataforeningen!
Sikkerhetsoperasjoner
Det å passe på sikkerheten til et system etter at det har vært satt i drift, har tradisjonelt vært sett på som en (ja, nettopp) driftsoppgave som «de på IT» tar seg av.
Et vellykket programvaresikkerhetsinitiativ må imidlertid også omfatte sikkerhetsoperasjoner eller nettverkssikkerhet, for å sørge for full tilbakekopling til utviklerne.
Kan NSMs grunnprinsipper for IKT-sikkerhet brukes for prosesskontroll-systemer?
Nasjonal sikkerhetsmyndighet har gitt ut en samling tiltak for IKT-sikkerhet i I(K)T-systemer. På oppdrag fra Ptil har vi gjennomført en evaluering av disse tiltakene, og finner at med noen få unntak er de relevante også for prosesskontrollsystemer i petroleumsindustrien, men at en del tiltak krever noen ekstra tillempninger.
Sju (pluss/minus to) steg til bedre program-varesikkerhet

Programvaresikkerhet handler om sikker funksjonalitet snarere enn sikkerhetsfunksjonalitet, dvs. å lage programvare slik at den oppfører seg som forventet også når den utsettes for angrep. Det finnes en lang rekke anbefalte aktiviteter som kan bidra til å nærme seg dette målet, men hvor skal man begynne? Etter fem års forskning på dette temaet har vi et forslag til ni steg som kan representere en slik begynnelse.
Statisk kildekodeanalyse
Testing av pacemakere – øvelse gjør mester!

En pacemaker er ikke en frittstående enhet som opereres inn i en pasient og deretter overlates til seg selv i årevis uten noen form for kommunikasjon med omverdenen. Introduksjon av telemedisin og fjernovervåking har medført at det faktisk kreves et helt økosystem for å holde en pacemaker i korrekt og effektiv drift.
Virtuelt møte om EU-forskning 24. juni

I regi av Referansenettverk for Digital Sikkerhet arrangerer vi 24/6 et virtuelt møte for å snakke om muligheter for deltagelse i EU-prosjekter generelt, og spesielt om hva som skjer i det nye programmet Horizon Europe.
Noen oppklarende formuleringer rundt det kommende «European Cybersecurity Industrial, Technology and Research Competence Centre» og eventuelle norske avleggere

EU har lansert en forordring [1][2] hvor hvert medlemsland (og presumtivt EØS-land) skal opprette et nasjonalt koordineringssenter for cybersecurity. I tillegg skal det opprettes et nettverk («Cybersecurity Competence Community») bestående av sentrale aktører fra industri, akademia og det offentlige; og et «European Cybersecurity Industrial, Technology and Research Competence Centre». Både det nasjonale og det europeiske senteret vil ha som ansvar å tildele finansiell støtte, henholdsvis i det nasjonale økosystemet og knyttet til implementasjonen av Digital Europe- og Horizon Europe-programmene. Som en del av forarbeidet har H2020 finansiert 4 «Piloter» [3][4][5][6], som skal definere hvordan det europeiske kompetansesenter skal fungere. Det er norske deltakere i CyberSec4Europe [3] (NTNU og SINTEF) og Concordia [4] (UiO, Storbyuniversitetet og Telenor).
Oppdatering fra Referansenettverk for digital sikkerhet

Som mange lesere av bloggen sikkert husker, ble Referansenettverk for digital sikkerhet opprettet for å øke deltagelsen av norske virksomheter i europeisk sikkerhetsforskning. Vi vil prøve å øke aktivitetsnivået i vår – foreløpig på virtuelle arenaer.
Et nytt fellesmøte i toppsjiktet

26. februar braker det løs igjen, med et nytt fellesmøte med Dataforeningen, ISF, ISACA og CSA Norge. Som vanlig stiller et spennende knippe av foredragsholdere, og i tillegg til det faglige blir det god anledning til relasjonsbygging akkompagnert av inntak av pizza og prøvesmaking av lokale produkter.
Penetrasjonstesting
Ifølge Gary McGraw hviler programvaresikkerhet på tre pilarer:

- Anvendt risikostyring: Ta på deg den svarte hatten din for å avdekke alle mulige trusler. Utfør risikoanalyse på arkitekturnivå, dvs. trusselmodellering med mere. Risiko må spores og motvirkes kontinuerlig gjennom hele utviklingslivssyklusen.
- Trykkpunkter for programvaresikkerhet: Identifiser kjerneaktiviteter som bidrar til forbedret programvaresikkerhet, og sørg for at sikkerhet blir tatt hensyn til i hvert steg av programvareutviklingssyklusen. Microsoft sitt Tiltrodde databehandlingsinitiativ (Trustworthy Computing Initiative) fra 2002 er et eksempel, som resulterte i Microsoft SDL (og senere SDL Agile).
- Kunnskap og god praksis: Alle utviklere må ha et minimum av sikkerhetskunnskap, og kunne bruke sjekklister som OWASP Top 10.
Sikkerhetsstandarder og evaluering

Det finnes mange sikkerhetsstandarder, og mange av disse går det an å sertifisere etter. Når vi sier «sikkerhetsevaluering», mener vi vanligvis å bruke ISO/IEC 15408, også kjent som Common Criteria. Andre kjente standarder omfatter ISO/IEC 27001, ISF Standard Good Practice, ITIL, og COBIT. Disse fokuserer mer på hvordan organisasjonen er bygget opp (rutiner etc.) enn på hvordan man utvikler programvare.
Smidig utvikling og programvaresikkerhet

Smidighetsbevegelsen representerer alternativer til tradisjonell prosjektledelse i utviklingsprosjekter. Smidige metoder brukes typisk for å la utviklingsorganisasjoner respondere på usikkerhet og uventet hendelsesforløp. Scrum er den mest populære måten å introdusere smidighet, på grunn av sin enkelhet og fleksibilitet.
Innebygget sikkerhet

I en artikkel i IEEE S&P for mange år siden diskuterte Bruce Schneier hva som gjør at vi «kjøper» sikkerhet. Hvorfor får sikkerhetsoppgaver alltid lavere prioritet enn andre oppgaver? Hvorfor er utviklere generelt så lite interesserte i sikkerhet? Eksperter forteller stadig vekk utviklere at de må tenke er på sikkerhet, så hvorfor gjør ikke alle det? Hvorfor innser ikke ledere at de må sørge for å ha sikkerhetseksperter i utviklingsgruppen, på samme måte som de gjør med testere?
Innebygget personvern

Innføringen av GDPR var en gullgruve for mange konsulentselskaper – mange firma var usikre på hva det ville medføre, og brukte hundre-tusenvis av kroner på å bli «GDPR-klare». En av de mest merkbare konsekvensene av GDPR var at mange virksomheter så seg nødt til å vaske epostlistene sine, og slette alle mottakere som ikke hadde gitt eksplisitt samtykke. Derfor fikk mange av oss gjentatte eposter hvor vi ble bedt om å bekrefte at vi fortsatt vill stå på epostlisten.
Risiko og programvaresikkerhet

Risiko er noe vi må leve med, men dessverre er det også noe de fleste av oss er veldig dårlige til å vurdere. En vanlig måte å beregne risiko på er å multiplisere konsekvensen av en hendelse med sannsynligheten for at den sal oppstå. Man illustrerer dette gjerne i en risikomatrise, der sannsynlighet er en akse, og konsekvens er den andre. I World Economic Forums risikorapport for 2019 finner vi cyberangrep langt opp til høyre i matrisen, kun slått av klimaendringer, ekstremvær og naturkatastrofer (som for meg egentlig høres ut til å være det samme).
Den som tror han er ferdig utlært er ikke utlært, men ferdig
Svart som hatten
Nok en tiltrekkende arbeidsbutikk!
I begynnelsen av juni arrangerte vi nok en gang «International Workshop on Secure Software Engineering in DevOps and Agile Development» (SecSE 2019), denne gang som en del av konferansen Cyber Security i Oxford.
Risiko ved tettere integrasjon i strømnettet

Høsten 2018 utførte vi en risikoanalyse på oppdrag fra NVE, hvor vi så på effekten av en fremtidig tettere integrering mellom AMS, DMS og SCADA-nettverk som brukes til å styre strømnettet. Bakteppet er flere kjente tilfeller av angrep mot SCADA-systemer i energisektoren, fra Stuxnet i 2010 via Dragonfly-kampanjen i 2014, angrepene mot det Ukrainske strømnettet i 2015 og 2016 (hhv. Blackenergy 3 og Industroyer), til Triton-angrepet i Saudi-Arabia i 2017. Alt tyder på at tettere integrasjon er noe som kommer, og at truslene er noe man må ta på alvor.



