Hva dekker CISSP Domain 3?

CISSP Domain 3 dekker sikkerhetsarkitektur og ingeniørarbeid, der teori om sikkerhetsmodeller, kryptografi og systemdesign brukes til å styre praktiske arkitekturvalg.

CISSP Domain 3, Security Architecture and Engineering, dekker prinsippene som brukes til å designe, bygge, evaluere og vedlikeholde sikre informasjonssystemer. I gjeldende CISSP-rammeverk fra (ISC)² handler domenet blant annet om sikkerhetsmodeller, sikre designprinsipper, kryptografi, fysisk sikkerhet, tekniske kontroller, systemlivssyklus og vurdering av sikkerhetsarkitektur.

Sist oppdatert: 2026. Innholdet er kvalitetssikret mot den publiserte CISSP-emneoversikten fra (ISC)², relevante begreper fra NIST SP 800-160 og NIST SP 800-53, samt kontrollspråk som ofte gjenfinnes i ISO/IEC 27001 Annex A. Disse kildene brukes her som faglig rammeverk, ikke som erstatning for offisielt eksamensmateriell.

Hvorfor Domain 3 er mer enn tekniske definisjoner

Sikkerhetsarkitektur beskriver hvordan en organisasjon strukturerer sikkerhet på tvers av systemer, data, nettverk, identiteter og drift. Sikkerhetsteknikk er gjennomføringen av dette designet: konfigurasjoner, kontroller, testregimer, endringsprosesser og tekniske valg som gjør arkitekturen operativ.

Domain 3 er derfor et brofag. Det kobler risikostyring til konkrete designvalg, for eksempel hvordan data klassifiseres, hvor nøkler lagres, hvordan systemkomponenter isoleres, og hvilke kontroller som er nødvendige for å beskytte konfidensialitet, integritet og tilgjengelighet. Kandidater som kun pugger modellnavn, får ofte problemer når eksamensspørsmålet ber om det mest hensiktsmessige tiltaket i en gitt forretningssituasjon.

En nyttig beslutningsramme er å begynne med det primære sikkerhetsmålet: er problemet konfidensialitet, integritet eller tilgjengelighet? Deretter identifiseres trussel og aktør, før arkitekten vurderer relevante modeller og mønstre som Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash eller Zero Trust. Først etter dette bør kontrollen velges, og valget må kunne begrunnes ut fra drift, ytelse, vedlikehold og risiko.

Hva inngår i CISSP Domain 3?

Den offisielle CISSP-strukturen endres over tid, men Domain 3 dreier seg fortsatt om hvordan sikre systemer blir designet og validert. Kandidaten forventes å forstå hvordan prinsipper som minste privilegium, separasjon av oppgaver, forsvar i dybden, feilsikre standarder og sikker standardkonfigurasjon påvirker arkitektur. Dette gjelder både tradisjonelle datasentre, skyplattformer, hybride miljøer og moderne applikasjonsplattformer.

Kryptografi er et sentralt område, men eksamen tester sjelden ren algoritmepugging alene. Det viktigste er å skille mellom formålene: kryptering beskytter konfidensialitet, hashing støtter integritetskontroll, digitale signaturer gir autentisitet og ikke-benekting, og nøkkelhåndtering avgjør om løsningen faktisk er trygg over tid. Et design kan bruke sterke algoritmer og likevel være svakt dersom nøkler lagres feil, roteres tilfeldig eller deles på tvers av miljøer uten kontroll.

Fysisk sikkerhet inngår også, men bør forstås som en del av totalarkitekturen. Adgangskontroll til datasentre, sikring av nettverksrom, miljøkontroller, kameraovervåking og mantraps er ikke sideemner; de beskytter tekniske kontroller mot fysisk manipulering. Likevel er en vanlig eksamensfelle å overfokusere på fysiske tiltak når scenarioet egentlig handler om systemdesign, dataklassifisering eller kryptografisk nøkkellivssyklus.

