Säkerhet på flera nivåer

Flernivåsäkerhet eller flera säkerhetsnivåer ( MLS ) är tillämpningen av ett datorsystem för att behandla information med inkompatibla klassificeringar (dvs på olika säkerhetsnivåer), tillåta åtkomst för användare med olika säkerhetstillstånd och behov att veta, och förhindra användare från att få tillgång till information som de saknar behörighet för. Det finns två sammanhang för användning av flernivåsäkerhet. Det ena är att hänvisa till ett system som är tillräckligt för att skydda sig mot subversion och som har robusta mekanismer för att separera informationsdomäner, det vill säga trovärdigt. Ett annat sammanhang är att hänvisa till en applikation av en dator som kommer att kräva att datorn är tillräckligt stark för att skydda sig själv från omstörtning och ha adekvata mekanismer för att separera informationsdomäner, det vill säga ett system vi måste lita på. Denna distinktion är viktig eftersom system som måste vara pålitliga inte nödvändigtvis är pålitliga.

Pålitliga operativsystem

En MLS- operativmiljö kräver ofta ett mycket pålitligt informationsbehandlingssystem, ofta byggt på ett MLS-operativsystem (OS), men inte nödvändigtvis. De flesta MLS-funktioner kan stödjas av ett system som helt består av opålitliga datorer, även om det kräver flera oberoende datorer länkade av hårdvarusäkerhetskompatibla kanaler (se avsnitt B.6.2 i Trusted Network Interpretation, NCSC-TG-005 ). Ett exempel på hårdvarupåtvingad MLS är asymmetrisk isolering . Om en dator används i MLS-läge måste den datorn använda ett pålitligt operativsystem (OS). Eftersom all information i en MLS-miljö är fysiskt tillgänglig av operativsystemet, måste starka logiska kontroller finnas för att säkerställa att åtkomst till information är strikt kontrollerad. Vanligtvis involverar detta obligatorisk åtkomstkontroll som använder säkerhetsetiketter, som Bell–LaPadula-modellen .

Kunder som använder pålitliga operativsystem kräver vanligtvis att produkten genomför en formell datorsäkerhetsutvärdering. Utvärderingen är striktare för ett bredare säkerhetsområde, som är de lägsta och högsta klassificeringsnivåerna som systemet kan bearbeta. Trusted Computer System Evaluation Criteria (TCSEC) var de första utvärderingskriterierna som utvecklades för att bedöma MLS i datorsystem. Under dessa kriterier fanns en tydlig enhetlig kartläggning mellan säkerhetskraven och bredden av MLS-säkerhetsområdet. Historiskt sett har få implementeringar certifierats kapabla till MLS-bearbetning med ett säkerhetsintervall av Oklassificerad genom Top Secret. Bland dem var Honeywells SCOMP, USAF SACDIN, NSA :s Blacker och Boeings MLS LAN, alla under TCSEC, 1980-tals vintage och Intel 80386 -baserade. För närvarande utvärderas MLS-produkter enligt Common Criteria . I slutet av 2008 certifierades det första operativsystemet (mer nedan) till en hög utvärderad säkerhetsnivå: Evaluation Assurance Level (EAL) - EAL 6+ / High Robustness, under överinseende av ett amerikanskt regeringsprogram som kräver säkerhet på flera nivåer i ett högt hot miljö. Även om denna garantinivå har många likheter med den gamla Orange Book A1 (som formella metoder), fokuserar funktionskraven på grundläggande isolerings- och informationsflödespolicyer snarare än policyer på högre nivå som Bell-La Padula. Eftersom Common Criteria frikopplade TCSEC:s parning av säkerhet (EAL) och funktionalitet (Protection Profile), har den tydliga enhetliga kartläggningen mellan säkerhetskrav och MLS-säkerhetsområdeskapacitet som dokumenterats i CSC-STD-004-85 till stor del gått förlorad när Common Criteria ersatte Rainbow-serien .

