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.

BSIMMs programvaresikkerhetsrammeverk er som kjent delt inn i fire domener som hver er delt inn i 3 praksiser. Hver praksis består av et antall aktiviteter fordelt på 3 nivåer, der det laveste nivået omfatter aktiviteter som alle virksomheter burde kunne initiere, mens de høyere nivåene blir mer for viderekomne.

Det overordnede målet for praksisen “konfigurasjons- og sårbarhetshåndtering” er endringshåndtering – holde styr på autoriserte endringer, og avdekke og/eller forhindre uautoriserte endringer.

Nivå 1

Det laveste nivået handler om å få det som observeres i driften til å drive utviklingen, og har to aktiviteter:

• CMVM1.1: Opprett eller opprett kontakt med hendelseshåndtering
  Hvis organisasjonen har en CSIRT eller lignende, sørg for å opprette kontakt mellom denne og utviklerne. Hvis ikke, opprett en egen gruppe (med utgangspunkt i SSG) for å håndtere hendelser som har innvirkning på programvare.
• CMVM1.2: Identifiser programvarefeil som oppdages ved overvåkning av driften, og mat disse tilbake til utviklingsavdelingen
  IDS og andre sikkerhetsverktøy kan oppdage uregelmessigheter som har sammenheng med programvare som er utviklet internt, f.eks. angrep som utnytter spesifikke sårbarheter. Det er viktig at slik informasjon flyter tilbake til utviklerne, slik at feilene kan rettes og hullene tettes.

Nivå 2

Det midterste nivået handler om å sørge for at krisehåndtering er tilgjengelig når en applikasjon er under angrep, og har tre aktiviteter:

• CMVM2.1: Ha et system for å gjøre  hurtige krise-endringer i koden når en applikasjon er under angrep
  Systematikk er nøkkelordet – her holder det ikke med ad hoc løsninger.
• CMVM2.2: Hold styr på programvarefeil som er funnet i driften gjennom hele opprettingsprosessen
  Ivareta en toveis forbindelse mellom de som finner feil og de som fikser feil.
• CMVM2.3: Opprett en katalog over applikasjoner for driften
  Organisasjonen må ha et kart over hvor programvare er rullet ut – hvis en kodebit må endres, kan de som driver systemene identifisere alle stedene hvor endringen må installeres.

Nivå 3

Det øverste nivået handler om å lage en lukket sløyfe hvor sikkerhetsoperasjoner og utvikling inngår som en del av et naturlig hele. Her er det fire aktiviteter: