Designregel Härdning av IT-system, utgåva 1.0

Relevanta dokument
<SYSTEM> <VERSION> INFORMATIONSSÄKERHETSDEKLARATION REALISERA (ISD-R) Inklusive 3 bilagor

<SYSTEMOMRÅDE> ISD-STRATEGI

Datum Diarienummer Ärendetyp. ange ange ange. Dokumentnummer. ange 1(15) <SYSTEM> <VERSION> IT-SÄKERHETSSPECIFIKATION VIDMAKTHÅLLA (ITSS-V)

SYSTGL GRANSKNINGSINSTRUKTION ISD 3.0

<SYSTEM> <VERSION> INFORMATIONSSÄKERHETSDEKLARATION IDENTIFIERA (ISD-I) Inklusive 2 bilagor

<SYSTEM> <VERSION> INFORMATIONSSÄKERHETSDEKLARATION DEFINIERA (ISD-D) Inklusive 3 bilagor

Datum Diarienummer Ärendetyp. ange ange ange. Dokumentnummer. ange 1(9) <SYSTEM> <VERSION> ANALYSUNDERLAG VIDMAKTHÅLLA (AU-V)

ISE GRANSKNINGSINSTRUKTION ISD 3.0

<SYSTEM> <VERSION> ISD-PLAN

Datum Diarienummer Ärendetyp. ange ange ange. Dokumentnummer. ange 1(12) <SYSTEM> <VERSION> ANALYSUNDERLAG IDENTIFIERA (AU-I)

ISD - IT-säkerhetsdeklaration. Information till SESAME Dan Olofsson PrL ISD

Beslut. Vårt tjänsteställe, handläggare Vårt föregående datum Vår föregående beteckning Daniel Kuehn, FM :2

Checklista Identitetshanteringssystem för SWAMID 2.0. Utarbetad tillsammans med SUNET CERT och SUSEC

BEGREPP OCH FÖRKORTNINGAR ISD 3.0

BREV. Your reference Your date Your file code. Our reference Our previous date Our previous file code AK Led, Eva Hammarlund,

Metodstöd för ISD-processen. Övergripande beskrivning

Metodbeskrivning för framtagning av. Användningsfall. Användningsfall

Presentation av H ProgSäk 2018

Request for Information Kameratjänster

1(13) FMV6474-1: Designregel. Sven Tholin, Håkan Seipel, Teknisk Direktör. Designregel Förnödenhetsdataregistrering.

GTP Info KP P-O Risberg Jaan Haabma GTP Info KP Inforum 1

Granskning av generella IT-kontroller för PLSsystemet

ISD. Etablering av ISD inom FMV. Dan Olofsson PrL ISD

Metodbeskrivning för framtagning av ITSS 2: IT-säkerhetsarkitektur. Framtagning av ITSS 2

FÖRSVARSMAKTENS INTERNA BESTÄMMELSER

Metodbeskrivning för genomförande av Oberoende värdering i ISD-processens faser Produktion och Leverans till FM. Oberoende värdering i ISD-processen

Metodbeskrivning för framtagning av. ISD/ISU-plan. ISD/ISU-plan

Hogias Ekonomisystem. Systemkrav för enanvändarinstallation fr o m version av GENERELLA KRAV

Bilaga 9 Säkerhet Dnr: /2015 Förfrågningsunderlag

IT-generella kontroller i Agresso, skattekontosystemet, Moms AG och Tina

För installationer av SQL Server som inte görs från Hogias installation måste följande inställningar göras:

Biometria Violweb. Installation kundportalaccess - för IT-administratörer. Mars 2019

Systemkrav 2014 för enanvändarinstallation fr o m version av

Strålsäkerhetsmyndighetens författningssamling

Modularitet VAD och HUR? Håkan Seipel FMV Tekn Dir 19:e maj 2009

Virtuell Server Tjänstebeskrivning

Systemkrav. Systemkrav för Hogia Approval Manager. Gäller från och med programversion

Kryptosamverkan. Träffpunkt CC Försvarets Materielverk/CSEC 2008 Document ID CB-039 Issue 0.4 SWEDISH CERTIFICATION BODY IT SECURITY