Fritt tillgängliga operativsystem med vissa funktioner som stöder MLS inkluderar Linux med den säkerhetsförbättrade Linux- funktionen aktiverad och FreeBSD . Säkerhetsutvärdering ansågs en gång vara ett problem för dessa gratis MLS-implementeringar av tre skäl:

  1. Det är alltid mycket svårt att implementera kärnans självskyddsstrategi med den precision som krävs för MLS-förtroende, och dessa exempel var inte designade för eller certifierade för en MLS-skyddsprofil så de kanske inte erbjuder det självskydd som behövs för att stödja MLS.
  2. Bortsett från EAL-nivåer saknar Common Criteria en inventering av lämpliga högsäkerhetsskyddsprofiler som anger den robusthet som krävs för att fungera i MLS-läge.
  3. Även om (1) och (2) uppfylldes är utvärderingsprocessen mycket kostsam och medför särskilda restriktioner för konfigurationskontroll av den utvärderade programvaran.

Trots sådana antaganden certifierades Red Hat Enterprise Linux 5 mot LSPP, RBACPP och CAPP vid EAL4+ i juni 2007. Den använder Security-Enhanced Linux för att implementera MLS och var den första Common Criteria-certifieringen för att upprätthålla TOE-säkerhetsegenskaper med Security Enhanced Linux .

Certifieringsstrategier för leverantörer kan vara vilseledande för lekmän. En vanlig strategi utnyttjar lekmannens överbetoning av EAL-nivå med övercertifiering, som att certifiera en EAL 3-skyddsprofil (som CAPP) till förhöjda nivåer, som EAL 4 eller EAL 5. En annan är att lägga till och certifiera MLS-stödfunktioner (som roll -baserad åtkomstkontrollskyddsprofil (RBACPP) och märkt säkerhetsskyddsprofil (LSPP)) till en kärna som inte utvärderas till en MLS-kapabel skyddsprofil. Dessa typer av funktioner är tjänster som körs på kärnan och är beroende av kärnan för att skydda dem från korruption och omstörtning. Om kärnan inte utvärderas till en MLS-kapabel skyddsprofil kan MLS-funktioner inte lita på oavsett hur imponerande demonstrationen ser ut. Det är särskilt anmärkningsvärt att CAPP specifikt inte är en MLS-kapabel profil eftersom den specifikt utesluter självskyddsfunktioner som är kritiska för MLS.

General Dynamics erbjuder PitBull , ett pålitligt MLS-operativsystem. PitBull erbjuds för närvarande endast som en förbättrad version av Red Hat Enterprise Linux , men tidigare versioner fanns för Sun Microsystems Solaris, IBM AIX och SVR4 Unix. PitBull tillhandahåller en Bell LaPadula- säkerhetsmekanism, en Biba -integritetsmekanism, en behörighetsersättning för superanvändare och många andra funktioner. PitBull har säkerhetsbasen för General Dynamics Trusted Network Environment (TNE) -produkt sedan 2009. TNE möjliggör informationsdelning och åtkomst på flera nivåer för användare i försvarsdepartementet och underrättelsetjänster som använder olika klassificeringsnivåer. Det är också grunden för multilevel-koalitionsdelningsmiljön, Battlefield Information Collection och Exploitation Systems Extended (BICES-X).

Sun Microsystems , nu Oracle Corporation , erbjuder Solaris Trusted Extensions som en integrerad funktion i de kommersiella operativsystemen Solaris och OpenSolaris . Förutom skyddsprofilen för kontrollerad åtkomst (CAPP) och för rollbaserad åtkomstkontroll (RBAC), har Trusted Extensions även certifierats vid EAL4 till den märkta säkerhetsskyddsprofilen (LSPP). Säkerhetsmålet inkluderar både skrivbords- och nätverksfunktionalitet. LSPP kräver att användare inte har behörighet att åsidosätta märkningspolicyerna som tillämpas av kärnan och X Window System ( X11-server). Utvärderingen innehåller inte en dold kanalanalys . Eftersom dessa certifieringar är beroende av CAPP, tyder inga Common Criteria-certifieringar på att denna produkt är pålitlig för MLS.

