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.

Arkitekturanalyse som risikosport

architecturalriskArkitekturanalyse (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.

Security Culture Conference 2016

14-15 juni braker det løs med en ny utgave av “sommerens vakreste eventyr”. I år har CSA Nordic Summit slått seg sammen med Security Culture Conference i et heidundrande to-for-en-tilbud med bøttevis av kjente navn på talerlisten.

Vi kommer til å bidra på flere plan, bl.a. med siste nytt fra OJ!, SINTEFs eget internprogram for sikkerhetskultur.

Om å la andre ta seg av hendelseshåndteringen

passing-the-buck Denne uken har jeg vært i Vancouver for å delta på CloudCom-konferansen, og har presentert en artikkel basert på masteroppgaven til Alfredo Reyes (som jeg veiledet i vår).

Det har skjedd en stor utvikling i tjenesteproduksjon i senere år, fra overveiende bruk av lokal datakraft, via tradisjonell tjenesteutsetting, til dagens økende bruk av nettskyen.

Ukens myte: Vi har ikke råd til sikkerhet

poorunclesam-800pxOfte blir sikkerhet sett på som en ekstra kostnad. En sikkerhetsansvarlig som prøver å sanke støtte hos ledelsen for investering i sikkerhetstiltak må argumentere for en positiv avkastning på investeringen (ROI). Dette blir vanskelig hvis man ikke kan vise til noen sikkerhetshendelser – da kan det tvert i mot se ut som om investeringene var overdrevet eller direkte bortkastet. Pussig nok er dette aldri en problemstilling i HMS-verdenen, men dette kan forklares ut fra samfunnets vilje til å bruke mye penger hvis det kan redde livet til et eneste menneske.

Alle vil ha sikkerhet, men ingen vil betale for det

rejection-ideogram-2400pxSikkerhet er aldri gratis. Selv når man ikke betaler i rene penger, må brukere av sikkerhet akseptere at ting tar lengre tid, medfører mer plunder, eller er mindre spennende enn de ellers kunne ha vært. Et relevant eksempel er ramaskriket over oppdagelsen av de påståtte falske GSM-basestasjonene på forskjellige strategiske plasser i Oslo i fjor, som man antok kunne tillate sporing og avlytting av topp-politikere og ledende forretningsfolk.

Ukens myte: Vi trenger ikke sikkerhet

Sikkerhet og personvern er begreper som har mye med hverandre å gjøre, men de er selvfølgelig ikke synonymer. Den klassiske oppdelingen av sikkerhet i konfidensialitet, integritet og tilgjengelighet gjør det fristende å konkludere at personvern ikke har noe å gjøre med de to siste, og følgelig på et eller annet vis må være relatert til konfidensialitet. Det er imidlertid et subtilt skille mellom personvern og konfidensialitet; mens det på den ene siden er åpenbart at man kan sikre personvernet med knallhard anvendelse av konfidensialitet, finner vi i det virkelige liv at vi er nødt til å utveksle forskjellige typer personopplysninger med andre instanser, slik at konfidensialitet for vår egen del aldri kan være nok alene. Videre er det slik at selv om vi deler personopplysninger nå, ønsker vi ikke nødvendigvis at disse skal være tilgjengelig for motparten for lang tid framover, og i hvert fall ikke for andre formål enn de ble samlet inn.

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.