Presentation is loading. Please wait.

Presentation is loading. Please wait.

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-1 Chapter 20: Vulnerability Analysis Background Penetration Studies Example.

Similar presentations


Presentation on theme: "November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-1 Chapter 20: Vulnerability Analysis Background Penetration Studies Example."— Presentation transcript:

1 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-1 Chapter 20: Vulnerability Analysis Background Penetration Studies Example Vulnerabilities Classification Frameworks

2 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-2 DMZ http://en.wikipedia.org/wiki/Image:DMZ_n etwork_diagram_1_firewall.png

3 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-3 Definitions Vulnerability, security flaw: failure of security policies, procedures, and controls that allow a subject to commit an action that violates the security policy –Subject is called an attacker –Using the failure to violate the policy is exploiting the vulnerability or breaking in

4 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-4 Formal Verification Mathematically verifying that a system satisfies certain constraints Preconditions state assumptions about the system Postconditions are result of applying system operations to preconditions, inputs Required: postconditions satisfy constraints

5 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-5 Penetration Testing Testing to verify that a system satisfies certain constraints Hypothesis stating system characteristics, environment, and state relevant to vulnerability Result is compromised system state Apply tests to try to move system from state in hypothesis to compromised system state

6 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-6 Notes Penetration testing is a testing technique, not a verification technique –It can prove the presence of vulnerabilities, but not the absence of vulnerabilities For formal verification to prove absence, proof and preconditions must include all external factors –Realistically, formal verification proves absence of flaws within a particular program, design, or environment and not the absence of flaws in a computer system (think incorrect configurations, etc.)

7 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-7 Goals Attempt to violate specific constraints in security and/or integrity policy –Implies metric for determining success –Must be well-defined Example: subsystem designed to allow owner to require others to give password before accessing file (i.e., password protect files) –Goal: test this control –Metric: did testers get access either without a password or by gaining unauthorized access to a password?

8 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-8 Goals Find some number of vulnerabilities, or vulnerabilities within a period of time –If vulnerabilities categorized and studied, can draw conclusions about care taken in design, implementation, and operation –Otherwise, list helpful in closing holes but not more Example: vendor gets confidential documents, 30 days later publishes them on web –Goal: obtain access to such a file; you have 30 days –Alternate goal: gain access to files; no time limit (a Trojan horse would give access for over 30 days)

9 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-9 Layering of Tests 1.External attacker with no knowledge of system Locate system, learn enough to be able to access it 2.External attacker with access to system Can log in, or access network servers Often try to expand level of access 3.Internal attacker with access to system Testers are authorized users with restricted accounts (like ordinary users) Typical goal is to gain unauthorized privileges or information

10 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-10 Layering of Tests (con’t) Studies conducted from attacker’s point of view Environment is that in which attacker would function If information about a particular layer irrelevant, layer can be skipped –Example: penetration testing during design, development skips layer 1 –Example: penetration test on system with guest account usually skips layer 2

11 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-11 Methodology Usefulness of penetration study comes from documentation, conclusions –Indicates whether flaws are endemic or not –It does not come from success or failure of attempted penetration Degree of penetration’s success also a factor –In some situations, obtaining access to unprivileged account may be less successful than obtaining access to privileged account

12 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-12 Steps of a Pen Test Confirm target addresses Port scan Identify Web based remote management interfaces Scan for vulnerabilities

13 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-13 Steps of a Pen Test Vulnerability assessment Exploit vulnerabilities Password attack File and directory scanning Execute remote commands

14 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-14 Steps of a Pen Test Review system configuration Review firewall rules Drop firewall rules DNS scanning Analyze results

15 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-15 Flaw Hypothesis Methodology 1.Information gathering Become familiar with system’s functioning 2.Flaw hypothesis Draw on knowledge to hypothesize vulnerabilities 3.Flaw testing Test them out 4.Flaw generalization Generalize vulnerability to find others like it 5.(maybe) Flaw elimination Testers eliminate the flaw (usually not included)