0. ALLMÄNT INNEHÅLL. Bilaga 1.Referensförteckning över angivna referenser i Verksamhetsåtagande. Handbok KRAVDOK Verksamhetsåtagande

Optimering av licenshantering Hur arbetar FMV? Björn Spåra Crayon AB

Installationsanvisning. Dokumenttyp Installationsanvisning Område Boss med delad databas

Interimistisk instruktion avseende TO under vidmakthållandeskede

Beslut. HÖGKVARTERET Datum Beteckning FM :1 Sida 1 (5) Ert tjänsteställe, handläggare Ert datum Er beteckning Signalskydd

Ny samverkan till stöd vid upphandling av kryptolösningar

Mobilt Efos och ny metod för stark autentisering

eklient Livscykelplaner i Samverkan Livscykelplaner eklient 1.0

Sjunet standardregelverk för informationssäkerhet

eklient Objekt 1 Livscykelplaner i Samverkan Livscykelplaner eklient 1.5

ANVISNING Säkerhetsuppdateringar för IT infrastruktur

Molnplattform. Version 1.0. Användarhandbok

Metodstöd för ISD-processen Övergripande beskrivning. Kundnyttan med ISD-processens metodstöd

Hå rd- och mjukvårukråv såmt rekommendåtioner fo r 3L Pro from version 2013.Q2

Gränsdragning mellan Försvarsmakten och FMV

Revisionsrapport. Granskning av intern styrning och kontroll av informationssäkerheten vid Verket för högskoleservice 2010.

Fördjupningsseminarium till Försvarsföretagsdagarna

VÄGLEDNING ATT UPPHANDLA PÅ ETT SÄKERT SÄTT

Hå rd- och mjukvårukråv såmt rekommendåtioner fo r 3L Pro from version 2013.Q3

Import och exportföreskrifter/kemiska produkter m.m. 1. Förordning (2014:425) om bekämpningsmedel Uppdaterad:

Internt penetrationstest. Tierps kommun. Revisionsrapport. Juni Erik Norman 1(6)

Remote Access Service

STYRNING AV DOKUMENT OCH DATA 1. SYFTE 2. OMFATTNING 3. ANSVAR / AKTUELLTHÅLLANDE 4. BESKRIVNING (5) Tore Magnusson

FÖRSVARSMAKTENS INTERNA BESTÄMMELSER

Krav för tillträde till KSU

HUR MAN LYCKAS MED BYOD

Kravspecifikation avseende Tunna klienter

Gallrings-/bevarandetider för loggar i landstingets IT-system

Systemkrav för enanvändarinstallation fr o m version av

IDE USB kabel Windows XP, Vista 7 löäzxcvbnmqwertyuiopåasdfghjklöäz [Version 1.4, ]

SOLLENTUNA FÖRFATTNINGSSAMLING 1

Säkra trådlösa nät - praktiska råd och erfarenheter

Lagring i molnet. Dokumenthantering i högskolans Office365 ur ett offentlighetsperspektiv

Finansinspektionens författningssamling

UtvecklingavErIT-miljö. Hjälp med datorproblem Allmän IT-support

Tjänstekomponent Mjukvaruplattform

Utarbetat av Område Informationsklass. Teknisk standard Ånge Kommun...1. Syfte med beskriven it-miljö...3. Hårdvara...

Hå rd- och mjukvårukråv såmt rekommendåtioner fo r 3L Pro from version 2015.Q1

Mobilt Efos och ny metod för stark autentisering

Lathund Blanketthotell Komma igång

Bilaga IT till förfrågningsunderlag Bil 3 Inledning

FMV Vägledning för ISD och SE. ISD och SE

Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet

Vad är molnet? Vad är NAV i molnet? Vem passar NAV i molnet för? Fördelar med NAV i molnet Kom igång snabbt...

ATIVA Development AB. ATIVA-Mätdon. Produktinformation. Sidan 1 av 6

Konsoliderad version av

Bilaga Funktionshyra Vårdval Gynekologi sida 1 (5) FUNKTIONSHYRA. Vårdval Gynekologi

