Vad betyder IT säkerhet i praktiken - även för Mission Networks

Transkript

1 Vad betyder IT säkerhet i praktiken - även för Mission Networks Jaan Haabma Basesoft Open Systems AB jaan@basesoft.se

2 Säkerhet är svårt Vi inför säkerhet succesivt fr.o.m. version 2 Vi har ett särskilt delprojekt för säkerhet Vi använder godkända säkerhetskomponenter s.k. GFE Vi använder samma lösning som i system FOO Vi låter leverantören ansvara för säkerheten Säkerhet kan inte vara så komplicerat som säkerhetskonsulterna påstår Vi antar att säkerhetskraven inte gäller eller kommer ändras... Vi använder samma programvara som land NNN Det är mindre krav på säkerhet i internationella insatser =>

3 Mission Secret i internationell verksamhet [ur HSäkInfosäk] Begreppet Mission Secret avser information som är kopplad till en specifik internationell insats och som kan förekomma i samtliga motsvarigheter till de svenska informationssäkerhetsklasserna (och inte enbart i nivån SECRET). Det som styr omfattningen av skyddsåtgärder för information avgörs uteslutande av uppgifternas informationsklassificering. För uppgifter som kräver skyddsåtgärder vilka motsvaras av det svenska kravet på säkerhetsskydd, framgår sådana krav genom uppgifternas placering i motsvarigheten till våra informations-säkerhetsklasser (som t.ex. NATO SECRET, NATO/ISAF CONFIDENTIAL, RESTREINT UE osv.). I diskussioner framförs det ibland att man inom olika internationella organisationer (framförallt Nato) har ett begrepp, Mission Secret, som antyder att det på grund av sekretessens geografiska eller tidsmässiga begränsning inte behövs lika omfattande skyddsåtgärder för informationen. Detta synssätt är emellertid felaktigt [HSäkInfosäk]. Den enda självständiga betydelse som begreppet har är kopplat till delgivning av informationen. Information som är Mission Secret får, under vissa förutsättningar, delges efter beslut av den internationella insatsens befälhavare (Force Commander) istället för den normala och mer formella beslutsgången för delgivning av information inom Nato-systemet [HKV :52919, Innebörd av begreppet Mission Secret ]

4 Säkerhet blir bara svårare

5 Plus teknikutvecklingen

6 IT-säkerhet vad är det? Security - CIA + Audit Safety Confidentiality Integrity Audit/Accountability (traceability) Availability Robustness

7 Granskning Lagar, Förordn., OSL, ISO ISO ( LIS ) [jmf ISO 9000, ISO14000] FM DIT,... Dokument ( Papper ) Regelverk MUST-KSF CC STIL... PCI-DSS Uppfyllnad? Effekt? Nytta? OSA SP008 OWAST NIST SP Realisering Stöd för? Sekretess Integritet Tillgänglighet Spårbarhet Reviderbarhet Robusthet Funktion Styrka (SOF) Assurans Effektivitet Nytta Interop. Samverkan Flexibilitet Skalbarhet

8 Funktion, Styrka och Assurans Styrka Funktion Assurans Ofta svårt greppa / förstå / förmedla / realisera sambandet mellan funktion, styrka och assurans i säkerhetsfunktioner och säkerhetslösning (mekanismer)? Top Secret Sammanvägningen ofta inte alls beaktat i syfte att åstadkomma en reell, hållbar, effektiv och nyttig IT-säkerhet! Öppen

9 Assurans Basesoft Exempel behörighetskontroll - Integration i Windows H/R? Maximal assurans som kan uppnås Windows kommunikation (Internt i nod, över nätverk) Aktivt kort, Kortläsare Windows Behörighetsfunktion Kort- Kommunikation programvara Inloggningsprogramvara Windows Användare Windows Loggning Windows Administration. Ex: TAK-KT2 KrAPI Integr. Windows login Windows: IPC, RPC, Användare, BKS, Logg

10 Samverkan?

11 Samverkan? Samverkansportal (ex WEB) för specifik mission Ett antal separata system egna, missions-system, verka i annans system Integration A - Hur autentisera sig och mot vad, exv nationella PKI vs globala PKI strukturer, federationer, Individ i eget system, Roll i annat system Integration B -Behörigheter, behörighetskataloger,