Sikkerhetsmodeller forklart gjennom arkitekturvalg

Bell-LaPadula, Biba, Clark-Wilson og Brewer-Nash blir ofte presentert som historiske modeller, men de påvirker fortsatt hvordan moderne datastrømmer utformes. Bell-LaPadula handler primært om konfidensialitet og passer godt som tankemodell der sensitiv informasjon ikke skal flyte til lavere klassifiserte nivåer. Biba handler om integritet og er relevant der uautoriserte eller lavt betrodde data ikke må påvirke kritiske beslutninger.

Clark-Wilson er særlig nyttig i forretningssystemer fordi modellen legger vekt på veldefinerte transaksjoner og separasjon av oppgaver. I praksis kan dette bety at en betalingsprosess krever validerte arbeidsflyter, logging og godkjenning, heller enn kun fil- eller databasebasert tilgangskontroll. Brewer-Nash, ofte omtalt som Chinese Wall-modellen, passer i situasjoner der interessekonflikter må styres dynamisk, for eksempel rådgivnings- eller konsulentmiljøer med konkurrerende kunder.

I en moderne dataarkitektur kan disse modellene dukke opp uten at noen bruker modellnavnene. Et analyseområde som mottar data fra produksjon, utvikling og tredjepartskilder må for eksempel håndtere både konfidensialitet og integritet. Arkitekten må da avgjøre hvilke datasett som kan blandes, hvilke som må maskeres, hvilke pipelines som krever attestasjon, og hvor integritetskontroller skal ligge.

Fra krav til arkitektur: et sky- og hybridscenario

Vurder en virksomhet som skal flytte kundeanalyse til en skytjeneste, men fortsatt beholde enkelte kildesystemer i eget datasenter. Kravene er at persondata skal beskyttes, rapporter skal være tilgjengelige for autoriserte analytikere, og dataintegriteten må kunne dokumenteres fordi beslutninger påvirker kundebehandling. Dette er et typisk Domain 3-problem: løsningen krever mer enn en brannmur og kryptering.

Trusselmodelleringen bør først avklare hvem som kan skade systemet og hvordan. Eksterne angripere kan forsøke å utnytte API-er, kompromitterte utviklerkontoer kan påvirke bygg- og utrullingspipelines, og interne brukere kan få for bred tilgang til datasett. I tillegg kommer sidekanalangrep, feilkonfigurert isolasjon mellom arbeidslaster og forsyningskjederisiko fra tredjepartsbiblioteker eller containerbilder.

I sky- og hybridarkitektur blir ansvarsdelingen særlig viktig. Skyleverandøren drifter deler av infrastrukturen, men organisasjonen eier fortsatt dataklassifisering, identiteter, tilgangsmodeller, nøkkelpolicyer og sikker konfigurasjon. Valget mellom skyleverandørens Key Management Service (KMS) og en dedikert Hardware Security Module (HSM) bør derfor styres av krav til kontroll, regulatoriske behov, operasjonell kompleksitet og hvor nøklene må være tilgjengelige.

Zero Trust-prinsipper påvirker også designet. Sterke maskinidentiteter, gjensidig TLS (mTLS), mikrosegmentering, kontinuerlig verifikasjon og attestasjon av bygg- og kjøremiljø kan redusere tilliten til nettverksplassering alene. Samtidig må arkitekturen kunne driftes; for hard segmentering uten god observabilitet kan skape feilsøking, ytelsesproblemer og uforutsigbare avhengigheter.

Kryptografi og nøkkelhåndtering i praksis

Kryptografi feiler ofte i grenseflatene mellom teori og drift. Et system kan bruke sterk kryptering for data i ro og under overføring, men likevel ha svake rutiner for nøkkelrotasjon, tilgang til nøkkelmateriale eller separasjon mellom utvikling, test og produksjon. Domain 3 legger derfor vekt på forståelsen av hele kryptosystemet, ikke bare algoritmen.

