Vad ingår i CISSP Domain 3 och hur tillämpas det?

CISSP Domain 3 omfattar säkerhetsarkitektur och teknik, men området upplevs ofta som en samling lösa tekniska ämnen: kryptografi, hårdvara, fysisk säkerhet, modeller, testning och arkitekturprinciper.

CISSP Domain 3, Security Architecture and Engineering, handlar om hur säkra system designas, byggs, utvärderas och underhålls med hjälp av etablerade säkerhetsprinciper. Domänen är bred, men dess kärna är tydlig: den prövar förmågan att koppla säkerhetsmål till arkitekturbeslut snarare än att memorera enskilda produkter eller kommandon.

Vad Domain 3 omfattar

Den aktuella (ISC)² Exam Outline är alltid den styrande källan för CISSP-examen, men på hög nivå rör Domain 3 flera återkommande teman. Den omfattar säkerhetsmodeller, designprinciper, kryptografi, säkra hårdvaru- och systemkomponenter, fysisk säkerhet, sårbarhetsbedömning, säkerhetstestning och säkerhet i systemlivscykeln.

Det är samtidigt viktigt att se gränserna. Riskstyrning, policyarbete och juridik hör främst hemma i andra CISSP-domäner, även om de påverkar arkitekturvalen. Drift, övervakning och incidenthantering behandlas också mer utförligt på andra håll. Domain 3 fokuserar på vad som bör byggas in i systemet från början och hur säkerhetsfunktioner kan bedömas innan de används i en verksamhetskritisk miljö.

En praktisk läsning av domänen är därför att se den som bron mellan affärskrav och teknisk design. Om verksamheten behöver skydda kunddata, säkerställa korrekta transaktioner och hålla tjänster tillgängliga under störningar, ska arkitekturen visa hur konfidentialitet, integritet och tillgänglighet hanteras genom kontroller, lager och validering.

Säkerhetsarkitektur och säkerhetsteknik i praktiken

Säkerhetsarkitektur beskriver den övergripande strukturen: vilka tillgångar som skyddas, vilka hot som är relevanta, vilka principer som styr designen och hur kontroller samverkar. Den tar ställning till zonindelning, identitet, dataskydd, systemberoenden, loggning, återställning och styrning.

Säkerhetsteknik är det praktiska arbetet med att omsätta arkitekturen i system. Det kan innebära att konfigurera åtkomstkontroll, välja krypteringslösningar, införa säker uppstart, testa sårbarheter, härda operativsystem och verifiera att en molnplattform följer den tänkta referensarkitekturen.

Skillnaden märks tydligt i ett hybridscenario. En organisation som driver ett äldre affärssystem lokalt men lägger nya kundtjänster i molnet behöver först besluta vilken data som får flyttas, vilka identiteter som ska vara auktoritativa och hur nätverksflöden ska begränsas. Därefter behöver lösningen byggas med rätt nyckelhantering, segmentering, logginsamling, sårbarhetsskanning och återställningsrutiner. Arkitekturen anger riktningen; tekniken visar om den faktiskt håller.

CIA-triaden är en startpunkt, inte en färdig arkitektur

Konfidentialitet, integritet och tillgänglighet, ofta kallat CIA-triaden, är ett grundläggande sätt att strukturera säkerhetsmål. Konfidentialitet handlar om att endast behöriga får ta del av information. Integritet handlar om att information och systemtillstånd är korrekta och inte ändras otillåtet. Tillgänglighet handlar om att tjänster och data finns när de behövs.

Misstaget är att behandla triaden som tre lika stora mål i varje system. I ett klassificerat dokumentarkiv kan konfidentialitet vara det dominerande målet. I ett betalnings- eller ordersystem kan integritet väga tyngre, eftersom en otillåten ändring av transaktioner kan vara mer skadlig än begränsad informationsinsyn. I en vårdnära eller industriell miljö kan tillgänglighet vara avgörande för säker drift.

Denna prioritering påverkar valet av säkerhetsmodell. Bell-LaPadula används ofta som tankemodell när konfidentialitet är viktigast, exempelvis där informationsnivåer och läsbehörigheter styr designen. Biba och Clark-Wilson passar bättre som resonemangsramar när dataintegritet och kontrollerade transaktioner står i centrum, till exempel i finansiella flöden eller affärssystem där felaktiga ändringar måste förebyggas och kunna spåras.