LEDNINGSÄGARMODUL. Systemkrav 1(6)

Oberoende granskning i ISD-processen

Övergripande säkerhetsgranskning av kommunens säkerhet angående externa och interna dataintrång. Klippans kommun

Anvisningar för användare vid användning av e- Tjänster. Anvisningar och rekommendationer för användare av e-tjänster i samverkan SAML & SSO

Upprättande av säkerhetsskyddsavtal i Nivå 1

Rikspolisstyrelsens författningssamling

Helt omarbetad från föregående utgåva för att matcha RML och spårbarhetskrav.

Mission Network som plattform Hur möter vi det?

STYRKAN I ENKELHETEN. Business Suite

Instruktion. Datum (12) Coverage Dokument id Rev Status? Godkänd. Tillhör objekt -

Att införa LIS. Informationssäkerhet för offentlig sektor Johan Kallum Säkerhetschef/Informationssäkerhetschef

IT-säkerhetspolicy Instruktion Kommunfullmäktige. Senast reviderad Beskriver IT-säkerhetarbetet.

Definition av tjänst Datorarbetsplats

Vårdval primär hörselrehabilitering i Östergötland

Transkript:

1.0 1(9) Giltig t.o.m. t.v. Upphäver Beslutande Kristin Strömberg Teknisk Direktör Föredragande Dan Olofsson SPL Stab S&D Designregel Härdning av IT-system, utgåva 1.0 Sammanfattning Denna designregel reglerar användningen av rekommendationer för härdning (säkerhetskonfigurering) av IT-system ingående i de tekniska system för vilka FMV tar designansvar. Designregeln ingår som en av flera designregler inom området IT-säkerhet och utgör designstyrande handlingsregler vid kravtolkning av de krav som Försvarsmakten ställer i Beslut om krav på godkända säkerhetsfunktioner version 3.1(KSF v3.1) kravklass SFIS_HRD - Systemets komponenter ska härdas mot intrång.

1.0 2(9) Innehåll Designregel Härdning av IT-system, utgåva 1.0... 1 1 Inledning... 3 1.1 Bakgrund... 3 1.2 Syfte... 3 1.3 Omfattning... 3 1.4 Beroenden... 3 1.5 Avsteg... 4 1.6 Termer, definitioner och förkortningar... 4 1.6.1 Termer och definitioner... 4 1.6.2 Förkortningar... 4 2 Dokumentinformation... 5 2.1 Dokumentändringsinformation... 5 2.2 Giltighet... 5 2.3 Sekretessbedömning och ev. informationssäkerhetsklass... 5 2.4 Bilageförteckning... 5 2.5 Referensdokument... 5 2.6 Styrande dokument... 5 3 Diskussion... 5 4 Designregel... 7 4.1 Regel 1... 7 4.1.1 Regeltillämpning... 7 4.1.2 Exempel... 7 4.2 Regel 2... 7 4.2.1 Regeltillämpning... 7 4.2.2 Exempel... 7 4.3 Regel 3... 7 4.3.1 Regeltillämpning... 7 4.3.2 Exempel... 7 4.4 Regel 4... 8 4.4.1 Regeltillämpning... 8 4.4.2 Exempel... 8 5 Förutsättningar för designregelns användning... 8 6 Planerad revidering och utveckling av designregel... 8 7 CCB ställningstagande... 9 8 Beslut... 9