16 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-16 Information Gathering Devise model of system and/or components –Look for discrepencies in components –Consider interfaces among components Need to know system well (or learn quickly!) –Design documents, manuals help Unclear specifications often misinterpreted, or interpreted differently by different people –Look at how system manages privileged users

17 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-17 Flaw Hypothesizing Examine policies, procedures –May be inconsistencies to exploit –May be consistent, but inconsistent with design or implementation –May not be followed Examine implementations –Use models of vulnerabilities to help locate potential problems –Use manuals; try exceeding limits and restrictions; try omitting steps in procedures

18 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-18 Flaw Hypothesizing (con’t) Identify structures, mechanisms controlling system –These are what attackers will use –Environment in which they work, and were built, may have introduced errors Throughout, draw on knowledge of other systems with similarities –Which means they may have similar vulnerabilities Result is list of possible flaws

19 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-19 Flaw Testing Figure out order to test potential flaws –Priority is function of goals Example: to find major design or implementation problems, focus on potential system critical flaws Example: to find vulnerability to outside attackers, focus on external access protocols and programs Figure out how to test potential flaws –Best way: demonstrate from the analysis Common when flaw arises from faulty spec, design, or operation –Otherwise, must try to exploit it

20 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-20 Flaw Testing (con’t) Design test to be least intrusive as possible –Must understand exactly why flaw might arise Procedure –Back up system –Verify system configured to allow exploit Take notes of requirements for detecting flaw –Verify existence of flaw May or may not require exploiting the flaw Make test as simple as possible, but success must be convincing –Must be able to repeat test successfully

21 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-21 Flaw Generalization As tests succeed, classes of flaws emerge –Example: programs read input into buffer on stack, leading to buffer overflow attack; others copy command line arguments into buffer on stack  these are vulnerable too Sometimes two different flaws may combine for devastating attack –Example: flaw 1 gives external attacker access to unprivileged account on system; second flaw allows any user on that system to gain full privileges  any external attacker can get full privileges

22 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-22 Flaw Elimination Usually not included as testers are not best folks to fix this –Designers and implementers are Requires understanding of context, details of flaw including environment, and possibly exploit –Design flaw uncovered during development can be corrected and parts of implementation redone Don’t need to know how exploit works –Design flaw uncovered at production site may not be corrected fast enough to prevent exploitation So need to know how exploit works

23 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-23 Penetrating a System Goal: gain access to system We know its network address and nothing else First step: scan network ports of system –Protocols on ports 79, 111, 512, 513, 514, and 540 are typically run on UNIX systems Assume UNIX system; SMTP agent probably sendmail –This program has had lots of security problems –Maybe system running one such version … Next step: connect to sendmail on port 25

24 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-24 Output of Network Scan ftp 21/tcp File Transfer telnet 23/tcp Telnet smtp 25/tcp Simple Mail Transfer finger 79/tcp Finger sunrpc 111/tcp SUN Remote Procedure Call exec 512/tcp remote process execution (rexecd) login 513/tcp remote login (rlogind) shell 514/tcp rlogin style exec (rshd) printer 515/tcp spooler (lpd) uucp 540/tcp uucpd nfs 2049/tcp networked file system xterm 6000/tcp x-windows server

25 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-25 Vulnerability Classification Describe flaws from differing perspectives –Exploit-oriented –Hardware, software, interface-oriented Goals vary; common ones are: –Specify, design, implement computer system without vulnerabilities –Analyze computer system to detect vulnerabilities –Address any vulnerabilities introduced during system operation –Detect attempted exploitations of vulnerabilities

26 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-26 Program Analysis (PA) Goal: develop techniques to find vulnerabilities Tried to break problem into smaller, more manageable pieces Developed general strategy, applied it to several OSes –Found previously unknown vulnerabilities

27 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-27 Genesis of Flaws Inadvertent (unintentional) flaws classified using RISOS categories; not shown above –If most inadvertent, better design/coding reviews needed –If most intentional, need to hire more trustworthy developers and do more security- related testing