BAE Systems erbjuder XTS-400 , ett kommersiellt system som stöder MLS med vad leverantören hävdar är "hög säkerhet". Föregående produkter (inklusive XTS-300) utvärderades på TCSEC B3-nivå, som är MLS-kapabel. XTS-400 har utvärderats enligt Common Criteria vid EAL5+ mot CAPP- och LSPP-skyddsprofilerna. CAPP och LSPP är båda EAL3-skyddsprofiler som inte i sig är MLS-kapabla, men säkerhetsmålet för Common Criteria-utvärderingen av denna produkt innehåller en berikad uppsättning säkerhetsfunktioner som ger MLS-kapacitet.

Problemområden

Sanering är ett problemområde för MLS-system. System som implementerar MLS-restriktioner, som de som definieras av Bell–LaPadula-modellen , tillåter endast delning när det uppenbarligen inte bryter mot säkerhetsrestriktioner. Användare med lägre utrymmen kan enkelt dela sitt arbete med användare som har högre utrymmen, men inte vice versa. Det finns ingen effektiv, pålitlig mekanism genom vilken en Top Secret-användare kan redigera en Top Secret-fil, ta bort all Top Secret-information och sedan leverera den till användare med hemlig eller lägre tillstånd. I praktiken kringgår MLS-system detta problem via privilegierade funktioner som gör att en pålitlig användare kan kringgå MLS-mekanismen och ändra en fils säkerhetsklassificering. Tekniken är dock inte tillförlitlig .

Hemliga kanaler utgör ett annat problem för MLS-system. För att ett MLS-system ska hålla hemligheter perfekt måste det inte finnas något möjligt sätt för en Top Secret process att överföra signaler av något slag till en hemlig eller lägre process. Detta inkluderar biverkningar som förändringar i tillgängligt minne eller diskutrymme, eller förändringar i processtiming. När en process utnyttjar en sådan bieffekt för att överföra data, utnyttjar den en hemlig kanal. Det är extremt svårt att stänga alla hemliga kanaler i ett praktiskt datorsystem, och det kan vara omöjligt i praktiken. Processen att identifiera alla hemliga kanaler är en utmanande i sig. De flesta kommersiellt tillgängliga MLS-system försöker inte stänga alla hemliga kanaler, även om detta gör det opraktiskt att använda dem i högsäkerhetsapplikationer.

Bypass är problematiskt när det introduceras som ett sätt att behandla ett systemhögt objekt som om det vore MLS-betrodd. Ett vanligt exempel är att extrahera data från ett hemligt system-high-objekt för att skickas till en oklassificerad destination, med hänvisning till någon egenskap hos datan som pålitligt bevis på att det är "verkligen" oklassificerat (t.ex. "strikt" format). Ett system högt system kan inte lita på att bevara några pålitliga bevis, och resultatet är att en öppen dataväg öppnas utan något logiskt sätt att säkert förmedla den. Bypass kan vara riskabelt eftersom, till skillnad från hemliga kanaler med smal bandbredd som är svåra att exploatera, kan bypass uppvisa en stor, lätt exploaterad öppen läcka i systemet. Bypass uppstår ofta på grund av underlåtenhet att använda betrodda operativa miljöer för att upprätthålla kontinuerlig separation av säkerhetsdomäner hela vägen tillbaka till deras ursprung. När det ursprunget ligger utanför systemgränsen är det kanske inte möjligt att validera den betrodda separationen till ursprunget. I så fall kan risken för bypass vara oundviklig om flödet verkligen är viktigt.

