Last time Kryptering Autenticering Nyckelhantering KDC Symmetriska nycklar Asymmetriska nycklar PKI Säkerhetsprotokoll Kerberos SSL Threats Policy Specification Design Implementation Operation and Maintenance 17/10-06 Distributed systems - Jonny Pettersson, UmU 1 Security in the Course Lectures Introduction Threat analysis Introduction to access control matrix Security policies Cryptography Authentication Key management Design principles Access control mechanisms Assurance The future Literature 17/10-06 Distributed systems - Jonny Pettersson, UmU 2 Dagens föreläsning Designprinciper Accesskontroll Access control lists Capabilities Brandväggar IDS Assurance försäkran Vad får man göra? Hur organiserar man arbetet? När vet man att man är klar? Vad går fel Framtiden 17/10-06 Distributed systems - Jonny Pettersson, UmU 3 1
Design principles Specific design principles underlie the design and implementation of security mechanisms Build on simplicity Makes it easier to understand Less can go wrong Reduces the potential for inconsistencies and restriction Minimizes the interaction of system component Minimizes the power of an entity 17/10-06 Distributed systems - Jonny Pettersson, UmU 4 Principle of Least Privilege Def. The principle of least privilege states that a subject should be given only those privileges it needs in order to complete its task. The function of the subject should control the assignment of rights Rights should be removed when not needed any more Example: Mail server and file access 17/10-06 Distributed systems - Jonny Pettersson, UmU 5 Principle of Fail-Safe Defaults Def. The principle of fail-safe defaults states that, unless a subject is given explicit access to an object, it should be denied access to that object. The default access should be none In case of failure, changes should be undone Example: Mail server and the spool directory 17/10-06 Distributed systems - Jonny Pettersson, UmU 6 2
Principle of Economy of Mechanism Def. The principle of economy of mechanism states that security mechanisms should be as simple as possible. Simple design and implementation fewer errors Interfaces to other modules are suspect Implicit assumptions about input or output parameters or the current system state Example: Replace the finger server 17/10-06 Distributed systems - Jonny Pettersson, UmU 7 Principle of Complete Mediation Def. The principle of complete mediation requires that all accesses to objects be checked to ensure that they are allowed. Restricts the caching of information When a subject attempts to read a object First attempt: Allowed? Second attempt: a new check should be done Example: Unix and file descriptors 17/10-06 Distributed systems - Jonny Pettersson, UmU 8 Principle of Open Design Def. The principle of open design states that the security of a mechanism should not depend on the secrecy of its design or implementation. No security through obscurity ( Dumpster-diving ) Especially true of cryptographic software and systems Issues of proprietary software and trade secrets complicate Example: DVD and the Content Scrambling System 17/10-06 Distributed systems - Jonny Pettersson, UmU 9 3
Principle of Separation of Privilege Def. The principle of separation of privilege states that a system should not grant permission based on a single condition. More than one condition should be met Provides a fine-grained control over a resource Provides additional assurance that the access is authorized Example: Berkley-based versions of UNIX and root 17/10-06 Distributed systems - Jonny Pettersson, UmU 10 Principle of Least Common Mechanism Def. The principle of least common mechanism states that mechanisms used to access resources should not be shared. Limits sharing Sharing resources can provide a information channel Example: E-commerce sharing the Internet 17/10-06 Distributed systems - Jonny Pettersson, UmU 11 Principle of Psychological Acceptability Def. The principle of psychological acceptability states that security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present. Configuring and executing a program should be as easy and as intuitive as possible Output should be clear, direct, and useful The security burden must be both minimal and reasonable Example: Password and error messages 17/10-06 Distributed systems - Jonny Pettersson, UmU 12 4
Accesskontroll Inledning Accesskontroll i operativsystem Access control lists Capabilities Lite annat Brandväggar IDS 17/10-06 Distributed systems - Jonny Pettersson, UmU 13 Accesskontroll Dess funktion är att kontrollera vilka principals som har access till vilka resurser i systemet Accesskontroll finns på många nivåer Ju högre upp, ju mer komplexa, ju mindre tillförlitliga De flesta bedrägerier sker av anställda Upptäcker buggar eller gör otillåtna saker Ska anpassas till skyddsmålen enligt policyn 17/10-06 Distributed systems - Jonny Pettersson, UmU 14 OS accesskontroll OS autenticierar principals och hanterar deras access till resurser Matris för rättigheter, filer och användare Bättre med accesstriplar Användare, program, fil Görs på två huvudsätt Grupper och roller Matriser via kolumner (Access Control Lists) eller rader (Capabilities, certifikat) 17/10-06 Distributed systems - Jonny Pettersson, UmU 15 5
Discretionary Access Control Foo Bar Sam RWX RWX Alice --X --X Bob R-X R-- Capabilities ACL 17/10-06 Distributed systems - Jonny Pettersson, UmU 16 Access Control Lists Dataorienterade Fördelar Enkla att implementera Nackdelar Funkar inte bra med många användare och många ändringar Passar ej för deligering av rättigheter Ej effektiva för run-time kontroller Svårt hitta alla filer en användare har access till 17/10-06 Distributed systems - Jonny Pettersson, UmU 17 Implementationsskillnader hos ACL Frågor Vilka subjekt kan modifiera ett objekts ACL? Om det finns en previligerad användare, gäller ACL för den? Stöds grupper eller wildcards? Hur hanteras motsägelser? Om det finns en default inställning, modifierar ACL den eller gäller den bara om subjektet ej finns i ACL n? Hur återkallas rättigheter? 17/10-06 Distributed systems - Jonny Pettersson, UmU 18 6
ACL - Exempel Unix rwx för owner, group, world root kan göra allt (vem kontrollerar root?) ACL innehåller endast användare ej program suid finns i stället suid root i programmet programmet får göra vad som helst De flesta programmerarna har inte tillräcklig koll 17/10-06 Distributed systems - Jonny Pettersson, UmU 19 Capabilities Spara accesskontrollmatrisen radvis Motsats mot ACLs styrkor och svagheter Run-time checking lättare Delegering lättare Ändra en fils status svårare. Vilka har access? Comeback public key certificates Windows 2000 Kombinerar ACL med capabilities 17/10-06 Distributed systems - Jonny Pettersson, UmU 20 Granularitet Ett praktiskt problem för alla varianter av accesskontroll En databas(fil) innehåller många data, men access kan endast ges till hela filen Ett annat problem är single sign-on Säkerheten i bästa systemet kan lätt degraderas till det som är sämst 17/10-06 Distributed systems - Jonny Pettersson, UmU 21 7
Annat Sandlåda Ett avgränsat område med begränsade rättigheter (ex. Java) Proof-carrying code Kod måste ha med sig bevis på att den är korrekt Object Request Brokers Komponent som hanterar kommunikation mellan objekt Kontrollerar anrop mellan olika skyddsdomäner 17/10-06 Distributed systems - Jonny Pettersson, UmU 22 Brandväggar - Vad är det? Information system Gatekeeper function Computing resources (processor, memory, I/O) Data Processes Software Internal security controls Access channel Opponent Human Software En gatekeeper Ett skydd mot ej önskad trafik men också en begränsning för önskad trafik 17/10-06 Distributed systems - Jonny Pettersson, UmU 23 Brandväggar - Nivå? En brandvägg filtrerar på något/några/alla protokollnivåer På transportnivån Packetfiltrerande router På applikationsnivån Proxy server För utgående trafik Relay host För inkommande trafik Oftast kallar man båda typerna för proxy Applikation TCP/UDP IP Ethernet fråga x svar y src port x dest port y src IP x dest IP y protocol z src addr xxxx dest addr yyyy 17/10-06 Distributed systems - Jonny Pettersson, UmU 24 8
Brandväggar - Designmål 1. Brandväggen ska alltid vara uppe när nätverket är uppe 2. Brandväggen ska vara liten och enkel för rigorös kontroll 3. All trafik mellan in och ut måste passera brandväggen 4. Endast godkänd trafik ska släppas igenom - bestäms av säkerhetspolicyn 5. Brandväggen måste själv vara immun 6. Minimalt med tjänster, endast de nödvändiga 17/10-06 Distributed systems - Jonny Pettersson, UmU 25 Brandväggar - Default behavior Två skolor: Allt som inte uttryckligen är förbjudet är tillåtet Allt som inte uttryckligen är tillåtet är förbjudet 17/10-06 Distributed systems - Jonny Pettersson, UmU 26 Brandväggar - Olika tekniker För all trafik in och ut Servicekontroll Riktningskontroll Accesskontroll Uppförande- (behavior) kontroll Bastion Host En maskin som som innehåller en eller flera proxies En kritisk punkt i försvaret 17/10-06 Distributed systems - Jonny Pettersson, UmU 27 9
Brandväggar Möjligheter 1. Single point of defense - Förenklar 2. Ett bra övervakningsställe - Loggar och larm 3. VPN - Virtual Private Network (4. Plattform för annat, tex nätverksövervakning, adressöversättning) Begränsningar 1. Kan endast skydda mot attacker som går genom brandväggen 2. Skyddar endast mot externa hot 3. Kan ej skydda mot malicious programs och virusinfekterade filer 17/10-06 Distributed systems - Jonny Pettersson, UmU 28 Brandväggar - Konfigurering Proxyn sitter antingen i brandväggen eller i en DMZ (DeMilitarized Zone) Yttre nät Skyddat nät Brandvägg DMZ 17/10-06 Distributed systems - Jonny Pettersson, UmU 29 Brandväggar - Konfigurering (2) Internet Packetfiltering router Webb servers Application servers Data First firewall layer Second firewall layer with load balancing Third firewall layer (e) A secure firewall system according to Wineasy Backend system 17/10-06 Distributed systems - Jonny Pettersson, UmU 30 10
De vanligaste attackerna Juni 2000 (Andersson) 1. Stack overflow i BIND 2. CGI program i web-server 3. Stack overflow i RPC 4. Bug i MS IIS 5. Bug i sendmail 6. Stack overflow i Sun Solaris OS 7. Attack mot NFS 8. Gissa användare och lösenord 9. IMAP och POP 10. Svag autenticering i SNMP 17/10-06 Distributed systems - Jonny Pettersson, UmU 31 Förändrade kompetenser Användarna Systemadministratörerna Outsourcing 17/10-06 Distributed systems - Jonny Pettersson, UmU 32 Hot i nätverk OS Många tjänster och många tjänster default på Exempel på attacker i LAN Sniffa lösenord NFS Exempel på attacker i Internet SYN Flooding Smurfing DDOS Spam och adressförfalskning Kombinerade attacker Routing-attacker 17/10-06 Distributed systems - Jonny Pettersson, UmU 33 11
Försvar mot nätattacker Configuration Management Väldigt viktigt det görs korrekt Kryptering IPsec VPN Brandväggar 17/10-06 Distributed systems - Jonny Pettersson, UmU 34 Intrusion Detection Systems - IDS Det räcker inte med brandväggar All trafik går inte genom brandväggen Skyddar ej från hot inifrån Är ej immuna mot attacker Kan ej skydda mot tunnlade attacker IDS analyserar beteenden och mönster inom datorsystemet 17/10-06 Distributed systems - Jonny Pettersson, UmU 35 IDS - Vad de gör? Letar efter tecken på intrång missbruk av resurser Görs genom att analysera information som samlas in från många ställen Assisteras av vulnerability assessment systems kollar efter fel i system och konfigureringsfel som kan utgöra säkerhetsrisker 17/10-06 Distributed systems - Jonny Pettersson, UmU 36 12
IDS - Möjliga tjänster Övervakning och analys av användare och system Kontroll av systemets konfiguration och dess svagheter Integritetskontroll av kritiska filer och system Kollar efter mönster som liknar kända attacker Statistisk analys för att hitta onormala aktiviteter Kontrollerar loggar för att titta efter tecken på brott mot säkerhetspolicyn Automatisk installation av patchar Fällor för angripare 17/10-06 Distributed systems - Jonny Pettersson, UmU 37 IDS - Metoder Passiva Kontroll av konfiguration, passwords o dyl Aktiva Kopiera kända attacker och kolla systemets respons Regelbundna kontroller Security baseline Differentialanalys 17/10-06 Distributed systems - Jonny Pettersson, UmU 38 IDS - Begränsningar Svåra att ställa in Vad är ett onormalt beteende och vad är ett normalt False positives Alarm i rätt tid Finns det någon som lyssnar efter alarm Diagnos? - Vad ska man göra? Statiska (regelstyrda) eller AI 17/10-06 Distributed systems - Jonny Pettersson, UmU 39 13
Assurance - Försäkran Vad får man göra? Lagar och politik Hur organiserar man arbetet? Metodologi När vet man att man är klar? Evaluering och försäkran 17/10-06 Distributed systems - Jonny Pettersson, UmU 40 Vad? - Kryptografi SigInt Signal Intelligence Echelon USA, Storbritanien, Canada, Australien och Nya Zeeland Viktigt Utvecklingen av kryptering har alltid motarbetats Key escrow 17/10-06 Distributed systems - Jonny Pettersson, UmU 41 Vad? Kryptografi (2) Autenticering viktigare än konfidentialitet Skillnad på militär och polisiär användning Krypto inte bra för echelon Displacement activity Risken att utgöra måltavla 17/10-06 Distributed systems - Jonny Pettersson, UmU 42 14
Vad? - Copyright Efter krypto anonymitet, censur, copyright Nationella skillnader 17/10-06 Distributed systems - Jonny Pettersson, UmU 43 Vad? Personlig integritet Skydda personlig information från olämplig användning Skillnad mellan Europa och USA Europa: rättigheter kring innehåll och spridning USA: självreglerande Värdet av datat Vi kommer alltid vara övervakade Sammanställning av data 17/10-06 Distributed systems - Jonny Pettersson, UmU 44 Vad? - Bevis Svårt designa system som producerar bevis I rättsfall Kompetens och experter Elektroniska signaturer Risk dumping Sämre för kunder Incitament för att bygga säkra system minskar 17/10-06 Distributed systems - Jonny Pettersson, UmU 45 15
Vad? - Annat Social uteslutning och diskriminering Klasstillhörlighet Publika terminaler nya attacker Skyddsmekanismer kan vara diskriminerande Utbildningsnivå Alla tänkta användare ska kunna använda systemet Demokratiska val 17/10-06 Distributed systems - Jonny Pettersson, UmU 46 Hur? Leda säkerhetsprojekt Kärnan Vad ska skyddas och hur? Vinst, belöning och risk Risk management Ledningens uppgift Få de inblandade att göra sitt bästa och förstå varandra och deras roller Personalens betydelse 17/10-06 Distributed systems - Jonny Pettersson, UmU 47 Hur? Leda säkerhetsprojekt (2) Skillnad mellan risk och osäkerhet Hög tolerans för kaos undergräver kontroll Samband mellan kvalité och säkerhet Tillförlitlighet är en viktig tillgång Lösa fel problem Pengar till interna kontroller Moraliska risker Dumpa risken på tredje part sänker moralen De som skriver är inte de som tar risken 17/10-06 Distributed systems - Jonny Pettersson, UmU 48 16
Hur? - Metodologi Mycket att lära från mjukvaruutveckling Top-down Vattenfallsmodellen Iterativ design Spiralmodellen Evolutionär utveckling 17/10-06 Distributed systems - Jonny Pettersson, UmU 49 Hur? Metodologi (2) Att tänka på Minska TCB Viktigt ha koll på anställdas kompetens Felmaskering inte så bra för säkerhetsmarginalen Inkludera säkerhetsdokumenten bland de övriga utvecklingsdokumenten Säkerhet måste byggas in från början 17/10-06 Distributed systems - Jonny Pettersson, UmU 50 Hur? Security Requirement Engineering Security Requirement Engineering Hotanalys Säkerhetspolicy Svårast och viktigast Implementation av säkerhetspolicyn Risk management måste forsätta efter att systemet är driftsatt Använd experter parallellt 17/10-06 Distributed systems - Jonny Pettersson, UmU 51 17
Hur? - Implementation av policyn Val av säkerhetsprodukter/verktyg Test och verifikation av produkter Säkerhetshål kan finnas överallt Ett hål kan sänka hela produkten Hittas ej via beta-testning Ingagarantier Kräverexperter 17/10-06 Distributed systems - Jonny Pettersson, UmU 52 Hur? - Implementation av policyn (2) Rätt åtgärd på rätt ställe Överlappande säkerhetssystem Flera lager av åtgärder Säkerhet som en kedja 17/10-06 Distributed systems - Jonny Pettersson, UmU 53 Hur? Hantering av förändringar Anledningar Fixa bug Ha en plan (Hitta, fixa, distribuera, PR) Utveckla/förbättra systemet Förändrad omgivning The tragedy of the common Förändrad organisation Påtvingade teknologier 17/10-06 Distributed systems - Jonny Pettersson, UmU 54 18
Hur? - Ekonomi Nätverksekonomi Vi släpper det på onsdag och fixar allt till version 3 Använd inte standards, utan fösök låsa in kunderna Inga altruistiska motiv money talks 17/10-06 Distributed systems - Jonny Pettersson, UmU 55 När? - Assurance Försäkran kan baseras på Utvecklingsprocesser Vilka som varit med Tekniska aspekter Erfarenhet... Vad kan man behöva försäkran för? Funktionalitet Styrka hos mekanismer Implementation Användbarhet 17/10-06 Distributed systems - Jonny Pettersson, UmU 56 När? - Försäkran Försäkran är en process Testa med avseende på säkerhet Formella metoder Användbart, men bevis kan ha brister Vem kollar testarna? Felinjektion, historia hos testaren Skillnad mellan implementerare/team Standarder Lång testning säkrar komplexa system Lättare hitta något fel än att hitta och åtgärda just det felet 17/10-06 Distributed systems - Jonny Pettersson, UmU 57 19
När? - Evaluering Bevisa för andra att systemet fungerar Ofta köps känd sämre produkt Ofta glöms användbarhet bort Olika standardiserade testförfaranden finns 17/10-06 Distributed systems - Jonny Pettersson, UmU 58 När? Vägar framåt Måste ta hänsyn till användbarhet Måste anta att människor alltid är slarviga, oftast inkompetenta och ibland oärliga Nätverksekonomin gäller, nya versioner kommer Viktigt med hostile review Semi-öppen design 17/10-06 Distributed systems - Jonny Pettersson, UmU 59 När? Vägar framåt (2) Öppen källkod För: många tittar mycket hittas Emot: om mjukvara blir stor och komplex tittar få på den, samt ny funktionalitet adderas för fort Frågetecken Berättar alla vad de hittar? Hur mycket tid har lagts ned på test egentligen? Hur ska man göra när man hittar en bug? 17/10-06 Distributed systems - Jonny Pettersson, UmU 60 20
Vad går fel Stora OS Många buggar och många användare Många buggar hittas Mål för attack Få ett vanligt konto bli sysadmin Många buggar tillåter user root Smashing the Stack Kolla indata! 17/10-06 Distributed systems - Jonny Pettersson, UmU 61 Vad går fel (2) Race conditions En operation sker i två eller flera steg och någon annan hinner in emellan Service denial Ex. syn flooding Fel i användargränssnitt Trojanska hästar Eget program med känt namn, exv. ls 17/10-06 Distributed systems - Jonny Pettersson, UmU 62 Varför så många fel? Testare utnyttjar istället för att rapportera Kernel bloat mycket man ska lita på Program körs som root i onödan men, om inte root kanske de struntar i ordentlig säkring av känsliga delar 17/10-06 Distributed systems - Jonny Pettersson, UmU 63 21
Hjälpmedel Verktyg mot stack-overflow Program ska bara ha så mycket rättigheter som behövs The principle of least privilege Default ska vara säkert 17/10-06 Distributed systems - Jonny Pettersson, UmU 64 Environmental creep Se upp när omgivningen och grunden för antaganden förändras (ex. Internet) Användare Förr: Trovärdiga, men ibland inkompetenta Nu: Inkompetenta, men ibland kompetenta och farliga 17/10-06 Distributed systems - Jonny Pettersson, UmU 65 Framtiden Ökad komplexitet leder till ökade risker Lära sig av misstag? Buffer-overflow (60- ) Krypteringsalgoritmer Patchar Nya versioner Garantier? Lagar - Brott och straff Security Engineering Outsourcing 17/10-06 Distributed systems - Jonny Pettersson, UmU 66 22
Säkerhet som process - Principer Dela upp systemet i delar Säkra svagaste länken Kanalisera systemet Säkerhet i flera lager Fail sercurely Dölj vad som används Keep it simple Involvera användarna Försäkra att det fungerar (Svårt!) Ifrågasätt ständigt 17/10-06 Distributed systems - Jonny Pettersson, UmU 67 Säkerhet som process - Flöde Protection Detection Ständig uppmärksamhet Watch the watchers Reaction Någon form av reaktion Recover Counterattack Analysera, diagnosticera, implementera 17/10-06 Distributed systems - Jonny Pettersson, UmU 68 Säkerhet som process Det kommer alltid vara osäkert!!! Det går inte att göra det helt säkert Viktigt välja rätt skydd Vktigt att hela tiden övervaka och uppdatera Risk management 17/10-06 Distributed systems - Jonny Pettersson, UmU 69 23
Sammanfattning Designprinciper Accesskontroll Access control lists Capabilities Brandväggar IDS Assurance försäkran Vad får man göra? Hur organiserar man arbetet? När vet man att man är klar? Vad går fel Framtiden 17/10-06 Distributed systems - Jonny Pettersson, UmU 70 Nästa gång Repetition: Tentagenomgång 17/10-06 Distributed systems - Jonny Pettersson, UmU 71 24