Nøkkellivssyklusen bør dekke generering, lagring, bruk, rotasjon, tilbakekalling, arkivering og destruksjon. I store miljøer blir dette krevende fordi applikasjoner, databaser, meldingskøer, backup-systemer og analyseplattformer kan ha ulike krav. Rotårsaken til mange alvorlige hendelser er ikke at kryptografien er matematisk svak, men at nøkler kopieres, deles, hardkodes, gjenbrukes eller blir liggende i logger og konfigurasjonsfiler.

Det er også viktig å skille mellom kryptering og signering. Kryptering skjuler innhold for uvedkommende, mens signering gir mottakeren grunnlag for å verifisere avsender og at innholdet ikke er endret. I eksamensscenarioer er dette et vanlig skille: dersom spørsmålet handler om konfidensialitet, er kryptering ofte relevant; dersom spørsmålet handler om autentisitet, integritet eller ikke-benekting, peker svaret ofte mot digitale signaturer, sertifikater eller meldingsautentisering.

Drift, endringsstyring og sikker systemlivssyklus

Sikker arkitektur må overleve drift. Endringsstyring, patching og konfigurasjonskontroll er derfor ikke administrative ettertanker, men tekniske sikkerhetsmekanismer. I store miljøer kan en oppdatering påvirke avhengigheter mellom eldre systemer, skyressurser, identitetsplattformer og nettverkskontroller.

Legacy-systemer skaper ofte vanskelige kompromisser. De kan være forretningskritiske, men støtte begrenset logging, svak autentisering eller gamle protokoller. En god arkitektur dokumenterer slike unntak, isolerer risikoen med segmentering og kompenserende kontroller, og legger en realistisk plan for utfasing eller modernisering.

SDLC-perspektivet er også sentralt. Sikker programvareutvikling handler om trusselmodellering, kodegjennomgang, avhengighetsskanning, hemmelighetshåndtering, sikker byggpipeline og kontrollert utrulling. Når byggmiljøet kompromitteres, kan angriperen påvirke programvaren før den når produksjon, noe som gjør pipeline-sikring til en del av sikkerhetsarkitekturen.

Eksamensscenario: hvordan resonnere frem riktig svar

Et typisk Domain 3-spørsmål kan beskrive en virksomhet som behandler svært sensitive dokumenter i et hybridmiljø. Dokumentene skal bare være tilgjengelige for autoriserte brukere med riktig klassifisering, og hovedrisikoen er at informasjon kopieres fra et høyt klassifisert område til et lavere klassifisert område. Spørsmålet ber om den beste sikkerhetsmodellen for designet.

1. Identifiser primærmålet: scenarioet handler først og fremst om konfidensialitet.
2. Finn trusselen: uønsket informasjonsflyt fra høyere til lavere klassifisering.
3. Koble til modell: Bell-LaPadula er relevant når konfidensialitet og informasjonsflyt står sentralt.
4. Avvis alternativer: Biba passer bedre for integritet, Clark-Wilson for transaksjonskontroll og Brewer-Nash for interessekonflikter.
5. Velg svaret som best matcher kravene, ikke svaret som virker mest teknisk avansert.

Resonnementet er viktigere enn memoreringen. Dersom samme scenario i stedet handlet om å beskytte en produksjonsdatabase mot data fra lavt betrodde kilder, ville Biba vært mer relevant. Dersom scenarioet handlet om økonomiske transaksjoner med krav til separasjon av oppgaver og validerte prosesser, ville Clark-Wilson ligget nærmere.

Vanlige feller i Domain 3-forberedelser

Den første fellen er å lære modellene som isolerte definisjoner. På eksamen må modellene kobles til forretningskrav, dataflyt og kontrollmål. En kandidat bør kunne forklare hvorfor en modell støtter et bestemt designvalg, og hvilke begrensninger modellen har i et moderne miljø.