Ett vanligt exempel på oundviklig förbikoppling är ett ämnessystem som krävs för att acceptera hemliga IP-paket från en opålitlig källa, kryptera den hemliga användardatan och inte rubriken och deponera resultatet till ett opålitligt nätverk. Källan ligger utanför subjektsystemets inflytandesfär. Även om källan är otillförlitlig (t.ex. systemhög) är den betrodd som om den vore MLS eftersom den tillhandahåller paket som har oklassificerade rubriker och hemliga användardata i klartext, en MLS-datakonstruktion. Eftersom källan inte är pålitlig kan den vara korrupt och placera hemligheter i den oklassificerade pakethuvudet. De korrupta pakethuvudena kan vara nonsens, men det är omöjligt för ämnessystemet att avgöra det med någon rimlig tillförlitlighet. Paketanvändardata är kryptografiskt väl skyddade men pakethuvudet kan innehålla läsbara hemligheter. Om de korrupta paketen skickas till ett opålitligt nätverk av det aktuella systemet kanske de inte är routbara men någon samarbetande korrupt process i nätverket kan ta tag i paketen och bekräfta dem och det aktuella systemet kanske inte upptäcker läckan. Detta kan vara en stor öppen läcka som är svår att upptäcka. Att se klassificerade paket med oklassificerade rubriker som systemhöga strukturer istället för de MLS-strukturer de verkligen är utgör ett mycket vanligt men allvarligt hot.

De flesta bypass kan undvikas. Undvikbar förbikoppling uppstår ofta när systemarkitekter designar ett system innan de överväger säkerheten korrekt och sedan försöker tillämpa säkerhet i efterhand som tilläggsfunktioner. I den situationen verkar bypass vara det enda (enkla) sättet att få systemet att fungera. Vissa pseudo-säkra system föreslås (och godkända!) som undersöker innehållet i de förbikopplade uppgifterna i ett fåfängt försök att fastställa att förbikopplad data inte innehåller några hemligheter. Detta är inte möjligt utan att lita på något om datan såsom dess format, vilket strider mot antagandet att källan inte är pålitlig för att bevara några egenskaper hos källdata. Försäkrad "säker förbikoppling" är en myt, precis som en så kallad High Assurance Guard (HAG) som transparent implementerar förbikoppling. Risken dessa inför har länge varit medveten; Befintliga lösningar är i slutändan processuella snarare än tekniska. Det finns inget sätt att med säkerhet veta hur mycket sekretessbelagd information som tas från våra system genom utnyttjande av bypass.

"Det finns inget sådant som MLS"

Det finns en minskning av COMPUSEC- experter och MLS-termen har blivit överbelastad . Lekmän designar säkra datorsystem och drar slutsatsen att MLS inte existerar. Dessa två användningsområden är: MLS som bearbetningsmiljö kontra MLS som förmåga. Tron på att MLS är obefintlig är baserad på tron ​​att det inte finns några produkter som är certifierade för att fungera i en MLS- miljö eller -läge och att MLS därför inte existerar som en förmåga . Det ena innebär inte det andra. Många system fungerar i en miljö som innehåller data som har olika säkerhetsnivåer och därför är MLS enligt Computer Security Intermediate Value Theorem (CS-IVT). Konsekvensen av denna förvirring går djupare. NSA-certifierade MLS-operativsystem, databaser och nätverk har funnits i driftläge sedan 1970-talet och att MLS-produkter fortsätter att byggas, marknadsföras och distribueras.