28 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-28 Time of Flaws Development phase: all activities up to release of initial version of software Maintenance phase: all activities leading to changes in software performed under configuration control Operation phase: all activities involving patching and not under configuration control

29 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-29 Location of Flaw Focus effort on locations where most flaws occur, or where most serious flaws occur

30 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-30 Coding Faults Synchronization errors: improper serialization of operations, timing window between two operations creates flaw –Example: xterm flaw Condition validation errors: bounds not checked, access rights ignored, input not validated, authentication and identification fails –Example: fingerd flaw

31 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-31 Emergent Faults Configuration errors: program installed incorrectly –Example: tftp daemon installed so it can access any file; then anyone can copy any file Environmental faults: faults introduced by environment –Example: on some UNIX systems, any shell with “-” as first char of name is interactive, so find a setuid shell script, create a link to name “-gotcha”, run it, and you has a privileged interactive shell

32 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-32 Key Points Given large numbers of non-secure systems in use now, unrealistic to expect less vulnerable systems to replace them Penetration studies are effective tests of systems provided the test goals are known and tests are structured well Vulnerability classification schemes aid in flaw generalization and hypothesis

33 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-33 Chapter 21: Auditing Overview What is auditing? What does an audit system look like? How do you design an auditing system? Auditing mechanisms

34 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-34 What is Auditing? Logging –Recording events or statistics to provide information about system use and performance Auditing –Analysis of log records to present information about the system in a clear, understandable manner

35 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-35 Problems What do you log? –Hint: looking for violations of a policy, so record at least what will show such violations What do you audit? –Need not audit everything –Key: what is the policy involved?

36 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-36 Audit System Structure Logger –Records information, usually controlled by parameters Analyzer –Analyzes logged information looking for something Notifier –Reports results of analysis

37 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-37 Logger Type, quantity of information recorded controlled by system or program configuration parameters May be human readable or not –If not, usually viewing tools supplied –Space available, portability influence storage format

38 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-38 Analyzer Analyzes one or more logs –Logs may come from multiple systems, or a single system –May lead to changes in logging –May lead to a report of an event

39 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-39 Notifier Informs analyst, other entities of results of analysis May reconfigure logging and/or analysis on basis of results

40 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-40 Designing an Audit System Essential component of security mechanisms Goals determine what is logged –Idea: auditors want to detect violations of policy, which provides a set of constraints that the set of possible actions must satisfy –So, audit functions that may violate the constraints Constraint p i : action  condition

41 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-41 Implementation Issues Show non-security or find violations? –Former requires logging initial state as well as changes Defining violations –Does “write” include “append” and “create directory”? Multiple names for one object –Logging goes by object and not name –Representations can affect this (if you read raw disks, you’re reading files; can your auditing system determine which file?)

42 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-42 Log Sanitization U set of users, P policy defining set of information C(U) that U cannot see; log sanitized when all information in C(U) deleted from log Two types of P –C(U) can’t leave site People inside site are trusted and information not sensitive to them –C(U) can’t leave system People inside site not trusted or (more commonly) information sensitive to them Don’t log this sensitive information

43 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-43 Application Logging Applications logs made by applications –Applications control what is logged –Typically use high-level abstractions such as: su: bishop to root on /dev/ttyp0 –Does not include detailed, system call level information such as results, parameters, etc.

44 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-44 System Logging Log system events such as kernel actions –Typically use low-level events 3876 ktrace CALLexecve(0xbfbff0c0,0xbfbff5cc,0xbfbff5d8) 3876 ktrace NAMI"/usr/bin/su" 3876 ktrace NAMI"/usr/libexec/ld-elf.so.1" 3876 su RETxecve 0 3876 su CALL __sysctl(0xbfbff47c,0x2,0x2805c928,0xbfbff478,0,0) 3876 suRET__sysctl 0 3876 suCALLmmap(0,0x8000,0x3,0x1002,0xffffffff,0,0,0) 3876 su RETmmap 671473664/0x2805e000 3876 su CALLgeteuid 3876 su RET geteuid 0 –Does not include high-level abstractions such as loading libraries (as above)

