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.

AA Nivå 1: Utfør risikodrevne AA gjennomganger, ledet av SSG.

Virksomheten må gjøre et lettvekts risikoklassifiserings-skjema for programvare tilgjengelig. Programvaresikkerhetsgruppen (SSG) må begynne å lede arkitekturanalyseaktiviteter, spesielt i forbindelse med høyrisiko-applikasjoner, som en måte å bygge opp kompetanse internt og demonstrere verdien på designnivå.

  • AA1.1: Foreta gjennomgang av sikkerhetsmekanismer
    For å komme igang med arkitekturanalyse, fokuser prosessen på en gjennomgang av sikkerhetsmekanismer. Sikkerhetsbevisste evaluatorer identifiserer først skkerhetsmekanismer i en applikasjon (autentisering, aksesskontroll, bruk av kryptografi, osv.), og studerer så designet mens de leter etter problemer som kan få disse mekanismene til å feile eller på annet vis vise seg utilstrekkelige.For eksempel, et system som kunne utsettes for et angrep som ga forhøyede privilegier pga. håpløs aksesskontroll, eller et system som lagret usaltede passordhasher ville begge identifiseres i denne type gjennomgang. På høyere modenhetsnivåer vil denne aktiviteten komme i skyggen av en grundigere tilnærming til arkitekturanalyse som ikke kun er fokusert på mekanismer. I noen tilfeller kan bruk av virksomhetens sikker-ved-design komponenter strømlinjeforme denne prosessen.
  • AA1.2: Foreta designgjennomgang for høyrisiko applikasjoner
    Virksomheten lærer fordelene ved arkitekturanalyse ved å se håndfaste resultater for et utvalg høyrisiko applikasjoner med høy profil. Evaluatorene må ha noe erfaring med utføring av arkitekturanalyse og bryting av arkitekturen som studeres, Hvis SSG ikke enda er utstyrt for å utføre en arkitekturanalyse i dybden, bruker den konsulenter for å løse denne oppgaven. Ad hoc gjennomgangsparadigmer som hviler tungt på ekspertise kan brukes her, men i det lange løp skalerer det ikke.
  • AA1.3: La SSG lede gjennomgangsaktiviteter
    SSG tar en lederrolle rolle i gjennomføring av arkitekturanalyse for å begynne å bygge opp virksomhetens evne til å avdekke designfeil. Det å bryte en arkitektur er tilstrekkelig mye av en kunst til at SSG må være dyktig til det før de kan overlate jobben til arkitektene, og dyktighet krever øvelse. SSG kan ikke oppnå suksess alene, heller — de trenger sannsynligvis hjelp fra arkitektene eller utviklerne for å kunne forstå designet. Med et klart design for hånden kunne SSG utføre analysene med et minimum av interaksjon med prosjektgruppen. På høyere modenhetsnivåer flyttes ansvaret for å lede gjennomgangsaktiviteter til programvarearkitekter. Tilnærminger til arkitekturanalyse (og trusselmodellering) utvikler seg over tid. Ikke forvent å etablere en prosess og så bruke den til evig tid.
  • AA1.4: Bruk et risiko-spørreskjema for å rangere applikasjoner
    For å legge til rette for arkitekturanalyse og andre prosesser, bruker SSG et risiko-spørreskjema for å samle inn grunnleggende informasjon om hver applikasjon slik at det kan danne grunnlaget for et risiko-klassifisering og -prioriterings regime. Spørsmål kan inkludere «Hvilke(t) programmeringsspråk er applikasjonen skrevet i?», «Hvem bruker applikasjonen?», og «Håndterer applikasjonen sensitive personopplysninger?» Et kvalifisert medlem av utviklergruppen fyller ut spørreskjemaet. Spørreskjemaet er kort nok til å kunne fylle ut i løpet av et par timer. SSG kunne bruke svarene til å gruppere applikasjonen som høy, medium eller lav risiko. Ettersom det kan være lett å tilpasse seg et risiko-spørreskjema, er det viktig å utføre noen punktsjekker for validitet og nøyaktighet. En overdreven avhengighet av selv-rapportering og automatisering kan virke mot sin hensikt og gjøre denne aktiviteten impotent.

AA Nivå 2: Spre bruk av dokumentert AA-prosess.