Lekmän drar ofta slutsatsen att att erkänna att ett system fungerar i en MLS-miljö (miljöcentrerad betydelse av MLS) är att backas in i det upplevda hörnet av att ha ett problem utan MLS-lösning (kapacitetscentrerad betydelse av MLS). MLS är bedrägligt komplex och bara för att enkla lösningar inte är uppenbara motiverar det inte en slutsats att de inte existerar. Detta kan leda till en förlamande okunskap om COMPUSEC som visar sig som viskningar att "man inte kan prata om MLS" och "Det finns inget sådant som MLS." Dessa MLS-förnekelsescheman förändras så snabbt att de inte kan åtgärdas. Istället är det viktigt att klargöra skillnaden mellan MLS-miljö och MLS-kapabel.

  • MLS som en säkerhetsmiljö eller säkerhetsläge : En grupp vars användare har olika säkerhetstillstånd kan uppfatta MLS som en datadelningsförmåga : användare kan dela information med mottagare vars tillstånd tillåter mottagande av den informationen. Ett system arbetar i MLS-läge när det har (eller skulle kunna ha) anslutning till en destination som är rensad till en lägre säkerhetsnivå än någon av de data som MLS-systemet innehåller. Detta är formaliserat i CS-IVT. Bestämning av säkerhetsläge för ett system beror helt på systemets säkerhetsmiljö; klassificeringen av data den innehåller, godkännandet av de som kan få direkt eller indirekt tillgång till systemet eller dess utgångar eller signaler, och systemets anslutningsmöjligheter och portar till andra system. Säkerhetsläget är oberoende av kapacitet, även om ett system inte bör köras i ett läge som det inte är värt att lita på.
  • MLS som en förmåga : Utvecklare av produkter eller system som är avsedda att tillåta MLS-datadelning tenderar att löst uppfatta det i termer av en förmåga att upprätthålla begränsningar för datadelning eller en säkerhetspolicy, som mekanismer som upprätthåller Bell–LaPadula- modellen . Ett system är MLS-kapabelt om det kan visas att det implementerar en säkerhetspolicy på ett robust sätt.

Den ursprungliga användningen av termen MLS tillämpades på säkerhetsmiljön eller läget. En lösning på denna förvirring är att behålla den ursprungliga definitionen av MLS och vara specifik om MLS-kapabel när det sammanhanget används.

MILS arkitektur

Multiple Independent Levels of Security (MILS) är en arkitektur som adresserar domänseparationskomponenten i MLS. Observera att UCDMO (den amerikanska regeringens ledare för system över flera domäner och flernivåsystem) skapade en term Cross Domain Access som en kategori i sin baslinje av DoD och Intelligence Community ackrediterade system, och denna kategori kan ses som i huvudsak analog med MILS.

Säkerhetsmodeller som Biba-modellen (för integritet) och Bell–LaPadula-modellen (för konfidentialitet) tillåter envägsflöde mellan vissa säkerhetsdomäner som annars antas vara isolerade. MILS adresserar isoleringen som ligger bakom MLS utan att adressera den kontrollerade interaktionen mellan domänerna som adresseras av ovanstående modeller. Pålitliga säkerhetskompatibla kanaler som nämns ovan kan länka MILS-domäner för att stödja fler MLS-funktioner.

MILS-metoden följer en strategi som kännetecknas av en äldre term, MSL ( multiple single level ), som isolerar varje informationsnivå inom sin egen ennivåmiljö ( System High ).

Den stela processkommunikation och isolering som erbjuds av MILS kan vara mer användbar för mjukvaruapplikationer med ultrahög tillförlitlighet än MLS. MILS tar särskilt inte upp den hierarkiska struktur som förkroppsligas av begreppet säkerhetsnivåer. Detta kräver tillägg av specifika import-/exportapplikationer mellan domäner som var och en måste ackrediteras på lämpligt sätt. Som sådan kan MILS bättre kallas Multiple Independent Domains of Security (MLS-emulering på MILS skulle kräva en liknande uppsättning ackrediterade applikationer för MLS-applikationerna). Genom att avstå från att ta itu med out-of-the-box interaktion mellan nivåer som överensstämmer med Bell-La Padulas hierarkiska relationer är MILS (nästan bedrägligt) enkelt att implementera initialt men behöver icke-triviala kompletterande import-/exportapplikationer för att uppnå den rikedom och flexibilitet som förväntas av praktiska MLS-applikationer.

Varje MILS/MLS-jämförelse bör överväga om ackreditering av en uppsättning enklare exportapplikationer är mer möjlig än ackreditering av en, mer komplex MLS-kärna. Denna fråga beror delvis på omfattningen av de import/export-interaktioner som intressenterna kräver. Till förmån för MILS är möjligheten att inte alla exportansökningar kommer att kräva maximal säkerhet.