1.0 3(9) 1 Inledning 1.1 Bakgrund Härdning av IT-system är en förutsättning för att kunna uppfylla de krav som Försvarsmakten ställer i KSF 3.1, se ref [4], kravklass SFIS_HRD. Härdning innebär att i IT-systemet ingående operativsystem, inbyggda program (firmware), nätverkskomponenter, databaser och andra applikationer konfigureras på ett så säkert sätt som möjligt. Exempelvis kan åtkomsträttigheterna i systemet och dess ingående delar begränsas, möjliga attackvägar via osäkra funktioner i infrastrukturkomponenter och applikationer skäras av och exponering från externa enheter förhindras. I många fall rådet en osäkerhet avseende vad som avses med kraven på härdning enligt KSF och kravtolkningen beror till stor del på de personliga erfarenheterna som finns i varje projekt respektive aktuell MUST-handläggares uppfattning. Detta medför att IT-systemen härdas utifrån olika rekommendationer baserat på personliga uppfattningar vilket försvårar möjligheterna till enhetlighet och effektivitet inom området. 1.2 Syfte Det övergripande syftet med designregeln är att de tekniska system som FMV utövar tekniskt designansvar för ska bestå av IT-komponenter som tillsammans uppfyller Försvarsmaktens krav på härdning enligt KSF på ett så effektivt sätt som möjligt. Designregeln skapar förutsättningar för: 1. att etablera en gemensam grund för samverkan mellan FMV och FM avseende kravtolkning och kravuppfyllnad inom området. 2. att möjliggöra för FMV och industrin att bygga upp kompetens inom området. 3. underlätta återbruk genom att IT-komponenter har härdats enligt samma rekommendationer. 4. att FMV kan ta designansvar för det tekniska systemet. 5. att det tekniska systemet kan ackrediteras inom FM. 1.3 Omfattning Denna utgåva av designregeln definierar hur KSF v3.1 krav SFIS_HRD.2 ska tolkas inom FMV samt vilka rekommendationer som härdningen ska baseras på. I denna utgåva definieras inte i vilken omfattning härdningsrekommendationerna ska implementeras, alltså hur mycket som ska härdas. Detta görs istället genom kravtolkning av övriga SFIS_HRD krav i varje enskilt fall. 1.4 Beroenden Inga identifierade.

1.0 4(9) 1.5 Avsteg Avsteg från denna designregel får endast ske efter beslut av designansvarig. Begäran om avsteg framställs skriftligen och ställs till Teknisk Chef som efter samråd med KravF IT-säk fattar beslut avseende eventuellt avsteg. 1.6 Termer, definitioner och förkortningar 1.6.1 Termer och definitioner Term Definition Källa Härdning Tekniskt designansvar Principen om minsta möjliga rättigheter (Least privilege) ITkomponent IT-system 1.6.2 Förkortningar Säkerhetskonfigurering av IT-system genom att det som inte behövs för ITsystemets definierade funktion ska vara begränsat avseende åtkomst, avstängt eller borttaget ur systemet. Tekniskt designansvar utövas av Försvarets materielverk för alla produkter Försvarets materielverk levererar till Försvarsmakten För varje abstraktionslager i ett ITsystem ska varje subjekt, alltså person, program eller process endast ska ha de rättigheter som behövs för att kunna utföra de handlingar och operationer som är legitima. allmänt vedertagen Del av IT-system KSF v3.1 System med teknik som hanterar och utbyter information med omgivningen SAMO 2017 Annex A A4 https://en.wikipedia.org/wi ki/principle_of_least_privi lege KSF v3.1 Förk. Fullständig benämning Källa CIS Center for Internet Security www.cisecurity.org KSF Krav på IT-säkerhetsförmågor hos ITsystem Beslut om krav på godkända säkerhetsfunktioner version KravF IT-säk FMV kravföreträdare inom ITsäkerhetsområdet 3.1 (KSF v3.1) 15FMV6214-3:1, 2015-06- 18 Kommentarer/ Anmärkningar Kommentarer / Anmärkninga r