Säkra designprinciper som återkommer i Domain 3

Domain 3 förutsätter att grundprinciper kan användas i konkreta designbeslut. Minsta privilegium innebär att användare, tjänster och systemkomponenter bara får den åtkomst de behöver. Försvar på djupet innebär att flera kontroller samverkar, så att en bruten kontroll inte leder till full kompromettering. Felsäkra standardinställningar innebär att system hellre nekar åtkomst än tillåter den när något är oklart.

Andra viktiga principer är separation av uppgifter, enkelhet i design, fullständig medling av åtkomstbeslut och spårbarhet. De låter teoretiska, men de styr vardagliga beslut. En administratör ska exempelvis inte använda samma konto för e-post och domänadministration. Ett API bör validera auktorisation på serversidan i varje känsligt anrop. En brandväggsregel bör dokumenteras med syfte, ägare och livslängd i stället för att bli en permanent genväg.

I verkliga miljöer finns alltid begränsningar. Äldre system kanske saknar modern autentisering, regulatoriska krav kan kräva särskild logghantering och prestandakrav kan påverka krypteringsval. En mogen arkitektur försöker inte dölja sådana avsteg. Den dokumenterar dem, förklarar risken, anger kompensatoriska kontroller och sätter en tidpunkt för omprövning.

Kryptografi: mindre matematik, mer nyckelhantering

Kryptografi är ett centralt ämne i Domain 3, men prov- och yrkesmässigt ligger tyngdpunkten ofta på användning, styrning och begränsningar. En säkerhetsarkitekt behöver förstå skillnaden mellan symmetrisk kryptering, asymmetrisk kryptering, hashfunktioner, digitala signaturer och offentlig nyckelinfrastruktur, ofta kallad PKI.

Det vanliga felet är att lägga oproportionerligt mycket tid på kryptomatematik och för lite på nyckelhantering. I praktiken faller många kryptografiska lösningar på svaga processer: nycklar lagras fel, rotation saknas, certifikat löper ut, privilegier till nyckelvalv är för breda eller utvecklingsmiljöer delar hemligheter med produktion.

Domain 3-perspektivet är därför arkitektoniskt. Frågan är inte bara om data är krypterad, utan vem som kontrollerar nycklarna, var de skyddas, hur åtkomst loggas, hur återställning fungerar och vad som händer vid incident. I molnmiljöer blir detta en del av modellen för delat ansvar: leverantören säkrar vissa lager, men kunden ansvarar fortfarande för konfiguration, identitet, dataklassning och nyckelstyrning.

Hårdvarurot av tillit och utvärderingskriterier

Modern säkerhetsarkitektur slutar inte vid operativsystemet. Hårdvarubaserade säkerhetsfunktioner kan skapa en rot av tillit, alltså en grundpunkt som andra säkerhetsbeslut bygger på. Trusted Platform Module, förkortat TPM, kan stödja mätning av uppstart, skydd av nyckelmaterial och verifiering av enhetens tillstånd. Trusted Execution Environment, TEE, kan ge isolerad exekvering för särskilt känslig kod och data.

Säker uppstart är ett närliggande begrepp. Det innebär att systemet kontrollerar startkedjan så att otillåten kod inte laddas tidigt i processen. För en arkitekt är värdet inte att känna varje teknisk detalj, utan att förstå när sådana mekanismer stärker en design: klienter med höga skyddskrav, servrar som hanterar nycklar, industriella system eller miljöer där manipulation av firmware är ett realistiskt hot.

Utvärderingsramar ger ytterligare struktur. Common Criteria används för att beskriva och bedöma säkerhetsegenskaper i produkter på ett formaliserat sätt. FIPS 140 rör kryptografiska moduler och deras säkerhetskrav. Sådana referenser ersätter inte en egen riskbedömning, men de hjälper inköpare och arkitekter att ställa mer precisa krav än att en produkt bara ska vara ”säker”.

Moln, virtualisering och zero trust i arkitekturen

Moln och virtualisering förändrar hur Domain 3-principer tillämpas. Nätverksgränsen är mindre tydlig när användare, applikationer och data finns utspridda över SaaS-tjänster, plattformstjänster, containermiljöer och lokala system. Därför blir identitet, policy och telemetri viktigare än traditionell perimeterdesign.