MSL-system

Det finns ett annat sätt att lösa sådana problem som kallas multipla single-level . Varje säkerhetsnivå är isolerad i en separat otillförlitlig domän. Frånvaron av kommunikationsmedium mellan domänerna säkerställer att ingen interaktion är möjlig. Mekanismen för denna isolering är vanligtvis fysisk separation i separata datorer. Detta används ofta för att stödja applikationer eller operativsystem som inte har någon möjlighet att stödja MLS som Microsoft Windows .

Ansökningar

Infrastruktur som tillförlitliga operativsystem är en viktig komponent i MLS-system, men för att uppfylla kriterierna som krävs enligt definitionen av MLS av CNSSI 4009 (omskrivet i början av denna artikel), måste systemet tillhandahålla ett användargränssnitt som är kapabelt att tillåta en användare att komma åt och bearbeta innehåll på flera klassificeringsnivåer från ett system. UCDMO körde ett spår specifikt fokuserat på MLS vid NSA Information Assurance Symposium 2009, där det lyfte fram flera ackrediterade (i produktion) och framväxande MLS-system. Observera användningen av MLS i SELinux .

Det finns flera databaser som klassificeras som MLS-system. Oracle har en produkt som heter Oracle Label Security (OLS) som implementerar obligatoriska åtkomstkontroller - vanligtvis genom att lägga till en "etikett"-kolumn till varje tabell i en Oracle-databas . OLS distribueras vid US Army INSCOM som grunden för en "all-source" intelligensdatabas som spänner över JWICS- och SIPRNet -nätverken. Det finns ett projekt för att skapa en märkt version av PostgreSQL , och det finns även äldre märkta databasimplementeringar som Trusted Rubix . Dessa MLS-databassystem tillhandahåller ett enhetligt back-end-system för innehåll som spänner över flera etiketter, men de löser inte utmaningen att låta användare bearbeta innehåll på flera säkerhetsnivåer i ett system samtidigt som de upprätthåller obligatoriska åtkomstkontroller.

Det finns också flera MLS-slutanvändarapplikationer. Den andra MLS-kapaciteten som för närvarande finns på UCDMO-baslinjen kallas MLChat Archived 2013-03-17 at the Wayback Machine , och det är en chattserver som körs på operativsystemet XTS-400 - den skapades av US Naval Research Laboratory . Med tanke på att innehåll från användare på olika domäner passerar genom MLChat-servern, används smutsavsökning för att skydda sekretessbelagt innehåll, och det har förekommit en del debatt om om detta verkligen är ett MLS-system eller mer en form av dataskydd för överföring över flera domäner . Obligatoriska åtkomstkontroller upprätthålls av en kombination av XTS-400 och applikationsspecifika mekanismer.

Joint Cross Domain eXchange (JCDX) är ett annat exempel på en MLS-kapacitet som för närvarande finns på UCDMO [ permanent död länk ] baslinjen. JCDX är det enda försvarsdepartementet (DoD), Defense Intelligence Agency (DIA) ackrediterade Multilevel Security (MLS) Command, Control, Communication, Computers and Intelligence (C4I) system som ger nästan realtidsunderrättelse och varningsstöd till teater och framåt utplacerade taktiska chefer. JCDX-arkitekturen är heltäckande integrerad med ett högsäkerhetsskyddsnivå fyra (PL4) säkert operativsystem, som använder datamärkning för att sprida nästan realtidsdatainformation om styrkans aktiviteter och potentiella terrorhot på och runt världshaven. Den är installerad på platser i USA och allierade partnerländer där den kan tillhandahålla data från Top Secret/SCI ner till Secret-Releasable nivåer, allt på en enda plattform.

