Dypdykk i BSIMM del 1 – Configuration and vulnerability management

privacy-policy-445156_1280Etter 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:

  • CMVM3.1: Fiks alle programvarefeil som oppdages i driften
    Dette betyr ikke bare de som har generert feilrapporter
  • CMVM3.2: Utvid organisasjonens SSDL til å forhindre feil som oppdages i driften
    Det er selvfølgelig bra å være i stand til å oppdage feil etter at programvare er satt i drift, men de er enda bedre å unngå å introdusere dem i det hele tatt.
  • CMVM3.3: Simuler programvarekriser
    Kjør beredskapsøvelser hvor man tester evnen til identifisere og håndtere spesifikke trusler, evt. hvor man antar et en kritisk komponent er kompromittert, og evaluerer organisasjonens evne til å håndtere situasjonen.
  • CMVM3.4: Skuddpremie på programvarefeil
    Systematisk og kontinuerlig, utbetalinger i forhold til alvorligheten på den oppdagede feilen.

Hvilket BSIMM-tema skal vi ta neste gang? Kommenter under eller tweet!



Gå direkte til neste episode her.