Zero trust är relevant här som arkitekturprincip: åtkomst bör verifieras uttryckligen, begränsas till minsta nödvändiga nivå och övervakas kontinuerligt. I praktiken påverkar det flera designval. Nätverkssegmentering baseras inte enbart på IP-adresser utan även på arbetsbelastning, identitet och datakänslighet. Identitets- och åtkomsthantering behöver stödja stark autentisering, villkorad åtkomst och separerade administratörsroller. Telemetri från identitetssystem, slutpunkter, nätverk och molnkontroller måste kunna korreleras så att avvikande beteenden upptäcks.

Det delade ansvaret i molnet kräver också tydlighet. En molnleverantör kan tillhandahålla fysisk säkerhet, robust infrastruktur och säkerhetsfunktioner, men kunden måste konfigurera åtkomst, segmentera miljöer, skydda data, hantera nycklar och följa upp sårbarheter. Domain 3-frågor testar ofta just denna typ av ansvarsfördelning: vilken kontroll är mest lämplig givet arkitekturen och begränsningarna?

Fysisk säkerhet och logiska tester ska inte blandas ihop

Fysisk säkerhet ingår i Domain 3 eftersom informationssystem alltid finns i en fysisk verklighet. Datacenter, kontor, nätverksutrustning, backupmedia och klientenheter behöver skydd mot obehörig åtkomst, stöld, sabotage, brand, vatten och strömavbrott. Exempel på fysiska kontroller är passersystem, lås, mantrap, kameraövervakning, belysning, larm, brandskydd och miljöövervakning.

En vanlig sammanblandning är att placera fysiska detektorer i samma kategori som logiska säkerhetstester. Glaskrossensorer, rörelsedetektorer och passerkortsläsare hör till fysisk säkerhet. Sårbarhetsskanning, penetrationstestning, kodgranskning och konfigurationsgranskning hör till teknisk bedömning och testning av informationssystem. Båda områdena är viktiga, men de svarar på olika frågor.

Den skillnaden hjälper även i provfrågor. Om scenariot handlar om obehörig åtkomst till ett serverrum är en fysisk kontroll sannolikt relevant. Om scenariot handlar om osäkra tjänster, svaga konfigurationer eller exploaterbara applikationsfel är logiska testmetoder mer träffsäkra.

Bedömning, testning och livscykel

Säker arkitektur måste valideras. Sårbarhetsbedömning identifierar svagheter i system, konfigurationer och komponenter. Penetrationstestning undersöker om svagheter kan kombineras till en verklig angreppsväg under kontrollerade former. Kodgranskning och säkerhetstestning i utvecklingsprocessen minskar risken att brister når produktion.

Domain 3 betonar också att kontroller behöver underhållas över tid. Patchning, ändringshantering, omtestning, konfigurationsstyrning och avveckling av gamla komponenter är arkitekturfrågor eftersom de påverkar systemets faktiska säkerhetstillstånd. En design som är säker på ritbordet kan snabbt tappa värde om undantag, temporära regler och föråldrade komponenter aldrig följs upp.

Hotmodellering och riskanalys bör inte heller blandas ihop. Hotmodellering identifierar hur ett system kan angripas, vilka tillgångar som är exponerade och var kontroller behövs. Riskanalys bedömer sannolikhet, påverkan och prioritering i ett bredare verksamhetsperspektiv. De förstärker varandra, men de är inte samma aktivitet.

Ett sammanhängande exempel: hybrid arkitektur för kunddata

Anta att en organisation har ett lokalt affärssystem som innehåller kund- och orderdata, samtidigt som en ny kundportal ska köras i molnet. Målet är att ge kunder snabb åtkomst till sina ärenden utan att exponera hela affärssystemet. Domain 3-principerna leder då till flera konkreta val.

Först klassas data efter känslighet och affärsvärde. Kunduppgifter skyddas med tydliga åtkomstregler och kryptering, medan transaktionsintegritet får särskild uppmärksamhet genom attest, loggning och kontrollerade integrationsflöden. Bell-LaPadula kan hjälpa teamet att resonera om läsbegränsningar för känslig information, medan Clark-Wilson-liknande tänkande passar bättre för att säkra att orderändringar sker genom godkända transaktioner.