45 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-45 Detection Must spot initial Land packet with source, destination addresses the same Logging requirement: –source port number, IP address –destination port number, IP address Auditing requirement: –If source port number = destination port number and source IP address = destination IP address, packet is part of a Land attack

46 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-46 Chapter 22: Intrusion Detection Principles Basics Models of Intrusion Detection Architecture of an IDS Organization Incident Response

47 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-47 Principles of Intrusion Detection Characteristics of systems not under attack –User, process actions conform to statistically predictable pattern –User, process actions do not include sequences of actions that subvert the security policy –Process actions correspond to a set of specifications describing what the processes are allowed to do Systems under attack do not meet at least one of these

48 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-48 Example Goal: insert a back door into a system –Intruder will modify system configuration file or program –Requires privilege; attacker enters system as an unprivileged user and must acquire privilege Nonprivileged user may not normally acquire privilege (violates #1) Attacker may break in using sequence of commands that violate security policy (violates #2) Attacker may cause program to act in ways that violate program’s specification

49 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-49 Basic Intrusion Detection Attack tool is automated script designed to violate a security policy Example: rootkit –Includes password sniffer –Designed to hide itself using Trojaned versions of various programs (ps, ls, find, netstat, etc.) –Adds back doors (login, telnetd, etc.) –Has tools to clean up log entries (zapper, etc.)

50 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-50 Detection Rootkit configuration files cause ls, du, etc. to hide information –ls lists all files in a directory Except those hidden by configuration file –dirdump (local program to list directory entries) lists them too Run both and compare counts If they differ, ls is doctored Other approaches possible

51 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-51 Key Point Rootkit does not alter kernel or file structures to conceal files, processes, and network connections –It alters the programs or system calls that interpret those structures –Find some entry point for interpretation that rootkit did not alter –The inconsistency is an anomaly (violates #1)

52 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-52 Goals of IDS Detect wide variety of intrusions –Previously known and unknown attacks –Suggests need to learn/adapt to new attacks or changes in behavior Detect intrusions in timely fashion –May need to be be real-time, especially when system responds to intrusion Problem: analyzing commands may impact response time of system –May suffice to report intrusion occurred a few minutes or hours ago

53 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-53 Goals of IDS Present analysis in simple, easy-to-understand format –Ideally a binary indicator –Usually more complex, allowing analyst to examine suspected attack –User interface critical, especially when monitoring many systems Be accurate –Minimize false positives, false negatives –Minimize time spent verifying attacks, looking for them

54 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-54 Models of Intrusion Detection Anomaly detection –What is usual, is known –What is unusual, is bad Misuse detection –What is bad, is known –What is not bad, is good Specification-based detection –What is good, is known –What is not good, is bad

55 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-55 Anomaly Detection Analyzes a set of characteristics of system, and compares their values with expected values; report when computed statistics do not match expected statistics –Threshold metrics –Statistical moments –Markov model

56 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-56 Threshold Metrics Counts number of events that occur –Between m and n events (inclusive) expected to occur –If number falls outside this range, anomalous Example –Windows: lock user out after k failed sequential login attempts. Range is (0, k–1). k or more failed logins deemed anomalous

57 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-57 Difficulties Appropriate threshold may depend on non- obvious factors –Typing skill of users –If keyboards are US keyboards, and most users are French, typing errors very common Dvorak vs. non-Dvorak within the US

58 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-58 Statistical Moments Analyzer computes standard deviation (first two moments), other measures of correlation (higher moments) –If measured values fall outside expected interval for particular moments, anomalous Potential problem –Profile may evolve over time; solution is to weigh data appropriately or alter rules to take changes into account

59 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-59 Misuse Modeling Determines whether a sequence of instructions being executed is known to violate the site security policy –Descriptions of known or potential exploits grouped into rule sets –IDS matches data against rule sets; on success, potential attack found Cannot detect attacks unknown to developers of rule sets –No rules to cover them

60 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-60 IDS Architecture Basically, a sophisticated audit system –Agent like logger; it gathers data for analysis –Director like analyzer; it analyzes data obtained from the agents according to its internal rules –Notifier obtains results from director, and takes some action May simply notify security officer May reconfigure agents, director to alter collection, analysis methods May activate response mechanism

61 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-61 Agents Obtains information and sends to director May put information into another form –Preprocessing of records to extract relevant parts May delete unneeded information Director may request agent send other information

62 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-62 Example IDS uses failed login attempts in its analysis Agent scans login log every 5 minutes, sends director for each new login attempt: –Time of failed login –Account name and entered password Director requests all records of login (failed or not) for particular user –Suspecting a brute-force cracking attempt

63 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-63 Host-Based Agent Obtain information from logs –May use many logs as sources –May be security-related or not –May be virtual logs if agent is part of the kernel Very non-portable Agent generates its information –Scans information needed by IDS, turns it into equivalent of log record –Typically, check policy; may be very complex

64 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-64 Network-Based Agents Detects network-oriented attacks –Denial of service attack introduced by flooding a network Monitor traffic for a large number of hosts Examine the contents of the traffic itself Agent must have same view of traffic as destination –TTL tricks, fragmentation may obscure this End-to-end encryption defeats content monitoring –Not traffic analysis, though

65 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-65 Network Issues Network architecture dictates agent placement –Ethernet or broadcast medium: one agent per subnet –Point-to-point medium: one agent per connection, or agent at distribution/routing point Focus is usually on intruders entering network –If few entry points, place network agents behind them –Does not help if inside attacks to be monitored

66 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-66 Aggregation of Information Agents produce information at multiple layers of abstraction –Application-monitoring agents provide one view (usually one line) of an event –System-monitoring agents provide a different view (usually many lines) of an event –Network-monitoring agents provide yet another view (involving many network packets) of an event

67 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-67 Example Jane logs in to perform system maintenance during the day She logs in at night to write reports One night she begins recompiling the kernel Agent #1 reports logins and logouts Agent #2 reports commands executed –Neither agent spots discrepancy –Director correlates log, spots it at once

68 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-68 Adaptive Directors Modify profiles, rule sets to adapt their analysis to changes in system –Usually use machine learning or planning to determine how to do this Example: use neural nets to analyze logs –Network adapted to users’ behavior over time –Used learning techniques to improve classification of events as anomalous Reduced number of false alarms

69 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-69 Notifier Accepts information from director Takes appropriate action –Notify system security officer –Respond to attack Often GUIs –Well-designed ones use visualization to convey information

70 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-70 Organization of an IDS Monitoring network traffic for intrusions –NSM system Combining host and network monitoring –DIDS Making the agents autonomous –AAFID system

71 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-71 Monitoring Networks: NSM Develops profile of expected usage of network, compares current usage Has 3-D matrix for data –Axes are source, destination, service –Each connection has unique connection ID –Contents are number of packets sent over that connection for a period of time, and sum of data –NSM generates expected connection data –Expected data masks data in matrix, and anything left over is reported as an anomaly

72 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-72 Signatures Analyst can write rule to look for specific occurrences in matrix –Repeated telnet connections lasting only as long as set-up indicates failed login attempt Analyst can write rules to match against network traffic –Used to look for excessive logins, attempt to communicate with non-existent host, single host communicating with 15 or more hosts

73 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-73 Other Graphical interface independent of the NSM matrix analyzer Detected many attacks –But false positives too Still in use in some places –Signatures have changed, of course Also demonstrated intrusion detection on network is feasible –Did no content analysis, so would work even with encrypted connections

74 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-74 Combining Sources: DIDS Neither network-based nor host-based monitoring sufficient to detect some attacks –Attacker tries to telnet into system several times using different account names: network-based IDS detects this, but not host-based monitor –Attacker tries to log into system using an account without password: host-based IDS detects this, but not network-based monitor DIDS uses agents on hosts being monitored, and a network monitor –DIDS director uses expert system to analyze data

75 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-75 Layers of Expert System Model 1.Log records 2.Events (relevant information from log entries) 3.Subject capturing all events associated with a user; NID assigned to this subject 4.Contextual information such as time, proximity to other events –Sequence of commands to show who is using the system –Series of failed logins follow

76 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-76 Incident Prevention Identify attack before it completes Prevent it from completing Jails useful for this –Attacker placed in a confined environment that looks like a full, unrestricted environment –Attacker may download files, but gets bogus ones –Can imitate a slow system, or an unreliable one –Useful to figure out what attacker wants –MLS systems provide natural jails

77 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-77 Intrusion Handling Restoring system to satisfy site security policy Six phases –Preparation for attack (before attack detected) –Identification of attack  Containment of attack (confinement)  Eradication of attack (stop attack) –Recovery from attack (restore system to secure state)  Follow-up to attack (analysis and other actions)  Discussed in what follows

78 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-78 Containment Phase Goal: limit access of attacker to system resources Two methods –Passive monitoring –Constraining access

79 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-79 Passive Monitoring Records attacker’s actions; does not interfere with attack –Idea is to find out what the attacker is after and/or methods the attacker is using Problem: attacked system is vulnerable throughout –Attacker can also attack other systems Example: type of operating system can be derived from settings of TCP and IP packets of incoming connections –Analyst draws conclusions about source of attack

80 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-80 Deception Deception Tool Kit –Creates false network interface –Can present any network configuration to attackers –When probed, can return wide range of vulnerabilities –Attacker wastes time attacking non-existent systems while analyst collects and analyzes attacks to determine goals and abilities of attacker –Experiments show deception is effective response to keep attackers from targeting real systems

81 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-81 Eradication Phase Usual approach: deny or remove access to system, or terminate processes involved in attack Use wrappers to implement access control –Example: wrap system calls On invocation, wrapper takes control of process Wrapper can log call, deny access, do intrusion detection Experiments focusing on intrusion detection used multiple wrappers to terminate suspicious processes –Example: network connections Wrapper around servers log, do access control on, incoming connections and control access to Web-based databases

82 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-82 Firewalls Mediate access to organization’s network –Also mediate access out to the Internet Example: Java applets filtered at firewall –Use proxy server to rewrite them Change “ ” to something else –Discard incoming web files with hex sequence CA FE BA BE All Java class files begin with this –Block all files with name ending in “.class” or “.zip” Lots of false positives

83 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-83 Intrusion Detection and Isolation Protocol Coordinates response to attacks Boundary controller is system that can block connection from entering perimeter –Typically firewalls or routers Neighbor is system directly connected IDIP domain is set of systems that can send messages to one another without messages passing through boundary controller

84 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-84 Counterattacking Use legal procedures –Collect chain of evidence so legal authorities can establish attack was real –Check with lawyers for this Rules of evidence very specific and detailed If you don’t follow them, expect case to be dropped Technical attack –Goal is to damage attacker seriously enough to stop current attack and deter future attacks

85 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-85 Consequences 1.May harm innocent party Attacker may have broken into source of attack or may be impersonating innocent party 2.May have side effects If counterattack is flooding, may block legitimate use of network 3.Antithetical to shared use of network Counterattack absorbs network resources and makes threats more immediate 4.May be legally actionable

86 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-86 Example: Counterworm Counterworm given signature of real worm –Counterworm spreads rapidly, deleting all occurrences of original worm Some issues –How can counterworm be set up to delete only targeted worm? –What if infected system is gathering worms for research? –How do originators of counterworm know it will not cause problems for any system? And are they legally liable if it does?

87 November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-87 Key Points Intrusion detection is a form of auditing Anomaly detection looks for unexpected events Misuse detection looks for what is known to be bad Specification-based detection looks for what is known not to be good Intrusion response requires careful thought and planning


Download ppt "November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #11-1 Chapter 20: Vulnerability Analysis Background Penetration Studies Example."

Similar presentations


Ads by Google