I 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.
Hovedmålet for praksisen Programvaremiljø er endringsledelse. De som er ansvarlige for programvaremiljøet må sørge for at de er i stand til å gjøre autoriserte endringer, og avdekke uautoriserte endringer. Ledere må sørge for at virksomhetens retningslinjer blir fulgt.
SE Nivå 1: Sørg for at programvaremiljøet støtter programvaresikkerhet.
Driftsgruppen sørger for at de nødvendige sikkerhetsmekanismene for datamaskiner og nettverk fungerer, og overvåker programvare proaktivt, inkludert input til applikasjoner.
- SE1.1: Overvåk input til applikasjonene
Virkosmheten overvåker input til programvaren den kjører for å oppdage angrep. For web-kode kan en Web Application Firewall (WAF) gjøre jobben. Programvaresikkerhetsgruppen (SSG) kan ha ansvaret for røkt av dette systemet. Det er ikke en del av denen aktiviteten å respondere på angrep. Tannløse WAFer som lager loggfiler kan være nyttige dersom noen gjennomgår loggene periodisk. På den annen side, en WAF som ikke overvåkes lager ingen lyd når en applikasjon faller i skogen. - SE1.2: Sørg for at grunnleggende system- og nettverkssikkerhetsmekanismer er på plass
Virksomheten tilbyr et solid fundament for programvare ved å sørge for at grunnleggende system- og nettverkssikkerhetsmekanismer er på plass. Det er vanlig at driftssikkerhetsgruppen har ansvar for oppgaver som patching av operativsystemer og vedlikehold av brannmurer. Å fokusere på programvaresikkerhet før du har nettverkssikkerheten på plass blir som å ta på seg buksene før man tar på seg undertøy.
SE Nivå 2: Bruk publiserte installasjonsveiledninger og kodesignering.
SSG må sørge for at programvareutviklingsprosesser beskytter integriteten til koden. SSG må sørge for at veiledninger for installasjon og vedlikehold av applikasjoner er utarbeidet for bruk av driftsgruppen.
- SE2.2: Publisér installasjonsveiledninger
Livssyklusen for sikker programvareutikling (SSDL) krever at det opprettes en installasjonsveiledning for å hjelpe operatører til å installere og konfigurere systemet på en korrekt og sikker måte. Hvis spesielle trinn er nødvendige for å forsikre at en installasjon er sikker, er disse trinnene skissert i instalasjonsveiledningen. Veiledningen bør omfatte diskusjon av hyllevare komponenter. I noen tilfeller er installasjonsveiledninger distribuert til kunder som kjøper programvaren. Evolverende DevOps og integrerte gruppestrukturer eliminerer ikke behovet for skrevne retningslinjer. Selvfølgelig er “sikker med standardinstillinger” alltid den beste måte å gjøre det på. - SE2.4: Bruk kodesignering
Virksomheten bruker kodesignering for programvare som gis ut på tvers av tillitsgrenser. Kodesignering er spesielt nyttig for å beskytte integriteten til programvare som forlater virksomhetens kontroll, slik som hyllevare applikasjoner eller tykke klienter. Det faktum at enkelte mobile plattformer krever at applikasjonskode er signert er ingen indikasjon på institusjonell bruk av kodesignering.
SE Nivå 3: Beskytt klient-side kode og overvåk oppførselen til programvare aktivt.
SSG må sørge for at all kode som forlater virksomheten er beskyttet. Driftsgruppen må overvåke oppførselen til programvaren.
- SE3.2: Bruk kodebeskyttelse
For å beskytte immaterielle rettigheter og gjøre det vanskeligere å lage exploits, oppretter virksomheten barriærer mot omvendt utvikling. Obfuskeringsteknikker kan anvendes som en del av produksjonsbygging og utgivelsesprosessen. Ved å anvende platform-spesifikke mekanismer som Data Execution Prevention (DEP), Safe Structured Error Handling (SafeSEH), og Address Space Layout Randomization (ASLR) kan man gjøre utvikling av exploits vanskeligere. - SE3.3: Anvend overvåking av applikasjonsoppførsel og diagnostikk
Virksomheten overvåker oppførselen til utrullet programvare og ser etter tegn på at den ikke oppfører seg som den skal eller andre symptomer på angrep. Denne aktiviteten går utover maskin- og nettverksovervåkning ved å se etter problemer som er spesifikke for programvaren, som f,eks, indikasjoner på svindel. Inntrengningsdeteksjons- og anomalideteksjonsprogramvare på applikasjonslaget kan fokusere på en applikasjons interaksjon med operativsystemet (gjennom systemkall), eller på applikasjonens interaksjon med de forskjellige typer data som den konsumerer, oppretter, eller manipulerer.