12 Vem kan man lita på? Respektive internationellt samverkande system måste vara minst lika bra på IT-säkerhet som det andra systemet, dvs leder sannolikt till sammantaget lika eller högre krav på IT-säkerhet ju mer samverkan det blir Problem tex veta om / hur mycket det går att lita på andra systemets användare, credentials? Hur (väl) veta att det andra systemet minst uppfyller de egna kraven? Hur lita på COTS, Microsoft, utgivare av certifikat ( legitimation ) etc Ex SHBs BankID ( e-legitimation ) kan användas hos SKV, FK, men inte hos Nordea och vice versa Medför att ett svensk ledningssystem sannolikt inte kan användas i en NATO/USA ledd mission, utan det ledande landets system (delar av) måste användas parallellt med (isolerat från) det egna

13 Säkerhetsarkitektur Det är svårt (jobbigt, dyrt, nästan omöjligt, ) att efteråt tillföra IT-säkerhet i ett IT-system. Motsvarande gäller för alla systemegenskaper (s.k. ickefunktionella krav, kvalite er ) såsom skalbarhet, tekniktålighet, flexibilitet, etc. IT-säkerhet måste vara en del av IT-systemets arkitektur. Implicita (ex Windows) eller explicita val av säkerhetsarkitektur sätter dock möjliga gränser för säkerhet funktion, styrka och assurans d.v.s. vilken IT-säkerhet som faktiskt går att uppnå. Säkerhetslösning med explicit arkitektur och/eller lösa säkerhetskomponenter?

14 Samverkan! BO För att kunna samverka på riktigt med andra måste ens egen säkerhetsinfrastruktur i det egna ledningssystemet kunna separera all information ner till den minsta beståndsdel (objekt, resurs) A B J D E F G H C I K L A B C D E F G H J I K L Separation av all information ner till den minsta beståndsdel (objekt, resurs) => möjlig önskad och kontrollerad samverkan A B C D E F G H J I K L A B J D E F G H C I K L SESAM höstseminarium Jaan Haabma Traditionellt separata system - kontroll av informationsflöde ej möjlig

15 A Security Architecture Authentication A => Credentials Encryption (integrity, confidentiality) Access Control of A and/or C. Audit A through C A C B SEC Access Control of A. Audit A Access Control of A and/or C. Audit A through C. D All processes (Subjects A, B, C, D) are authenticated to a security server ( SEC ) Security server distributes credentials, including roles for the principal - A, B, C, D Access Control and logging is performed in shells to the design entitys (A, B, C, D now acting as objects) based on roles in the credentials. Access Control manager for each service (process, object) control access Credentials have a configurable life span. Can be renewed. Security server distributes encryption keys for communications A-C, C-B and C-D

16 Windows Kerberos Authentication (<=H/R?) TGT 2. Use hash(pwd ) to sign pre-auth! data in AS request (alt. PKI/Certificate Pre-Auth) Ticket - NTW 1. Locate KDC for domain by DNS lookup for AD service Windows 2k+ Active Directory 3. Group membership expanded by KDC, added to TGT auth data 4. Send TGS request for session ticket to workstation Key Distribution Center (KDC) Windows 2k+ Domain Controller

17 Figures from Nat Sakimura, OpenID Foundation

18 Svensk E-leg - Arkitektur och avtalsstruktur Leverantörer av eid-tjänst - Avtal Utfärdare e- legitimation Utfärdare av svensk e- legitimation Utfärdare e- legitimation - Fullmakt - Avtal - Regelverk - Tillitsramverk - Tekniskt ramverk - Avtalsrelation E-legitimationsnämnden E-legitimationsnämnden - Fullmakt Tillhandahållare av e-tjänster e-tjänst e-tjänst FEDERATION BASSTRUKTUR

19 Why Security is Harder than it Looks All software has bugs Under normal usage conditions, a 99,99% bug-free program will rarely cause problems Error-free Normal use Buggy A 99,99% security-bug-free program can be exploited by ensuring the 0,01% instance is always encountered Abnormal use Error-free This converts the 0,01% failure to 100% failure Buggy

20 Why security is harder (cont.) Users have come to expect buggy software Correctness is not a selling point Expensive and time-consuming software validation (evaluation) is hard to justify Time to Market Economics Solution: Confine security functionality into a small subset of functions, the trusted computing base (TCB) In theory the TCB is small and relatively easy to analyse In practice some vendors end up stuffing too much into the TCB making it a UTCB ( Untrusted TCB ) Users buy the product anyway (see above)

21 Frågor?