2 Dokumentinformation 2.1 Dokumentändringsinformation 1.0 5(9) Datum Utgåva Beskrivning Författare 2017-12-01 1.0 Första utgåvan Christian Fenger-Krog 2.2 Giltighet Gäller tills vidare. 2.3 Sekretessbedömning och ev. informationssäkerhetsklass Detta dokument bedöms ej innehålla uppgifter som omfattas av sekretess. 2.4 Bilageförteckning Ej tillämplig. 2.5 Referensdokument Dokumenttitel Dokumentbeteckning, datum Utgåva nr [1] Center for Internet Security härdningsrekommendationer, CIS benchmarks TM [2] White Paper. System Hardening Guidance for XenApp and XenDesktop. www.cisecurity.org/cis-benchmarks December 1, 2016 (https://www.citrix.com/content/dam/citrix/ en_us/documents/productssolutions/system-hardening-for-xenappand-xendesktop.pdf) [3] "Samråd" MUST Designregel Härdning 17FMV9847-1:1, 2017-11-30 2.6 Styrande dokument Dokumenttitel Dokumentbeteckning, datum Utgåva nr [4] Beslut om krav på godkända FM2014-5302:1 2014-06-13 3.1 säkerhetsfunktioner version 3.1 (KSF v3.1) 14FMV11462-1, 2014-06-16 [5] SAMO 2017, Annex A 15FMV10173-4:1, 2016-12-21 3 Diskussion Härdning av IT-system är, tillsammans med regelbunden uppdatering av kända säkerhetsbrister med s.k. säkerhetspatchar en del av det breda grundläggande skyddet i ett IT-system. Uppdatering av säkerhetsbrister med säkerhetspatchar åtgärdar kända brister kopplat till produktens specificerade funktion. Om och hur dessa brister kan utnyttjas av en angripare beror på hur produkten är utformad från leverantören samt hur den är konfigurerad i sin aktuella 1.1

1.0 6(9) instans. Säkerhetskonfigurering, eller härdning, utgår från principen att det som inte behövs för IT-systemets definierade funktion ska vara avstängt eller borttaget ur systemet. En jämförelse med den fysiska världen skulle kunna vara se ett IT-system som en skyddsvärd byggnad med alldeles för många dörrar, alltså både sådana som behövs för den definierade verksamheten och sådana som är onödiga. Regelbundet upptäcks lås som inte fungerar som förväntat och det går därför inte att lita på att dörrarna faktiskt är låsta. Att uppdatera kända säkerhetbrister (patcha) är som att byta ut de låsen vi vet är trasiga mot nya. Att härda IT-systemet är jämförbart med att svetsa igen de dörrar som inte behövs så att även om låsen går sönder så finns ett skydd mot obehörigt intrång. Härdning av IT-system baseras alltså till stor del på principen Least privilege - Principen om minsta möjliga rättigheter. För varje abstraktionslager i ett IT-system ska därför varje subjekt, alltså person, program eller process endast ska ha de rättigheter som behövs för att kunna utföra de handlingar och operationer som är legitima. Andra principer som omfattas är Minimalize Minimalisering som innebär att mängden funktioner i systemet begränsas och Defence in depth Försvar på djupet som innebär att det ska finnas säkerhetsfunktioner på olika nivåer i systemet; kommer man förbi en ska det finnas andra bakom. För att härda IT-systemet på rätt sätt finns det en mängd olika rekommendationer från både tillverkare och andra aktörer på marknaden. Rekommendationer från tillverkare är begränsade till den aktuella produkten och ingår oftast i licenskostnaden. Kvaliteten på rekommendationerna kan vara svår att bedöma och varierar utifrån tillverkarens ambitionsnivå. Som alternativ finns rekommendationer från oberoende organisationer och dessa är oftast bredare och omfattar ett "paket" med de vanligaste systemdelarna. Dessa rekommendationer omfattas i många fall av licenskostnader alternativt kostnader för medlemskap i den aktuella organisationen. Krav på härdning återfinns i KSF v3.1 kravklass SFIS_HRD. I denna klass finns krav SFIS_HRD.2 som lyder: Ingående delar i systemet ska konfigureras enligt tillverkarens rekommendationer för säker konfiguration. Om sådana inte finns ska av IT-säkerhetsbranschen vedertagna rekommendationer för säker konfiguration av komponenttypen användas. Vad Tillverkarens rekommendationer innebär är svårt att definiera i en designregel då det finns en mängd tillverkare och dessa har olika typer av rekommendationer. Då denna designregel ska ge en övergripande styrning inom området har SFIS_HRD.2 istället tolkats/omformulerats så att det ger förutsättningar för en sådan styrning. Förutsättningen är att av IT-säkerhetsbranschen vedertagna rekommendationer ska användas i första hand då det kan definieras oberoende av vilka produkter som ingår. Designreglerna i kommande avsnitt utgår från detta synsätt. För att få förankring för Tolkningen/omformuleringen av krav SFIS_HRD.2 i KSF 3.1 samt innehållet i denna designregel har samråd inhämtats från MUST, se ref [3]

4 Designregel 4.1 Regel 1 1.0 7(9) 4.1.1 Regeltillämpning Krav SFIS_HRD.2 i KSF 3.1 ska tolkas enligt följande: Ingående delar i systemet ska konfigureras i enlighet med av IT-säkerhetsbranschen vedertagna rekommendationer för säker konfiguration av komponenttypen. Om sådan inte finns ska tillverkarens rekommendationer för säker konfiguration användas. 4.1.2 Exempel Detta innebär att kravet ska tolkas som att alla IT-system som ingår i tekniskt system som FMV tar tekniskt designansvar, se ref [5], för och som omfattas av KSF krav SFIS_HRD.2 i första hand ska härdas enligt de generella rekommendationer som definieras i denna designregel enligt Regel 2. Om det i dessa generella rekommendationer saknas underlag för härdning av relevant komponenttyp ska den aktuella tillverkarens härdningsrekommendationer användas enligt Regel 3. 4.2 Regel 2 4.2.1 Regeltillämpning Med av IT-säkerhetsbranschen vedertagna rekommendationer enligt Regel 1 avses CIS Center for Internet Securitys härdningsrekommendationer s.k. CIS benchmarks TM, se ref [1] 4.2.2 Exempel Detta innebär att alla IT-system som ingår i tekniskt system som FMV tar designansvar för och som omfattas av KSF krav SFIS_HRD.2 i första hand ska härdas enligt relevanta CIS benchmarks. Ett fiktivt IT-system innehåller programvarorna Windows, Red Hat Linux, Microsoft Office. Dessutom används Citrix XenDesktop. För Windows, Red Hat Linux och Microsoft Office finns CIS benchmarks för de aktuella versionerna. Dessa ska då användas för dessa programvaror. 4.3 Regel 3 4.3.1 Regeltillämpning Om relevanta CIS benchmarks saknas för i IT-systemet ingående komponenttyper ska respektive tillverkares rekommendationer för säker konfiguration användas. Saknas även rekommendationer från tillverkaren ska eventuella andra relevanta rekommendationer användas. Vid tillämpning av Regel 3 ska samverkan avseende bedömning av olika alternativ ske med FMV kravföreträdare (KravF) IT-säk, ISD@fmv.se. 4.3.2 Exempel För det fiktiva IT-systemet i 4.2.2 ovan saknas CIS benchmarks för Citrix XenDesktop. Istället ska då enligt Regel 1 tillverkarens rekommendationer användas, i detta exempel System Hardening Guidance for XenApp and XenDesktop, se ref [2]. Samverkan avseende denna kravtolkning sker först med FMV KravF IT-säk.

4.4 Regel 4 1.0 8(9) 4.4.1 Regeltillämpning Kravtolkningen av SFIS_HRD.1, SFIS_HRD.3, SFIS_HRD.4, SFIS_HRD.5, SFIS_HRD.6 och SFIS_HRD.7 ligger till grund för bedömningen avseende vilka av åtgärderna i de ovan definierade härdningsrekommendationerna som är relevanta för det aktuella systemet. Krav på tillgänglighet behöver särskilt beaktas i denna bedömning då den kan påverkas både positivt och negativt av olika typer av härdningar. 4.4.2 Exempel Om det fiktiva IT-systemet har höga krav på flexibilitet och ska behandla icke sekretessbelagd information i en omgivning med låg exponering kan en lägre nivå på härdningens omfattning bedömas rimlig jämfört med om det fiktiva IT-systemet inte behöver vara flexibelt, innehåller stor mängd sekretess och har en omgivning med större exponering. 5 Förutsättningar för designregelns användning CIS benchmarks finns att tillgå via FMV:s centralorgan för standardisering och standarder inom civilt och militärt försvar, FSD. Se http://fsd.fmv.se 6 Planerad revidering och utveckling av designregel Denna designregel kan framöver komma att kompletteras med styrning avseende till vilken nivå olika typer av IT-system ska härdas. Det finns vid fastställandet av denna utgåva ännu ingen tidsplan för när nästa utgåva ska ges ut.