MLS-applikationer som för närvarande inte ingår i UCDMO:s baslinje inkluderar flera applikationer från BlueSpace . BlueSpace har flera MLS-applikationer, inklusive en MLS-e-postklient, en MLS-sökapplikation och ett MLS C2-system. BlueSpace använder en middleware-strategi för att göra det möjligt för sina applikationer att vara plattformsneutrala, och orkestrerar ett användargränssnitt över flera Windows OS-instanser ( virtualiserade eller fjärranslutna terminalsessioner) . US Naval Research Laboratory har också implementerat ett webbapplikationsramverk på flera nivåer som heter MLWeb som integrerar Ruby on Rails -ramverket med en flernivådatabas baserad på SQLite3 .

Framtida

Den kanske största förändringen som pågår inom flernivåsäkerhetsarenan idag är konvergensen mellan MLS och virtualisering. Ett ökande antal betrodda operativsystem går bort från att märka filer och processer och går istället mot UNIX-behållare eller virtuella maskiner . Exempel inkluderar zoner i Solaris 10 TX och den vadderade cellhypervisorn i system som Green Hills Integrity -plattform och XenClient XT från Citrix. High Assurance-plattformen från NSA som implementerad i General Dynamics Trusted Virtualization Environment (TVE) är ett annat exempel - den använder SELinux i sin kärna och kan stödja MLS-applikationer som spänner över flera domäner.

Se även

  1. ^    Davidson, JA (1996-12-09). "Asymmetrisk isolering". Proceedings 12:e årliga datasäkerhetskonferensen . Konferens för datorsäkerhetsapplikationer . s. 44–54. doi : 10.1109/CSAC.1996.569668 . ISBN 978-0-8186-7606-2 . S2CID 21977652 .
  2. ^ CSC-STD-004-85: Datorsäkerhetskrav - vägledning för tillämpning av försvarsdepartementet Pålitliga kriterier för utvärdering av datorsystem i specifika miljöer ( 25 juni 1985)
  3. ^ Flernivåsäkerhetskonfidentialitetspolicy i FreeBSD
  4. ^ "Validerad produkt - Red Hat Enterprise Linux version 5 som körs på IBM-hårdvara" . National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, USA. 7 juni 2007. {{ citera journal }} : Cite journal kräver |journal= ( hjälp )
  5. ^ Kontrollerad åtkomstskyddsprofil (CAPP)
  6. ^ Corrin, Amber (2017-08-08). "Hur BICES-X underlättar global intelligens" . C4ISRNET . Hämtad 2018-12-10 .
  7. ^ "Solaris 10 Release 11/06 Trusted Extensions" . Communications Security Establishment Kanada. 2008-06-11. Arkiverad från originalet 2011-06-17 . Hämtad 2010-06-26 . {{ citera journal }} : Citera journal kräver |journal= ( hjälp )
  8. ^ "Säkerhetsmål, version 1.22 för XTS-400, version 6.4.U4" (PDF) . National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, USA. 2008-06-01. Arkiverad från originalet (PDF) 2011-07-23 . Hämtad 2010-08-11 . {{ citera journal }} : Citera journal kräver |journal= ( hjälp )
  9. ^ David Elliott Bell: Ser tillbaka på Bell–LaPadula-modellen - Tillägg Arkiverat 2011-08-27 på Wayback Machine (20 december 2006)
  10. ^ David Elliott Bell: Ser tillbaka på Bell–LaPadula-modellen (7 december 2005)
  11. ^ Till exempel:   Petersen, Richard (2011). Fedora 14 Administration och säkerhet . Surfing Turtle Press. sid. 298. ISBN 9781936280223 . Hämtad 2012-09-13 . SELinux referenspolicy [...] Multi-level security (MLS) lägger till en mer förfinad säkerhetsåtkomstmetod. MLS lägger till ett värde på säkerhetsnivå till resurser.
  12. ^ http://www.sse.gr/NATO/EreunaKaiTexnologiaNATO/36.Coalition_C4ISR_architectures_and_information_exchange_capabilities/RTO-MP-IST-042/MP-IST-042-12.pdf [ permanent död länk ]

Vidare läsning

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Multilevel_security&oldid=1110762509 "