SSG må legge til rette for bruk av arkitekturanalyse gjennom hele virksomheten ved å gjøre seg selv tilgjengelig som en ressurs og mentor. SSG må definere en arkitekturanalyseprosess basert på et felles arkitekturbeskrivelse-språk og standard angrepsmodeller.

  • AA2.1: Definer og bruk AA prosess
    SSG definerer og dokumenterer en prosess for å gjennomføre arkitekturanalyse, og anvender den i de designgjennomgangene de foretar. Prosessen inkluderer en standardisert tilnærming for å tenke rundt angrep og sikkerhetsegenskaper. Prosessen er definert grundig nok til at folk utenfor SSG kan læres opp til å utføre den. Man må særlig vie oppmerksomhet til dokumentasjon av både arkitekturen som vurderes og eventuelle feil som avdekkes. Stammekunnskap teller ikke som en definert prosess. Microsofts STRIDE og Cigitals ARA er eksempler på en slik prosess. Bemerk at også disse to metodikkene for arkitekturanalyse har utviklet seg betydelig over tid. Pass på å aksessere oppdaterte kilder for informasjon om arkitekturanalyse, ettersom mange tidlige publikasjoner er utdaterte og ikke lenger anvendbare.
  • AA2.2: Standardiser arkitekturbeskrivelser (inkludert dataflyt)
    Virksomheten bruker et format man har blitt enige om for å beskrive arkitektur, inkludert en måte å representere dataflyt. Dette formatet, kombinert med en arkitekturanalyseprosess, gjør arkitekturanalyse gjennomførbart for folk som ikke er sikkerhetseksperter. En standard arkitekturbeskrivelse kan forbedres til å gi et eksplisitt bilde av informasjonsverdier som trenger beskyttelse. Standardiserte ikoner som brukes konsistent i UML-diagrammer, Visio-maler og tusjtavle-klotring er spesielt nyttige.
  • AA2.3: Gjør SSG tilgjengelig som en AA ressurs eller mentor
    For å kunne bygge opp en evne til å utføre arkitekturanalyse utenfor SSG, averterer SSG seg som som en ressurs eller mentor for grupper som ber om hjelp til å gjennomføre sin egen designgjennomgang, og leter proaktivt opp nye prosjekter å involvere seg i. SSG besvarer spørsmål rundt arkitekturanalyse i kontortiden, og i noen tilfeller kan de også tilordne noen som kan sitte ved siden av arkitekten hele den tiden det tar å gjennomføre analysen. I det tilfellet det dreier seg om høyrisiko applikasjoner eller produkter , spiller SSG en mer aktiv mentor-rolle.

AA Nivå 3: Bygg opp kunnskap om revidering og forbedring av sikkerhetsfeil i arkitekturgruppen.

Programvarearkitekter må lede analyseaktiviteter på tvers av virksomheten, og må bruke analyseresultater for å lage og oppdatere arkitekturmønstre som er sikre.

  • AA3.1: La programvarearkitekter lede gjennomgangsaktiviteter
    Programvarearkitekter på tvers av virksomheten leder arkitekturanalyseprosessen mesteparten av tiden. SSG kan fortsatt bidra til arkitekturanalyse i en rådgivende rolle, eller i spesielle tilfeller. Denne aktiviteten krever en godt forstått og veldokumentert arkitekturanalyseprosess. Til og med i slike tilfeller er det vanskelig å oppnå konsistens, ettersom det å bryte en arkitektur krever så mye erfaring.
  • AA3.2: Mat analyseresultater inn i standard arkitekturmønstre
    Feil som identifiseres i løpet av arkitekturanalyse mates tilbake til sikkerhetsdesignkomiteen slik at tilsvarende feil kan unngås i framtiden gjennom forbedrede designmønstre. Sikkerhetsdesignmønstre kan samvirke på overraskende måter som bryter sikkerheten. Arkitekturanalyseprosessen bør derfor anvendes også når verifiserte designmønster er i standard bruk.

Gå direkte til neste episode her.

  • Det kan være ekstra nyttig å gjøre gjennomgang med mer enn en arkitekt til stede for å beskrive arkitekturen. Da kan viktige funn gjerne komme av seg selv, ettersom forståelsen av arkitekturen varierer og dette fort blir åpenbart med flere til stede. Både nyttig, og potensielt interessant å bivåne 🙂