Den andre fellen er å undervurdere drift. Et design som ser sikkert ut på papir, kan mislykkes dersom det ikke kan patches, overvåkes, roteres, testes eller feilsøkes. CISSP-perspektivet belønner ofte svaret som balanserer sikkerhet med driftsbarhet og risikoreduksjon.

Den tredje fellen er å blande kryptografiske begreper. Autentisering bekrefter identitet, autorisasjon bestemmer hva identiteten får gjøre, kryptering beskytter konfidensialitet, og signering støtter integritet og ikke-benekting. Små begrepsforskjeller kan endre riktig svar i et scenario.

Hvordan bygge en god studieplan for Domain 3

En effektiv studieplan bør kombinere offisielt materiale, praktiske arkitekturcase og scenarioøving. Den offisielle CISSP-litteraturen fra (ISC)² bør være grunnlaget for begreper og eksamensramme, mens standarder som NIST SP 800-160, NIST SP 800-53 og ISO/IEC 27001 Annex A kan hjelpe kandidaten å se hvordan prinsippene brukes i styring og kontrollutforming.

Strukturert undervisning kan være nyttig når kandidaten trenger hjelp til å koble teori til scenarioer. Et CISSP-kurs hos Readynez kan gi en mer styrt gjennomgang av domenene, men verdien ligger først og fremst i hvordan kandidaten bruker stoffet: ved å forklare designvalg, øve på avveiinger og trene på hvorfor feil svar er feil.

Der Domain 3 møter praktisk sikkerhetsarbeid

CISSP Domain 3 er nyttig fordi det tvinger frem sporbarhet fra risiko og krav til kontrollvalg. En sikkerhetsarkitekt må kunne forklare til ledelsen hvorfor en HSM kan være nødvendig i ett tilfelle, hvorfor KMS er tilstrekkelig i et annet, og hvordan valget påvirker kostnad, ytelse, tilgjengelighet og operasjonell risiko.

Den viktigste læringen er at sikker arkitektur ikke er en samling enkeltkontroller. Den er et sammenhengende design der modeller, kryptografi, fysisk sikring, systemlivssyklus, testing og drift støtter samme risikomål. Readynez kan være et naturlig neste steg for kandidater som ønsker instruktørledet forberedelse, men den daglige verdien av Domain 3 ligger i bedre beslutninger når sikre systemer skal bygges og vedlikeholdes.

FAQ

Hva er hovedtemaene i CISSP Domain 3?

Domain 3 dekker sikkerhetsarkitektur og sikkerhetsteknikk, inkludert sikre designprinsipper, sikkerhetsmodeller, kryptografi, fysisk sikkerhet, systemkomponenter, vurdering og testing, samt sikkerhet gjennom systemets livssyklus.

Hvordan bør sikkerhetsmodeller læres til CISSP-eksamen?

Modellene bør læres gjennom formål og scenarioer. Bell-LaPadula knyttes til konfidensialitet, Biba til integritet, Clark-Wilson til kontrollerte transaksjoner og separasjon av oppgaver, og Brewer-Nash til interessekonflikter.

Hva er forskjellen på kryptering og digital signering?

Kryptering beskytter innhold mot innsyn, mens digital signering hjelper mottakeren å verifisere hvem som signerte innholdet og om det er endret. Begge bruker kryptografi, men de løser ulike sikkerhetsmål.

Hvorfor er nøkkelhåndtering så viktig i Domain 3?

Nøkkelhåndtering avgjør om kryptografiske kontroller er pålitelige over tid. Generering, lagring, rotasjon, tilgangsstyring og destruksjon av nøkler må være kontrollert, ellers kan en teknisk sterk løsning bli praktisk svak.

Hvordan påvirker Zero Trust sikkerhetsarkitektur?

Zero Trust flytter designet bort fra blind tillit til nettverksplassering. Arkitekturen bør bruke sterke identiteter, segmentering, kontinuerlig verifikasjon og attestasjon, samtidig som løsningen fortsatt må være mulig å drifte og feilsøke.