Därefter utformas identiteten som en central kontrollpunkt. Administrativa konton separeras, multifaktorautentisering krävs för känsliga roller och tjänstkonton ges begränsade rättigheter. Nätverket segmenteras så att portalen inte kan nå databaser direkt, utan använder ett kontrollerat integrationslager. Telemetri samlas från identitet, applikation, nätverk och molnkontroller för att upptäcka avvikelser.

Slutligen dokumenteras motiverade avsteg. Om det äldre affärssystemet inte stödjer modern autentisering kan kompensatoriska kontroller vara nätverksisolering, förstärkt övervakning, begränsade administrationsvägar och en plan för modernisering. Exemplet är förenklat; i reglerade miljöer behöver lösningen anpassas till krav på datalagring, revision, incidentrapportering och tredjepartsrisk.

Hur man studerar Domain 3 utan att fastna i detaljer

Ett effektivt studiesätt är att läsa Domain 3 scenariobaserat. När en fråga beskriver ett system bör läsaren först identifiera säkerhetsmålet: konfidentialitet, integritet, tillgänglighet, spårbarhet eller motståndskraft. Därefter blir det lättare att välja den kontroll som bäst löser problemet inom givna begränsningar.

Det hjälper också att aktivt leta efter vad frågan inte frågar efter. Om scenariot handlar om nyckelhantering är svaret sällan djup kryptomatematik. Om scenariot handlar om serverrummets skydd är det inte en penetrationstestmetod som ligger närmast. Om scenariot handlar om arkitekturbeslut i molnet behöver ansvarsfördelning, identitet och konfiguration vägas in.

Officiellt studiematerial bör vara basen. Den officiella CISSP-kursboken ger en strukturerad genomgång av ämnena, och den bör läsas tillsammans med aktuell Exam Outline från (ISC)². Den som vill komplettera egenstudier med lärarledd genomgång kan använda en instruktörsledd CISSP-utbildning, till exempel när säkerhetsmodeller, kryptografi och arkitekturfrågor behöver diskuteras utifrån praktiska scenarier.

Vad Domain 3 betyder för arkitekturarbetet

CISSP Domain 3 är mest värdefull när den används som ett sätt att tänka kring designbeslut. Den hjälper säkerhetsarkitekter, ingenjörer och tekniska ledare att koppla affärsmål till kontrollval, från identitet och kryptering till hårdvarutillit, fysisk säkerhet och testning.

Den viktigaste slutsatsen är att säkra system inte uppstår genom enskilda kontroller. De kräver konsekventa principer, tydliga avvägningar, validering och underhåll. Readynez kan vara ett stöd för den som vill strukturera sin CISSP-förberedelse, men den praktiska nyttan kommer av att kunna använda Domain 3 som ett språk för bättre arkitektur i verkliga miljöer.

FAQ

Vilka ämnen ingår i CISSP Domain 3?

Domain 3 omfattar bland annat säkerhetsmodeller, säkra designprinciper, kryptografi, hårdvaru- och systemskydd, fysisk säkerhet, sårbarhetsbedömning, säkerhetstestning och säkerhet i systemlivscykeln. Den aktuella (ISC)² Exam Outline bör alltid användas som styrande källa för exakt omfattning.

Vad är skillnaden mellan säkerhetsarkitektur och säkerhetsteknik?

Säkerhetsarkitektur beskriver strukturen, principerna och kontrollmålen för ett säkert system. Säkerhetsteknik omsätter detta i konfiguration, implementation, testning och driftbara tekniska lösningar.

Hur ska Bell-LaPadula, Biba och Clark-Wilson förstås?

Bell-LaPadula används främst för att resonera om konfidentialitet och informationsflöden. Biba och Clark-Wilson är mer användbara när integritet, korrekta transaktioner och kontrollerade ändringar är viktigast.

Hur djupt behöver man kunna kryptografi för CISSP Domain 3?

Man behöver förstå kryptografiska begrepp, användningsområden och begränsningar, men Domain 3 handlar inte om att lösa avancerad matematik. Nyckelhantering, certifikat, protokollval och korrekt tillämpning är ofta mer relevanta.

Var passar fysisk säkerhet in i Domain 3?

Fysisk säkerhet skyddar systemens fysiska förutsättningar: lokaler, utrustning, media, ström, kylning och åtkomstpunkter. Den ska skiljas från logiska testmetoder som sårbarhetsskanning, penetrationstestning och kodgranskning.