1. Vulnerability Analysis

2. Formal verification Formally (mathematically) prove certain characteristics Proves the absence of flaws in a program or design but not in a system Penetration testing Attempt to violate specific constrains stated in a policy Cannot prove correctness but absence of a vulnerability Review 2

3. Penetration Testing Goals Prove the existence/absence of a previously defined flaw Find vulnerabilities under given restrictions (time, resources,...) Layering of tests External attacker with no knowledge of the system External attacker with knowledge of the system Internal attacker with knowledge of the system 3

4. Penetration Testing Procedure Information gathering Find problem areas in the specification Flaw hypothesis Derive possible flaws from the information gathered Flaw testing Verify the possible flaws (exploiting, testing) – but no harming! Flaw generalization Generalize the obtained insights Flaw elimination proposal Flaws need to be fixed but sometimes this takes time and than the tester can suggest ways to prevent the exploit 4

5. Vulnerability Scanners Automated tools to test if the network or host is vulnerable to known attacks Run in batch mode against the system Process A set of system attributes are sampled and stored The results are compared to a reference set and the deviation derived 5

6. Network Based Analysis Probing the system actively by Looking for weaknesses Derive information from system responses Two different techniques Testing by exploit – really doing the attack Interference Methods – monitoring the system for vulnerable applications 6

7. Host Based Analysis Assessing system data sources (file contents, configuration setting, status information) to determine vulnerabilities Passive assessment where the tool has legitimated access which mostly involves privilege escalation attacks Targets are password files, SUID, access permissions, anonymous FTP... 7

8. Advantage/Disadvantage Helping to document the security state of a system Regular application can spot system changes which could lead to problems A way to double-check any changes made to the system Host based are tightly bound to the environment Network based can harm the system and are more prone to false alarms Can misguide a running IDS system May violate legal prescriptions (privacy, others sphere of influence...) 8 + -

9. Outline 1.Vulnerability Analysis 2.Security Strategies 3.Attack Trees 9

10. Security Strategies 10 Least Privilege Defense in Depth Diversity of Defense Choke Point Weakest Link Fail-Safe Stance Default Deny Default Permit Universal Participation Simplicity

11. Least Privilege (LP) Every user, process,.. should only have the privileges needed to solve their tasks. Problems Difficult to achieve as an ”afterthought” Which privileges should a subject have? 11

12. Defense in Depth Do not let the security of the system stand and fall with one mechanism Total security can never be achieved, but it can be made good enough so that intrusion attempts are: too risky. too costly. 12

13. Diversity of Defense Use security systems from different suppliers Let different persons configure the systems Problems Flavors of UNIX Drawback High cost 13

14. Choke Point Force the attacker to use one channel that can be monitored and controlled Example Firewall N.B. No alternative channels may be used. 14

15. Weakest Link Try to find all the weak points in the system eliminate them monitor them Problem How do you find all the weak points in a system? There will always be a weakest point 15

16. Fail-Safe Stance A system should fail in a secure manner if a system fails it should not be easier to penetrate the system Flavors Default deny stance define what is permitted and disallow everything else Default permit stance define what is disallowed and permit everything else 16

17. Universal Participation All personnel needs to participate in order to achieve security. Flavors Voluntary explain the benefits of a secure system/organization educate the staff Mandatory e.g. force the users to change passwords every week 17

18. Simplicity You can’t know if a system is safe if you don’t understand it. ”It is easier to secure an apartment than a whole block” 18

19. Summary The security of a system is, among other things, dependent on: How the system is constructed How the system is configured How the users behave 19

20. Questions ?