com puter security part four last tim e
play

Com puter Security Part Four Last tim e Cryptography - PDF document

Com puter Security Part Four Last tim e Cryptography Authentication Threats Key Management KDC Policy Symmetric keys Specification Asymmetric keys PKI Design Security Protocols Kerberos


  1. Com puter Security – Part Four

  2. Last tim e • Cryptography • Authentication Threats • Key Management – KDC Policy – Symmetric keys Specification – Asymmetric keys – PKI Design • Security Protocols – Kerberos Implementation – (SSL/ TLS) Operation and Maintenance

  3. Today’s lecture • More mechanisms – Firewalls – Intrusion Detection Systems • Design principles • What goes wrong? • What to do, how to do it, and when are you done? • The future • Also: Confused Deputy Problem (right after the break)

  4. Firew alls - I ntroduction Gatekeeper Information function system Computing resources Opponent (processor, memory, I/O) Data Access Human Processes channel Software Software Internal security controls • A “gatekeeper” • Mechanism that removes unwanted traffic • … but usually also limits wanted traffic

  5. Firew alls – Design purposes 1. The firewall should always be up when the network is up 2. The firewall should always be small and simplistic to be easily verified 3. All external traffic must pass through the firewall 4. Only permitted traffic (according to the policy) should pass through the firewall 5. The firewall itself must not be vulnerable 6. It should provide a minimal amount of services, only the required ones

  6. Firew alls - Default behavior • Two versions: – Everything not explicitly forbidden is allowed – Everything not explicitly allowed is forbidden

  7. Firew alls Limitations Strengths 1. Single point of defense 1. Only protecting against – Simplifies attacks that pass 2. A good place for through the firewall surveillance 2. Only useful against 1. Logs and alarms external threats 3. VPN - Virtual Private 3. Can not protect against Network “malicious programs” (4. Platform for other and viruses mechanisms, e.g., network surveillance and address translation)

  8. Firew alls - Configuration • The proxy is either in the firewall or in a DMZ (DeMilitarized Zone) WAN LAN Firewall DMZ

  9. I ntrusion Detection System s - I DS • Firewalls are not enough – All traffic does not go through the firewall – Does not protect against threats from the inside – Might be vulnerable themselves – Cannot protect against tunneled attacks • IDS analyzes the behavior and patterns within the system

  10. I DS – W hat do they do? • Looking for signs of – Trespassing – Misuse of resources • Analyzes information collected from many different places • Assisted by vulnerability assessment systems – Look for errors in the system and configuration that can pose a threat to security

  11. I DS – Possible Services • Surveillance and analysis of users and system • Control of the system configuration and its weaknesses • Integrity control of critical files and (sub)system • Pattern detection matching known attacks • Statistical analysis to find abnormalities in usage • Log auditing to detect policy violations • Automatic patch installation • Traps for attackers (honey pots)

  12. I DS - Methods • Offline: – Passive • Configuration control (passwords etc.) – Active • Simulate known attacks and evaluate the response of the system – Periodic controls • Online: – Passive – Reactive

  13. I DS - Lim itations • Hard to tune – What is abnormal and what is normal – False positives vs. false negatives • Alarm at the right moments • Is anyone listening to the alarms? • Diagnosis – what to do? • Static (rule based) or AI?

  14. 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

  15. Design principles ( 2 ) 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 (not identity) of the subject should control the assignment of rights • Rights should be removed when not needed any more • Example: – Mail server and file access

  16. Design principles ( 3 ) 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. Netw ork based threats • Interaction means exposure • Best possible network security is to stay offline • Browsers – Many users use the Internet only through browsers, and cannot tell the difference between them – A lot of software has moved inside the browser – There are several “major” browsers, and they all have different vulnerabilities and different bugs. – Compared to “real” systems, web sites are often managed and developed by inexperienced staff.

  18. Netw ork based threats ( 2 ) • OS – Many services, and many are activated by default • Examples of LAN based attacks – Password sniffing – NFS • Examples of WAN based attacks – SYN Flooding – Smurfing – DDOS – Spam and address spoofing – Routing-attacks – Combined attacks

  19. Defense against netw ork based attacks • Keeping the system / staff up to date – Most attacks and problems are not new • Configuration Management – Very important that it is carried out correctly • Cryptography – IPsec – VPN • Firewalls

  20. Other • Sandbox – Limited area with restricted rights (e.g. Java, Browsers to some extent) • Proof-carrying code – Code must contain evidence that it is correct • Object Request Brokers – Component responsible for the communication between object – Controls access between different security domains

  21. Assurance • Assurance is the basis of trust – Development methodologies – Formal methods for design analysis – Testing • Higher level: – What are you allowed to do? • Rules and politics – How do you organize the work? • Methodology – When do you know that you are done? • Evaluation and assurance

  22. W hat? – Cryptography • SigInt – Signal Intelligence – Echelon • USA, GB, Canada, Australia and New Zeeland – Important • The development of cryptography has always been opposed • Key escrow – Escrowed Encryption Standard (EES)

  23. W hat? – Personal I ntegrity • Protect personal information from unsuitable use • Difference between Europe and the US – Europe: rights concerning contents and spread – US: self regulating • Value of the data • We will always be under surveillance

  24. W hat? - Evidence • Hard to design systems that produce evidence • I court: – Competency and experts • Digital Signatures • Risk dumping – Worse for clients – Incentive to build secure system decreases

  25. How ? – Lead Security Projects • Core – What should be protected and how? • Revenue, risk, and reward • Risk management – The responsibility of the company management – Make sure everyone does their part and understand each other's functions • The value of staff

  26. How ? – Methodology • Lots to learn from Software Development • Top-down – Waterfall model • Iterative design – Spiral model – Evolutionary development (Extreme programming) • To consider: – Reduce TCB – Keep track of the competency of employees – Error masking is not good for the security margin – Include security documents among the other development documents – Security must be built in from the start

  27. How ? – Deal w ith Changes • Reasons – Fix a bug • Have a plan (find, patch, distribute, PR) – Develop / enhance the system – Changed environment – Changed organization • Enforced technologies

  28. How ? - Econom y • Network economy – “They did not want a secure system, only what security they could get for $10,000” – “We will release it on Wednesday and fix everything to version 3” – No use of standards – Vendor lock-in – No altruistic motives – “ money talks ”

  29. W hen? - Assurance • Assurance is a process • Test with regard to security • Formal methods – Useful, but hard and the proof can have flaws • Who controls the testers? – Error injection, history of tester • Difference between implementor / team • Standards • Thorough testing secures complex systems • Easier to find some bug than a specific bug (ref. Birthday attack)

  30. W hen? - Evaluation • Prove to others that the system works • Often a lesser product is bought instead • The usability is often secondary • There are standardized testing methodologies

  31. W hen? – W ays forw ard • Open source – Pro: Many watchers – a lot is found – Con: Large and complex software is rarely examined, functionality bloat – Open questions • Does everyone reveal what they find? • How much time has actually been spent on testing? • What should you do when you find a bug?

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend