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

Aller først er det viktig å lage en overordnet beskrivelse eller modell av systemet. Man bør altså starte med “det store bildet” – sagt på en annen måte: fokuser på skogen, ikke trærne. En måte å gjøre dette på kan være å bruke UML-diagrammer, men det kan like gjerne være andre former for bokser og piler. En slik beskrivelse er nyttig å skjele til under selve analysen (hvis den f.eks. er tegnet opp på en tavle i møterommet) , men bidrar også til å forsikre at alle som deltar i analysen er enige om hvordan systemet ser ut og henger sammen. Mange ganger kan det dukke opp viktig informasjon rett og slett som resultat av å tegne opp systemet på denne måten.

En arkitekturanalyse har tre kritiske steg, hvor man analyserer motstandsdyktighet mot angrep, tvetydigheter, og sårbarheter.

Angrep

En angrepsanalyse kan gjerne være sjekklisteorientert (a la STRIDE), der vi basert på en en-siders beskrivelse av systemet prøver å vurdere hvordan vi står oss mot kjente angrep. Vi vil først prøve å identifisere generelle feil fra litteraturen som kan være relevante, og dernest kartlegge eller utarbeide angrepsmønstre, f.eks. via misbrukstilfeller (misuse cases). Deretter vil vi prøve å identifisere risikoer i arkitekturen basert på sjekklister (som STRIDE, men også andre kilder), og til slutt for hvert identifiserte angrep anstrenge oss for å forstå og demonstrere angrepets gjennomførbarhet.

Et angrepsmønster er en generell beskrivelse av en type angrep; det finnes en samling slike mønstre hos Mitres CAPEC prosjekt. Et eksempel på et slikt angrepsmønster er CAPEC-278: Web Services Protocol Manipulation.

STRIDE er en huskeliste for typer av angrep, introdusert av Swiderski  og Snyder:

• Spoofing (gi seg ut for å være noen andre)
• Tampering (urettmessig endring)
• Repudiation (fornektelse)
• Information disclosure (røping av informasjon)
• Denial of Service (tjenestenekting)
• Elevation of privilege (urettmessig forhøying av rettigheter)

STRIDE brukes gjerne i sammenheng med en tilsvarende liste for klassifisering av alvorlighetsgrad, DREAD:

• Damage (skade som kan forvoldes)
• Reproducibility (hvor lett er det å gjenta et angrep)
• Exploitability (mulighet for utnyttelse)
• Affected users (hvor mange brukere kan bli påvirket)
• Discoverability (hvor lett er det for noen å oppdage/finne på angrepet)

Tvetydigheter

Jakten på tvetydigheter er en kreativ aktivitet for å oppdage nye risikoer, den fungerer best med to eller flere analytikere (som har noe erfaring). Deltakerne bruker tid på å analysere systemet hver for seg, og møtes for en plenumsdiskusjon etterpå. Hver og en beskriver så hvordan vedkommende mener at systemet skal fungere, og dersom det er uenigheter om noen detaljer vil disse være glimrende kandidater for tvetydigheter. Uenighet er derfor en god ting i denne fasen! Hvis uenigheten kan bekreftes som en reell tvetydighet, må den studeres nøyere for å avgjøre om tvetydigheten kan utnyttes av en angriper på noe vis.

Underliggende sårbarheter

Her tenker vi på sårbarheter som ikke stammer fra koden du skriver selv, men fra eksterne avhengigheter som plattformen du kjører på, etc. Det er viktig å analysere alle hyllevare-komponenter og biblioteker som brukes i ditt system, og ha tilgang på oppdaterte oversikter av feil og sårbarheter i disse. Det samme gjelder rammeverk som J2EE, .NET, etc. som du bruker. Nettverkstopologien er også relevant; det er forskjell på en baksystem-applikasjon begravd i brannmmurer og proxyer, og en webapplikasjon med direkte eksponering mot internett. Det samme kan sies om de fysiske omgivelsene; kjører applikasjonen i et miljø som du kontrollerer, eller er det en klientapplikasjon som kjører på sluttbrukerens eget utstyr?

Plattformen applikasjonen kjører på kan variere fra et rack i et profesjonelt datasenter via en vanlig PC til en smart-telefon, og de kan hver og i sær ha egne utfordringer. Også utviklingsmiljøet må vurderes, i hvilken grad finnes det egenskaper som bidrar til flere eller færre feil? Til slutt, hva slags antagelser gjøres om ekstern programvare, og hva skjer når antagelsene brytes?

For mer om arkitekturanalyse, se f.eks. https://buildsecurityin.us-cert.gov/articles/best-practices/architectural-risk-analysis/architectural-risk-analysis eller http://swsec.org/resources/

Illustrasjon ved Klearchos Kapoutsis CC BY 2.0