Metamodell Säkerhet
- Arkitekturgemenskapen
Beskrivning | Arkitektur-perspektiv | Verksamhets-område | Publicerad / Version |
|---|---|---|---|
Begreppsmodell för skapande av säkerhetsarkitektur. | Säkerhet | Alla | 2022-12-08/62 2021-04-15/53 |
Innehållsförteckning
Versionshistorik
Inledning
Metamodell Säkerhet är den del av arkitekturramverket som definierar struktur och omfattning när det gäller aspekter av säkerhet i såväl målarkitekturer, referensarkitekturer som lösningsarkitekturer. Metamodell Säkerhet definierar också de begrepp som kan användas inom säkerhetsområdet och därigenom tillhandahålls ett gemensamt språk för berörda intressenter. Metamodellen beskriver även hur arkitekturelement förhåller sig till varandra inom och utom säkerhetsdomänen, och sammantaget hjälper detta arkitekter från olika organisationer att samverka och återanvända arkitekturer, vilket bidrar till en större effektivitet och ökad kvalitet i såväl lokala som gemensamma initiativ.
I dess nuvarande form fokuserar metamodellen främst på beskrivning av arkitekturer för informationssäkerhet, men den går även att använda för arbete med säkerhetsskydd och IT-säkerhet.
Modelldiagram
Elementdefinitioner
Element | Definition | Exempel | Vägledning | Källor |
|---|---|---|---|---|
Definitionen motsvarar termen: skyddsåtgärd | Åtgärd som förändrar en risk. | Organisatoriska åtgärder:
Tekniska åtgärder:
Fysiska åtgärder:
| Synonymt begrepp är Skyddsåtgärd. Säkerhetsåtgärder indelas i organisatoriska (administrativa) -, tekniska och fysiska säkerhetsåtgärder. Säkerhetsåtgärder bör vara både proaktiva och reaktiva i syfte att skydda, detektera, reagera vid hot mot informationstillgångar, se ex. NIST Cybersecurity Framework Organisatoriska (administrativa) säkerhetsåtgärder realiseras genom en eller flera Processer (inklusive rutiner) eller Verksamhetsfunktioner. Tekniska säkerhetsåtgärder (inklusive IT-Säkerhet) realiseras med Applikationsfunktioner eller Teknikfunktioner. Fysiska säkerhetsåtgärder realiseras genom Utrustning. Se även Vägledning för Fysisk informationssäkerhet från MSB.(Kommentar: Utrustning bör kunna kopplas till Plats för att beskriva var Utrustningen står. Se förslag i Metamodell Teknik.) Grupper av säkerhetsåtgärder är ofta kopplade till en viss informationsklass. Beroende på informationsklass blir ett förutbestämt antal säkerhetsåtgärder applicerbara. Dessa kopplingar är baserade på tidigare bedömningar av vilka risker som en organisationen har. Detsamma gäller befintliga Krav och Begränsningar som är aktuella inom organisationen. De är uppkomna för att ange säkerhetsåtgärder i syfte att hantera redan identifierade risker. | ISO27000:2018: En åtgärd som förändrar en risk. SIS-TR 50:2015: Säkerhetsåtgärd: Identifierad uppsättning åtgärder för att möta en organisations risker. UAF: Security Control: The management, operational, and technical control (i.e., safeguard or countermeasure) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information [NIST SP 800-53]. UAF: Operational Mitigation: A set of security measures intended to address against specific cyber risks. Comprises a subset of SecurityControls that are required to protect the asset at Operational Performer (Operational Role). UAF: Resource Mitigation: A set of security measures intended to address specific cyber risks. Comprises a subset of TailoredSecurityControls that are used to protect the asset at resource (Resource Role).
|
Definitionen motsvarar termen: Informationssäkerhetsklass | Kategorisering som representerar informationens känslighet. |
| Lämplig nivåindelning och aspekter vid klassificering finns i SKRs verktyg och metodstöd för informationssäkert KLASSA. Där anges konsekvensnivåerna: i aspekterna: Klassning har en implicit koppling till juridik/ lagar. Lagar uttrycks med elementtypen Begränsning och därmed kan man också göra denna koppling mer explicit om behov finns genom att relatera Begränsningar till Informationsklasser. Lagar är oftast inte skrivna så att de direkt kan kopplas till informationsklasser, men för Säkerhetsskyddslagen 2018:585 (= Nivå 4) så finns följande Säkerhetsskyddsklasser definierade:
| SIS-TR 50:2015: Säkerhetsklass: Kombination av hierarkisk klassning och en (eventuellt tom) uppsättning kategorier som representerar informationens känslighet. MSB Metodstöd för systematiskt informationssäkerhetsarbete: Informationsklassning: Klassningsmodellen används för att värdera informationstillgångar ISO27002: Informationsklassning: Att säkerställa att information får en lämplig skyddsnivå i enlighet med dess betydelse för organisationen Information ska klassas i termer av rättsliga krav, värde, verksamhetsbetydelse och känslighet för obehörigt röjande eller modifiering.
|
Osäkerhetens effekt på mål. |
| SIS-TR 50:2015 har följande vägledning angående risker: Anm. 1: En effekt är en avvikelse från det förväntade – positiv och/eller negativ. Anm. 2: Osäkerhet är det tillstånd, också partiellt, av bristande information som har att göra med förståelse för eller kunskap om en händelse, dess konsekvenser eller sannolikhet. Anm. 3: Risk karaktäriseras ofta utifrån potentiella händelser och konsekvenser eller en kombination av dessa. Anm. 4: Risk uttrycks ofta som en kombination av en händelses konsekvenser (inklusive ändrade omständigheter) och tillhörande sannolikhet för förekomst. Risk är därmed ett värderat hot där sannolikhet och konsekvens vägs in. Anm. 5: I ledningssystem för informationssäkerhet uttrycks informationssäkerhetsrisker som osäkerhetens effekt på informationssäkerhetsmål. Anm. 6: Informationssäkerhetsrisk innebär möjligheten att ett givet hot utnyttjar sårbarheten hos en informationstillgång eller en grupp av informationstillgångar och därigenom orsakar organisationen skada. Risker bör relateras till de mål som de potentiellt kan ha effekt på, exempelvis att mål riskerar att inte uppnås. | Osäkerhetens effekt på mål (SIS-TR 50:2015). Effect of uncertainty on objectives (ISO 31000:2018). ISO 31000 recognizes that all of us operate in an uncertain world. Whenever we try to achieve an objective, there’s always the chance that things will not go according to plan. Every step has an element of risk that needs to be managed and every outcome is uncertain. Whenever we try to achieve an objective, we don't always get the results we expect. Sometimes we get positive results and sometimes we get negative results and occasionally we get both. The traditional definition of risk combines three elements: it starts with a potential event and then combines its probability with its potential severity. While ISO 31000 defines risk in a new and unusual way, the old and the new definitions are largely compatible. Both definitions talk about the same phenomena but from two different perspectives. ISO thinks of risk in goal-oriented terms while the traditional definition thinks of risk in event-oriented terms. These two definitions can and do co-exist. They’re two different ways of talking about the same phenomena. ISO provides a conceptual definition of risk while the traditional formulation operationalizes this general definition: it explains how to quantify risk. It argues that the amount or level of risk can be calculated by combining probability and severity. UAF: Risk: A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. I Archimate 3.0.1 specifikationen finns inte Risk som eget element, men nämns som möjlig specialisering av elementet Assessment i kapitel 15.2.5. Beskrivningen som ges där är “The probable frequency and probable magnitude of future loss.” Archimate: Assessment: An assessment represents the result of an analysis of the state of affairs of the enterprise with respect to some driver. Inte heller i TOGAF finns Risk som definierat element vilket är lite märkligt då Risk Management har ett eget kapitel. TOGAF hänvisar dock till ISO 31000 definitionen av risk. | |
Möjlig orsak till en oönskad händelse med negativa konsekvenser för verksamheten. |
| Kan indelas i avsiktliga och oavsiktliga hot. Med avsiktliga hot menas hot med illasinnad avsikt. Med oavsiktliga hot menas hot som existerar trots att illasinnad avsikt saknas. Kan även indelas i interna och externa hot. Med interna hot menas hot mot säkerheten som orsakas internt. Med externa hot menas hot som har sitt ursprung utanför organisationen. Hot kan kopplas till händelse för att beskriva potentiella informationssäkerhetshändelser och informationssäkerhetsincidenter. Informationssäkerhetshändelser är identifierade förekomster i ett system, tjänst eller nätverk som indikerar en möjlig avvikelse från policy för informationssäkerhet , eller ej fungerande säkerhetsåtgärder, eller en situation som tidigare varit okänd och som kan vara relevant för informationssäkerheten. informationssäkerhetsincidenter är enskilda eller flera oönskade eller oväntade informationssäkerhetshändelser som har negativa konsekvenser för verksamheten och dess informationssäkerhet. | IS27000:2018: Hot: Möjlig orsak till en oönskad händelse med negativa konsekvenser för verksamheten. Archimate: Threat Event (specialisering av Business Event): Event with the potential to adversely impact an asset. An attack is a specific type of threat event that is the result of an intentional malicious activity of an attacker, which is a specific type of threat agent.
| |
Brist i skyddet av en tillgång eller av en säkerhetsåtgärd som kan utnyttjas av ett eller flera hot. |
| All information som finns inom, och behandlas av, en organisation är föremål för hot i form av attacker, fel, naturrelaterade hot (t.ex. översvämning eller brand), etc., och utsätts för sårbarheter förknippade med dess användning. Sårbarheter är brister som möjliggör att hot kan realiseras. Sårbarheter gör att sannolikhet och/eller konsekvens för risker ökar. Sårbarheter är något som gör ett it‑system känsligt för angrepp. – Sårbarheter kan vara tekniska brister eller förbiseenden, mänskliga svagheter eller en kombination. Oftast menar man brister i datornätverkens system för identifiering, inloggning och rättigheter. Kontrollen av in- och utgående datatrafik kan ha sårbarheter, liksom processen för granskning av den utrustning som ansluts till nätverket, och de program som körs. – I en bredare bemärkelse kan sårbarheter också vara mänskliga svagheter som slarv, tanklöshet och naivitet i kombination med teknik som inte har utformats för att kompensera för sådana svagheter. Aktuella sårbarheter kan följas på ex. CVS : Security vulnerabilities (cvedetails.com) | ||
Information, och resurser som hanterar den, som är av värde för en organisation.
| Exempel: • information (kunddatabas, metodik, dokument etc.) • program (applikation, operativsystem etc.) • tjänster (kommunikationstjänst, abonnemang etc.) • fysiska tillgångar (dator, datamedier, lokala nätverk etc.) • människor och deras kompetens, färdigheter och erfarenheter • immateriella tillgångar (rykte och image etc.) | Informationstillgångar kan vara av fysisk eller logisk karaktär, eller bådadera. Detta omfattar både själva informationen och resurser som hanterar denna, både tekniska system och människor. Information som är personligt knuten till en identifierbar individ kallas Personuppgifter (Personal data, also known as personal information or personally identifiable information (PII) is any information relating to an identifiable person) och har en särställning som informationstillgång då behandlingen av denna typ av information är reglerad i särskild lagstiftning (EUs Dataskyddsförordning samt nationella lagstiftningen Lag (2018:218) med kompletterande bestämmelser till EU:s dataskyddsförordning). | ||
Informationsbehandlingsresurs | System, tjänst eller infrastruktur för hantering av information. |
| Abstrakt element som grupperar alla de resurser som behandlar information. Informationsbehandlingsresurs är en specialisering av Informationstillgång. Används för att öka läsbarhet och förståelse i metamodellen. Används inte i tillämpningar av metamodellen. Använd istället konkreta specialiseringar av detta element i en tillämpning. Konkreta element är, exempelvis applikationer, applikationstjänster och noder. |
|
Relationer inom lagret
Källelement | Relation | Målelement | Källa |
|---|---|---|---|
Hot | ökar | Risk | Inspirerat av ISO 27000:2018 |
Risk | påverkas av | Hot | Inspirerat av ISO 27000:2018 |
Hot | utnyttjar | Sårbarhet | ISO 27000:2018 |
Sårbarhet | utnyttjas av | Hot | ISO 27000:2018 |
Risk | påverkas av | Sårbarhet | Inspirerat av ISO 27000:2018 |
Sårbarhet | ökar | Risk | Inspirerat av ISO 27000:2018 |
Risk | påverkar | Informationstillgång | ISO 27000:2018 UAF:Affects: A dependency that asserts that a Risk is applicable to an Asset. |
Informationstillgång | utsätts för | Risk | ISO 27000:2018 UAF:Affects: A dependency that asserts that a Risk is applicable to an Asset. |
Risk | förändras av | Säkerhetsåtgärd | ISO 27000:2018 UAF Mitigates: A dependency relating a Security Control to a Risk. Mitigation is established to manage risk and could be represented as an overall strategy or through techniques (mitigation configurations) and procedures (SecurityProcesses). |
Säkerhetsåtgärd | förändrar | Risk | ISO 27000:2018 UAF: Mitigates: A dependency relating a Security Control to a Risk. Mitigation is established to manage risk and could be represented as an overall strategy or through techniques (mitigation configurations) and procedures (SecurityProcesses). |
Sårbarhet | förändras av | Säkerhetsåtgärd | ISO 27000:2018 |
Säkerhetsåtgärd | förändrar | Sårbarhet | ISO 27000:2018 |
Säkerhetsåtgärd | skyddar | Informationstillgång | UAF:Protects: A dependency that asserts that a SecurityControl is required to protect an Asset. |
Informationstillgång | skyddas av | Säkerhetsåtgärd | UAF:Protects: A dependency that asserts that a SecurityControl is required to protect an Asset. |
Sårbarhet | hör till | Informationstillgång | ISO 27000:2018 |
Informationstillgång | har | Sårbarhet | ISO 27000:2018 |
Säkerhetsåtgärd | styrs av | Informationsklass | Inspirerat av ISO 27001:2017 |
Informationsklass | styr | Säkerhetsåtgärd | Inspirerat av ISO 27001:2017 |
Säkerhetsåtgärd | möter | Hot | Inspirerat av ISO 27000:2018 |
Hot | adresseras av | Säkerhetsåtgärd | Inspirerat av ISO 27000:2018 |
Informationsbehandlingsresurs | är en | Informationstillgång | SIS-TR 50:2015 |
Relationer till andra lager
Fråga till AG: Behövs relation mellan Process och Sårbarhet för att kunna uttrycka att en process skapar sårbarheter eller räcker det med att kunna koppla sårbarheter till processens produkt (Verksamhetsobjekt) och Verksamhetstjänst?
Källelement | Relation | Målelement | Källa |
|---|---|---|---|
Risk | ägs av | Aktör | ISO 27000:2018. UAF: OwnsRisk: An abstraction relating a Risk to an organizational resource that is responsible for executing the risk mitigation. Aktören agerar i rollen Riskägare. |
Aktör | äger | Risk | ISO 27000:2018. UAF: OwnsRisk: An abstraction relating a Risk to an organizational resource that is responsible for executing the risk mitigation. Aktören agerar i rollen Riskägare. |
Risk | relevant för | Mål | ISO27002:2017 |
Mål | har | Risk | ISO27002:2017 |
Hot | kan orsaka | Händelse | ISO 27000:2018 |
Händelse | kan orsakas av | Hot | ISO 27000:2018 |
Krav | kravställer | Säkerhetsåtgärd | SIS-TR 50:2015 |
Säkerhetsåtgärd | uppfyller | Krav | UAF: Satisfy |
Säkerhetsåtgärd | möjliggör | Förmåga | Arbetsgruppen |
Förmåga | möjliggörs av | Säkerhetsåtgärd | Arbetsgruppen |
Process Verksamhetsfunktion Teknikfunktion Applikationsfunktion Utrustning | är en / kan vara | Säkerhetsåtgärd | ISO 27000:2018 |
Informationsklass | klassificerar | Verksamhetsobjekt Informationsobjekt Dataentitet | Inspirerat av ISO27002:2017 |
Verksamhetsobjekt Informationsobjekt Dataentitet | tillhör | Informationsklass | Inspirerat av ISO27002:2017 |
Aktör Verksamhetstjänst Informationsobjekt Verksamhetsobjekt | är en | Informationstillgång | Inspirerat av SIS-TR 50:2015, ISO 27000:2018 och UAF |
Nod Applikationstjänst Applikation | är en | Informationsbehandlingsresurs | Inspirerat av SIS-TR 50:2015, ISO 27000:2018 och UAF |
Utvecklingsförslag
Här listas förslag på vidareutveckling:
Utökad modell för beskrivning av Sannolikhet och Konsekvens.
Konsekvenser behöver listats på en mer generell nivå:
Personlig säkerhet, Egendom, Kommersiella intressen/externa intressen, personlig integritet, Miljö, Förtroende och varumärke, Lag och efterlevnad (personal), Lag och efterlevnad (verksamhet), Samhällets/Stadens funktionalitet
Gruppera Konsekvens utifrån risk som påverkar:
Internt:
Ekonomi - ekonomisk förlust i verksamhet (MSB) : Kvalitativ
Tid (avbrott i aktivteter) (MSB)
Intern produktivitet (MSB): kvantitativ
Personlig Säkerhet (GBG Stad) (Dödsfall till arbetsskada):Kvalitativ
Egendom (skada på egendom eller näringsverksamhet):KvalitativLeverans:
Kommersiella intressen/externa intressenter (ISO27005): Kvalitativ
Personlig Integritet (Dataskyddsförordningen och ISO 27701): Kvalitativ
Miljö (Luft, mark, vatten) (GBG Stad):KvalitativExternt:
Förtroende och varumärke (MSB): kvantitativ
Lag och efterlevnad (personal): Kvantitativ (MSB)
Log och efterlevnad (Verksamhet) (MSB): Kvantitativ
Samhällets/verksamhetens/stadens funkitonalitet (GBG Stad): kvalitativ
Gruppera Sannolikhet utifrån risk som påverkar
Svårigheter, Frekvens och annat (se tabell nedan som exempel)
Svårighet |
| Frekvens i verksamheten |
|
| |||||
| Intraservice | ISO 29134 | Intraservice | Intraservice | Intraservice/MSB | ISO31000 | Göteborgs Stad | Göteborgs Stad | Intraservice |
| Kvalitativt | Kvalitativt | Kvalitativt | Kvalitativt | kvantitativ | kvantitativ | kvantitativ | Kvalitativt | Kvalitativt |
Maximal / Allvarlig | Lätt att det händer | Att utföra ett hot verkar vara extremt enkelt för de valda riskkällorna (t.ex. stöld av pappersdokument lagrade i en lobby). | Händer alltid | Ofta återkommande händelse. | 50% | mer än 2 gånger om året | Inträffar 52 gånger/år | Mycket hög | Mycket sannolikt |
Betydande | Möjligt att det händer | Att utföra ett hot verkar vara möjligt för de valda riskkällorna (t.ex. stöld av pappersdokument lagrade på kontor som inte kan nås utan att först kontrollera i receptionen). | Händer ofta att | Hänt inom staden eller närliggande verksamhet flertalet gånger. | 20% | 1-2 gånger om året | Inträffar 6 gånger/år | Hög | Sannolikt |
Måttlig | Svårt att det händer | Att utföra ett hot verkar vara svårt för de valda riskkällorna (t.ex. stöld av pappersdokument lagrade i ett rum som är skyddat av en badge-läsare). | Händer ibland | Har hänt inom staden eller närliggande verksamhet men ej frekvent. | 5% | 1 gång om året | Inträffar 1 gång/år | Låg | Möjligt |
Flera historiskt kända fall eller nytt hot, men ej inom staden eller närliggande verksamhet. | Osannolikt | ||||||||
Försumbar | Omöjligt det händer | Att utföra ett hot verkar inte möjligt för de valda riskkällorna (t.ex. stöld av pappersdokument lagrade i ett rum som är skyddat av en badge-läsare och åtkomstkod). | Händer aldrig att | Fåtal kända fall att detta har skett historiskt eller hotet är nytt och avlägset. | 1% | 1 gång vart tionde år | Inträffar var 30:e år | Mycket låg | Mycket osannolikt |
Introducera Hotaktör i metamodellen
Exempel på hotaktörer
Hostile Nations (Cyber War)
Organized Crime and Criminals (Cyber Crime
Terrorism and Terrorist Groups (Cyber War)
The Empowered Small Agent (ESA) (Hacktevism)
Amateurs (Cyber Crime / Vandalism)
Hackers (Cyber Crime / Vandalism)
Crackers (Cyber Crime / Vandalism)
Employees (Cyber Crime, Espionage / Hacktivism)
The Corporation (Cyber Espionage)
HOTAKTÖR har förmåga
HOTAKTÖR har uppsåt/vilja
HOTAKTÖR använda metod för utnyttja sårbarhet för att utöva/orsaka/skapa hot/påtryckning/(möjlighet utifrån hotaktörens sätt att se det).
HOTAKTÖR använder sårbarheter