Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Users and Terminals Characterization, Identification and Monitoring On a Net Project Team Raz Kitzoni Aryhe Segal Eliad Barazi Mati Kochen 036297083 061667572 040152514 015937287 [email protected] [email protected] [email protected] [email protected] Revision Control Rev. 1.0 Detailed Description Paragraph Reference Original version Approved by Date 9.12.07 -2- Table of Contents 1. Introduction …………………………………………………………………………………………4 1.1. Introduction ……………………………………………………………………………………4 1.2. The Problem Domain ………………………………………………………………………….5 1.3. Stakeholders …………………………………………………………………………………...5 1.4. Software Context ……………………………………………………………………………...6 1.5. System Interfaces ……………………………………………………………………………...6 1.5.1. Hardware Interfaces …………………………………………………………………….6 1.5.2. Software Interfaces ……………………………………………………………………..6 1.5.3. Events …………………………………………………………………………………...7 2. Functional Requirements …………………………………………………………………………...8 2.1. Research Requirements ………………………………………………………………………..8 2.2. Implementation part …………………………………………………………………………..10 2.2.1. User Management Requirements ……………………………………………………...10 2.2.2. Profile Feature Requirements …………………………………………………………10 2.2.3. Identification and Monitoring Requirements ………………………………………….11 2.2.4. Configuration & Settings Requirements ………………………………………………11 2.2.5. Reports Requirements …………………………………………………………………12 3. Non-functional requirements ……………………………………………………………………...13 3.1. Performance constraints ………………………………………………………………………13 3.1.1. Speed …………………………………………………………………………………..13 3.1.2. Capacity ……………………………………………………………………………….13 3.1.3. Throughput …………………………………………………………………………….14 3.1.4. Reliability ……………………………………………………………………………...14 3.1.5. Safety & Security ……………………………………………………………………...14 3.1.6. Usability ……………………………………………………………………………….14 3.1.7. Availability ……………………………………………………………………………15 3.2. Platform constraints …………………………………………………………………………..15 3.3. Special restrictions & limitations ..……………………………………………………………15 4. Usage Scenarios …………………………………...………………………………………………16 4.1. User Profiles — the Actors ……………………………………………...……………………16 4.1.1. System Administrator …………………………………………………………………16 4.1.2. Domain expert …………………………………………………………………………16 4.1.3. WireShark ………………………………………………………………..……………16 4.2. Use-cases ……………………………………………………………………………..………17 4.2.1. Use case 1 & Sequence Diagram …..………………………………………………18 4.2.2. Use case 2 & Sequence Diagram ………………………..…………………………19 4.2.3. Use case 3 & Sequence Diagram ………………………………………..…………20 4.2.4. Use case 4 & Sequence Diagram …………………..………………………………22 4.2.5. Use case 5 & Sequence Diagram ………………………………………..…………24 4.3. Special usage considerations..….…………………………………………………………25 5. Appendices …………………………………………………………………...……………………26 5.1. Features ………………………………………………………………………………….……26 5.2. Algorithms ……………………………………………………………………………………27 5.3. Dictionary ………………………………………………………………………….…………29 5.4. WireShark ………………………………………………………………………….…………30 -3- 1 Introduction Deutsche Telekom is one of the world's leading telecommunications and information technology service providers and as such sets high international standards. Network security is the focal topic of a research and development agreement between Israel's BenGurion University (BGU) and the Technology and Platforms (T&P) central department of Deutsche Telekom AG. Today, enterprises which employs a large amount of employees on a wide spread net of terminals, find it hard to maintain a strict security codes in the organization. Even a layer of standard user authentication protection can't prevent neglect of a terminal by an employee which enables a malicious user to gain privilege of a valid enterprise user and issue malicious commands using these privileges. The UTC-IMON system is a security tool which extends the existing layer of standard user authentication protection, using network traffic observation to identify and monitor users and terminals. A need for such system arises by enterprises which need another layer of protection above standard user authentication in order to protect against masquerading attacks. Examples include remote code execution or simply approaching an unlocked workstation while the user is temporarily away. 1.1 Vision In world based on communication and computing, one of the main aspects is security. Today the standard user authentication protection doesn't protect against masquerading attacks, making the UTC-IMON system a necessity in every enterprise and organization. The UTC-IMON System will provide security notice in real time, and will have a highly reliable identification system, which includes a numerous elements of identifying and monitoring techniques. The UTC-IMON System will provide maximum modularity to enable future features, which will give the system an extra monitoring and identifying capabilities. -4- 1.2 The Problem Domain The UTC-IMON will be connected to the main communication channel of the organization, usually in the inner side of the network next to the Firewall, where the heaviest transportation is, in order to get the monitored communication to maximum. The UTC-IMON will interact with the 2 major actors: the system administrator and the domain expert, which will have a relevant GUI for each of them. It will also have optional access to the organizations user data server using an appropriate query language, to able an automatic user data querying. -5- 1.3 Stakeholders Our research work will help Deutsche Telekom to extend their line of products and offer a brand new perspective for security features. Potential Clients that might be interested in the UTC-IMON security features can vary from enterprises and organizations with a wide spread net of terminals that may hold sensitive information, to ISPs (internet service providers) that may be interested in this new feature as a service for their customers. Deutsche Telekom BGU representatives based on their experience and knowledge in the security and communication fields will guide and advise the developing team and together will design the system. 1.4 Software Context The UTC-IMON system will work like a sniffer; it will use the network transportation as an input. The system would identify and monitor users and their terminals, and characterize them by analyzing their network transportation (conversations see dictionary.). Based on the collected information, the system then will be able to notice a change in the behavior on a terminal, allowing it to notify the administrator about a threat according to predefined configurations. 1.5 System Interfaces Abstractly, our system is mainly interfaced to network transport. Hence, one of our goals would be to avoid a specific system-oriented hardware, which uniquely serves UTC-IMON. Therefore, this section will supply information regarding the software interfaces with our system. 1.5.1 Hardware Interfaces The system identifies the organization's user's behavior, by recognizing the terminal that transmits the data. No further hardware apart from the existing edge devices/terminal and the existing network architecture is needed. The existing hardware should be able to support analyzing up to 20,000 packets per second and the monitoring of 200 remote users. -6- 1.5.2 Software Interfaces The following varied software applications would be used in part of UTC-IMON: WireShark is a network protocol analyzer. It lets you interactively browse packet data from a live network or from a previously saved capture file. A major advantage that WireShark holds upon other similar tools is the ability to connect to it comfortably and threat it almost as an internal module in the system. User Data Servers will be connected to the UTC-IMON using an appropriate query language and the server’s API. The UTC-IMON system will provide an API to external software to support maximum compatibility, e.g. a reaction to alert made by UTC-IMON by an external system that in turn would block traffic on a terminal. 1.5.3 Events The basic event that changes the manner that UTC-IMON handles data stream, would be the identification of a user action that is exceptional to his pre-stored profile. Administrator and Domain Expert login and configuration can also change the system behavior. A user starting and ending session will also trigger a course of action of the system. As the analyzing constants are configurable, it is likely to happen that such an event that rose in a certain constellation would be unnoticeable from the user point of view and according to his will. -7- 2 Functional Requirements The project is comprised of a research part that in turn produces the foundation to the implementation part. 2.1 Research Requirements The process of developing the system evolves a comprehensive stage of research in the fields of data mining and anomaly net behavior. Tough this document emphasize the applicative side of the system, we've chosen to include several core research requirements. 1. Search and gather the most effective set of features that yields the most unique deterministic user character on the net. Under other constraints, a main goal from a research point of view is to reach a delicate balanced set of features that result (with the algorithm) in the best identification of a user. * More details in appendix part 5.1 2. Locate a data mining Model \ Algorithm that is the most reliable and produce the best result in user behavior anomaly detection. The obvious goal here would be to reach the higher level as possible of results when determine whether or not an anomaly usage is taking place. * More details in appendix part 5.2 The different combinations of profile features and algorithms would examined and rated by grades, statistics and success rate in different aspects of anomaly detection (such as TP\FP\ROC tables and other measures that would be elaborated in appendix part 5.3). This research evaluation stage would be extensive and comprehensive. The evaluation stage of the project will have applicative research requirements: Research Requirements Prio. # 1 Requirement Traffic recording 2 Traffic per user separation 3 Analyzer configuration 4 Analyze user traffic 5 Analyze users separated traffic Description The system will record traffic to a pcap file, enabling the reanalysis and comparison of information without reentering it from scratch. The system will separate a given pcap file to the relevant users who took part in it. The system will receive and modify the different analyzers with different configurations for execution it would receive. The system will analyze user traffic and produce a features profile and a standard deviation for the profile features. The system will analyze each of the user’s traffic in the group and produce the resulting features -8- Comments Generates a pcap file in a predefined format. Resulting in a format that enables to work on specific user traffic, and/or on a group of user’s traffic. For the 4 - 7 req. analyzers. * Will produce a profile of features and standard deviation In a predefined format. ** Will produce a series of profile feature and a standard deviation in 6 Analyze user delta traffic 7 Analyze users delta traffic 8 User Profile examination profile and a standard deviation for each of them. a predefined format. With a given delta the system would analyze and produce a behavior features for each delta in the user traffic. With a given delta the system would analyze and produce a profile features for each delta and each user in the given group traffic. With a given user profile features with the standard deviation and series of behavior features, the system examines according to the configuration each of the behavior features with the user profile features and standard deviation. * Will produce a series of behavior features In a predefined format. -9- ** * Results a statistic of the different aspects of anomaly detection rating (such as TP\FP\ROC graph… which is elaborated in appendix part 5.3). 2.2 Implementation part After the research part is over and conclusions been made, the Implementation part starts. The functional requirement for the implementation would be detail by reviewing the main aspects of the system: user management, profile feature, identification and monitoring, configuration and settings, reports. 2.2.1 User Management Requirements Each monitored user in the system would have it details and relevant data and statistic information stored. User Management prio # 1 Requirement Create a new User Description Add a new User to the system: Comments Possible user info: 2 Delete User X Remove an existing User data from the system 3 Delete all Users 4 Modify a User Attribute 5 User initialization Remove all existing Users data from the system Change an existing User data type attribute Initialization of the User details 6 Display User statistic in each stage the system enables a visualize display of the relevant user statistic Username Location Communication method (phone ,etc.) User type & permissions Training period Location/ on net station structure * , (UI or NUI) Related Requirement: Removal is Enabled through a frame that shows the oldest users * (UI) ** * Invoked at the profile creation process (see requirement 2.2.1, Or during reset (NUI) * , ** 2.2.2 Profile Feature For each user a profile feature is created, monitored, updated and checked. This profile represents the user behavior and habits. Profile Feature prio # 1 2 3 4 5 Requirement User X profile features initialization Add a new feature to the Users set Remove a feature from the users set Modify Users set feature Modify User X set Description Initialization of the User profile features. will be called by the profile creation requirement Add the Users profile features a new attribute Remove a feature from the user general profile Modify Users profile attribute. One or more from the feature data type. Modify a specific User profile - 10 - Comments * ** Actions that most likely enforce reset to the monitoring process, and possibly to the collected data as well. (Modify User X set feature from Y 6 7 feature. feature Delete User X profile features to Z) results in reentering the learning period * results in reentering the learning period Delete Users profile features ** 8 Display User profile features statistic in each stage the system enables a visualize display of the relevant profile features user statistic * , ** 2.2.3 Identification and Monitoring Requirements Identification and Monitoring prio # 1 Requirement Maintain applicative user data and statistics 2 Start User login session 3 End User login session high 4 high 5 Notify on a change in User profile behavior Notify on a new user login Request approval on a new user 6 7 8 Ignore notification of a change in User profile behavior Display Identification and Monitoring statistic Description Track and store data per user regarding: start of training log-in times login session intervals Chang a User login state from offline to online and start training/detection Chang a User login state from online to offline and stop training/detection Raise notification when a change in user profile is identified Notify when an unregistered user perform a login On notification (req. 5), approval from admin is needed prior to start of monitoring user. Ignore notification of a change in User profile behavior, and keep monitoring. in each stage the system enables a visualize display of the relevant profile features user statistic Comments ??? *, (NU) * ,(NU) Enable display of detailed user info, possibly on demand Possibly configurable setting The user behavior monitoring and learning would start only after the Admin approved it. * , ** 2.2.4 Configuration & Settings Requirements Configuration & Settings prio # 1 Requirement Configure system attributes 2 Modify system attribute/s Description Configure system setting: Domain Expert: - used detection algorithm Admin: - trash holding - notifications Configure system setting: Domain Expert: - used detection algorithm Admin: - 11 - Comments all the attributes at once At set-up time or at any given time a specific attribute 3 Change algorithm X from Y to Z - trash holding - notifications Replace the relevant algorithm from the current one to it other. Giving the required variables as detailed in appendix 5.2. Relevant to algorithm X = the profile update algorithm, the distance function algorithm or the alert rate algorithm. 4 5 6 7 8 Modify User X configuration attributes Modify User X configuration attribute from Y to Z Enable configuration reset to defaults Activate/Deactivat e system Display configuration Modify the user configuration attributes in the User profile * all the attributes at once Modify a specific attribute in the user configuration attributes that's in the User profile a specific attribute Keep defaults/initial settings, and provide the ability to roll back to it. Start and stop the system Secured & restricted operation in each stage the system enables a visualize display of the relevant configuration statistic * , ** 2.2.5 Reports Requirements Reports prio low # 1 Requirement Display Users profile features report Description Display report of the profile feature values for group of Users. Comments Possibly for single user 2 Display average Users profile features values report Display report of the average profile attributes values of all Users ** 3 Display notifications statistics Generation of notifications report that summarize notifications states. By user, by Terminal/Host, by date, etc.. 4 Display System configuration report Display current active (logged) users 5 Display list of currently logged in users. Comments Legend: 1. 2. 3. 4. * - Relevant to a specific User ** - Relevant to all Users (UI) - meaning an UI operation. (NUI) - meaning not an UI operation. - 12 - 3 Non-functional requirements 3.1 Performance constraints 3.1.1 Speed: The system is constantly monitoring and identifying, checking and re-checking for behavior anomaly (e.g. by a hostile element trying to commandeer a work) As such the speed in which the system performs is critical to its reliability and success rate. The faster a change in the common behavior is detected the better. Once an intrusion is detected above a fixed correctness percentage, the system would react and act accordingly. Since we are using an algorithm (see 5.2 for details) to analyze the data we splitter the requirements into 2 parts: The first part is the algorithm analyzing time which can be set during the initialization of the system, it can be set between half a second up to 15 minutes. The second part is the time takes to the system to show the analyzed data on the screen after processing, which should be within 1 minute. 3.1.2 Capacity: The number of terminals and user profiles the system monitors, would be defined by the size and complexity of the organization net. The system should support and monitor simultaneously all the terminals and users in the defined organization net. In conclusion the system should support up to 200 user profiles. The system will send a notification to the system administrator that would handle them. He will also configure the system according to the suitable requirements. - 13 - 3.1.3 Throughput: The System should monitor the entire network transportation in order to indentify and monitor users and terminals in the most efficient manner. The network transportation will be analyzed by the sniffer and will result in conversations information. This information includes attributes such as source, destination, IP and port along with the Protocol used. The number of packet the system will be able to monitor, is depended on the hardware of the machine the system is installed on and WireShark capabilities as well. In all the system should be able to monitor up to 20,000 packets per second. The conversations will be diagnosed by the system to induce identification and\or Behavior of the source user, which would be implemented as a set of values each representing specific attribute. This set of values will be used to compare with the user profile and\or to update it. A notification will be send to the system administrator if needed. 3.1.4 Reliability: The system constantly updates and learns the attributes of its users and terminals. Once on a pre-decided cycle, the system creates a restore point of the current gathered information. That restored point enables to reconstruct the system in case the system collapse. 3.1.5 Safety & Security: The gathered information will be encrypted and handled by authorized personal to prevent misuse or exploitation by a hostile element to deceive the system. Notification messages to the appropriate authority should be encrypted and secured in order to avoid flooding attack. The system can be accessed and configured only by the system administrator and the domain expert, using a unique user-name and password. In case the system will use files they will be encrypted and secured. 3.1.6 Usability: The common user doesn't need to be aware to the presence of the system. UTC-IMON is supposed to gather information unnoticed, and notify the administrator only when divert in the expected behavior is noticed. In contrast, the system administrator will need to understand the notifications from the system, i.e. the notifications would be simple and understandable. In addition the system administrator will need to be able to configure the system according to required demands. - 14 - 3.1.7 Availability: UTC-IMON should work at any time there's any kind of traffic on the corresponding Net. If an organization net is up and running 24 hours, so will be the UTC-IMON. In all the system should be available 99.9% of the time. 3.2 Platform constraints The system is developed using C# and C, Due to the special nature of data mining on a net, in Windows XP 2003 OS. 3.3 Special restrictions & limitations In order to develop the most modular easily embedded system, a major assumption would be that UTC-IMON would run on existing central net-machines, and won't force to any change or reordering of his current net structure. A general one year time restriction is taken into consideration while several low-level components are chosen to be a completed known open-source products, rather then be implemented from scratch. As our system focus on integrate various components, it would be waste of precious development time to try and reach the quality of those products. - 15 - 4 Usage Scenarios 4.1 User Profiles — the Actors 4.1.1 System Administrator The system administrator is the main user of the system therefore he has the main role in the system usage. He has the following responsibilities: 1. Add new user (could be an action of some other entity, possibly automated action). 2. Modify system settings. In addition to initially configure it (first use). 3. Receive real time notifications and alerts according to preferences. If pre-configured administrator can be notified on certain level(s) notifications and be asked to guide the system as for manner of treatment. 4.1.2 Domain expert The domain expert is responsible for system optimizations and advanced settings. He is familiar with all its features, algorithms and detailed configurations. 4.1.3 WireShark WireShark is the system main input source. The system receives all the network transport information from WireShark and uses it to analyze the users and terminals behavior. More information about WireShark is given separately at the end of this document. - 16 - 4.2 Use-cases - 17 - Use case 1: Section Name Description Goal Pre-Condition Post-Condition Course of Action Purpose Anomaly Detection System checks network throughput every fixed ∆t, and alerts the administrator for anomaly if needed. To detect user behavior if necessary. The system is running and configured The system finished the training phase for at least one user. Anomaly detected/Behaviour is normal . Actor System Timer signals the system to The system extracts the relevant throughput data from get the throughput from WireShark. WireShark. The system runs the anomaly detection algorithm in order to compare current users behavior with normal users behavior. The system decides normal behavior/ behavior anomaly and alerts the administrator in case of anomaly. Sequence Diagram: - 18 - Use case 2: Section Name Description Goal Pre-Condition Post-Condition Course of Action Purpose System Training System checks network throughput every fixed ∆t, and updates users profiles according to the new data. To train the system in order to be able to detect behavior anomaly in the future. The system is running and configured. Relevan users profiles were updated . Actor System Timer signals the system to The system extracts the relevant throughput data from get the throughput from WireShark. WireShark. The system extracts the relevant feature from the current data. The system updates relevant users profiles. Sequence Diagram: - 19 - Use case 3: Section Name Description Goal Pre-Condition Post-Condition Course of Action Purpose New User Creation New user addition to the system To handle unfamiliar user login by creating and adding new users to the system and start monitoring them. A user has logged in to the network. The user does not exist in the system. The network's administrator is logged in to ADS. The new user exists in the system and . Actor System The administrator receives the alert and chooses to add a the new user to the system. The administrator fills the user's details and approves. The administrator chooses to start the training process for the user. Alternative course (1) Alternative course (2) The system identifies a new user's login to the network and sends an alert to the network's administrator. The system presents a new user's form with relevant fields. The system stores the user's information, creates an empty user profile, and asks the administrator if he wants to start monitoring the user. The system starts the training process for the user. Actor System The administrator chooses not to add the new user to the system. The system asks for approval The administrator approves. Actor System The administrator isn't logged in . - 20 - The System adds the users to "pending users". Sequence Diagram: - 21 - Use case 4: Section Name Description Goal Pre-Condition Post-Condition Course of Action Purpose Administrator's system configurations change. System configuration change made by an administrator To let the administrator manipulate system configurations by his personal preferences. Administrator is logged in. System configuration has changed by the administrator's preferences. Actor System The administrator chooses "set/change system configurations" The administrator changes the relevant fields, and presses "save changes" Administrator approves. System presents "Administrator's system configuration" form. System asks for approval. Alternative course (1) Actor System Administrator presses "restore defaults" The system loads it's default administrator configurations. Alternative course (2) Actor System The administrator does not approve the changes saving. System returns to form filling. Alternative course (3) Actor System The administrator chooses "quit without saving" System closes "administrator's system configuration form" without saving. - 22 - The system saves the new configuration. Sequence Diagram: - 23 - Use case 5: Section Name Description Goal Pre-Condition Post-Condition Course of Action Purpose Domain Expert's system configurations change. System configuration change made by the domain expert. To let the domain expert manipulate system configurations in order to optimize it to a satisfactory condition. Domain expert is logged in to the system System configuration has changed by the domain expert's preferences. Actor System The domain expert chooses "set/change system configurations" The domain expert changes the relevant fields, and presses "save changes" Domain expert approves. System presents " Domain expert 's system configuration" form. System asks for approval. Alternative course (1) Actor System Domain expert presses "restore defaults" The system loads it's default domain expert configurations. Alternative course (2) Actor System The domain expert does not approve the changes saving. System returns to form filling. Alternative course (3) Actor System The domain expert chooses "quit without saving" System closes " domain expert's system configuration form" without saving. - 24 - The system saves the new configuration. Sequence Diagram: 4.3 Special usage considerations Besides knowing how to use Windows XP and its basic features, the System administrator will have to go through a short briefing and/or course about the configuration and use of the System. The domain expert must know the system very good (e.g. one of the developers) in order to be able to customize the system to work as efficient as possible. None of the actors above needs to be familiar with WireShark or any of its usability. However, if the domain expert will be familiar with it, it’s an advantage. - 25 - 5 Appendices 5.1 Features: Features category # 5.1.1 5.1.2 5.1.3 Feature Total amount Application Certain time periods Description Total throughput Throughput per application Throughput in certain time period (e.g. lunch time scenario). 5.1.4 Certain IP connections 5.1.5 Connections usage Throughput per certain IP destinations (e.g. highest\lowest IP connections) Usage per connection Throughput Order Usage Concurrent used connections Connection time. Certain time periods Login attempts Session Transport IP Password change Update request open ports number packets length reset packets Connections Certain time periods Settings Browser Homepage User agent Request type Usage order (e.g. staring order or usage order) Number or set of concurrent used connections. Connection usage time. Usage in certain time period (e.g. lunch time scenario). Different login attempts under a certain connection. (e.g. mail account) Identify a change password request. Identify a “Software Updating” request. Number of open ports length of packets per protocol amount of reset packets Certain IP connections IP destinations in certain time period (e.g. news websites in the morning, restaurants websites before lunch). Browser settings (security settings…) Browser homepage defined User agent used Request type (Get/post format) Comments Legend: 1. 2. 3. 4. (In\Out) - could be divided into two features, for the In and Out relevant information. Time – the information would be measured per ∆t or a determined amount of units. Used\not used –Boolean measurement. URL & Applications – could be Relevant for URL & Applications - 26 - Comments (in\out), Time Time OR used\not used URL & Application. URL & Application. Pair wise or a series of N units. URL & Applications Time URL & Application. Time Time URL & Application. (average amount div use time) 5.2 Algorithms: The user profile is comprised of 2 vectors: avg. features vector and a deviation vector. For each delta a user behavior features vector is build: 5.2.1 Profile update: There are 2 ways to update the user profile: - incremental update of a profile: For each feature in the avg. features vector a new value will be calculated: In other words: For each feature k in the profile, for the user i. For each field in the deviation vector a new value will be calculated: - Static update of a profile: Building a profile using instance dataset of behavior features, by finding average values for each feature on the behavior features dataset. 5.2.2 Distance function: - Euclidean distance: - Manhattan distance: Where n is the number of feature in the profile. - 27 - 5.2.3 Alerts rate: - The Leaky bucket algorithm: The algorithm can be conceptually understood as follows: o Consider a bucket with a hole in the bottom. o The empty part of the bucket represents an amount of credit available measured in anomaly detection incidents. o The size of the bucket S is the number of anomaly detection incidents allowed before an alert is made. This means that if the bucket is empty, size incidents of credit is available. o If an anomaly detection incident arrives and its S is less than the available credit, the alert can be forwarded. Otherwise, it is discarded or queued depending on the application. o The bucket leaks through the hole in its bottom at a constant rate of L incidents per a predefined amount of time, this indicates credit accummulation - All: Any case of anomaly detection incident would be alerted. 5.2.3 Versus Algorithems: Versus Algorithms category Profile update Algorithm1 incremental vs. vs. Algorithm2 Static Distance function Alerts rate Euclidean Leaky bucket vs. vs. Manhattan All - 28 - Variables Algo1 threshold bucket size, leaking amount, leaking rate (time) Variables Algo2 instances percentage of DS (ADD DS TO DIC.?!) threshold 5.3 Dictionary: Main players: User - an entity uses a terminal that is connected to a net that the system monitors. Administrator - responsible of users managing in the system, and receives the system alerts, notifications, and can modify the user configuration. Domain expert - responsible of the system configuration. Technical: Alert – message from the system of a change in a user behavior. Notification - message from the system of events that needs tending. Terminal – a working station that is connected to the monitored net via a network adaptor with a unique Mac address. Behavior – the working habits of the user, including: programs that uses the net, URLs, net protocols, working time, etc… Packet - a formatted block of information carried by a computer network. Conversation – a connection between an <IP, Port> and another <IP, Port>, which distinguish programs and protocols. TP / True positive - incidents that test positive for a condition representing a “TRUE” situation (In our case detecting a change from the normal user behavior as a threat). FP / False positive – incidents that test positive for a condition representing a “FALSE” situation (In our case detecting normal behavior as a threat). ROC graph – a graph representing equivalently by plotting the fraction of true positives (TPR = true positive rate) vs. the fraction of false positives (FPR = false positive rate), Displaying the ratio between the TP (Y axis) and the FP (X axis) rates. Domain objects: Feature – noticeable attribute from the gathered monitored data. Profile - set of feature that represents a specific user behavior, according to the gathered monitored information of the user. - 29 - 5.3 WireShark Since WireShark is based on Ethereal it has the same features, as followed: Data can be captured "off the wire" from a live network connection, or read from a capture file. Ethereal can read capture files from tcpdump (libpcap), NAI's Sniffer™ (compressed and uncompressed), Sniffer™ Pro, NetXray™, Sun snoop and atmsnoop, Shomiti/Finisar Surveyor, AIX's iptrace, Microsoft's Network Monitor, Novell's LANalyzer, RADCOM's WAN/LAN Analyzer, HP-UX nettl, i4btrace from the ISDN4BSD project, Cisco Secure IDS iplog, the pppd log (pppdump-format), the AG Group's/WildPacket's EtherPeek/TokenPeek/AiroPeek, or Visual Networks' Visual UpTime. It can also read traces made from Lucent/Ascend WAN routers and Toshiba ISDN routers, as well as the text output from VMS's TCPIPtrace utility and the DBS Etherwatch utility for VMS. Any of these files can be compressed with gzip and Ethereal will decompress them on the fly. Live data can be read from Ethernet, FDDI, PPP, Token-Ring, IEEE 802.11, Classical IP over ATM, and loopback interfaces (at least on some platforms; not all of those types are supported on all platforms). Captured network data can be browsed via a GUI, or via the TTY-mode "tethereal" program. Capture files can be programmatically edited or converted via command-line switches to the "editcap" program. 759 protocols can currently be dissected: 3COMXNS, 3GPP2 A11, 802.11 MGT, 802.11 Radiotap, 802.3 Slow protocols, 9P, AAL1, AAL3/4, AARP, ACAP, ACN, ACP133, ACSE, ACtrace, ADP, AFP, AFS (RX), AH, AIM, AIM Administration, AIM Advertisements, AIM BOS, AIM Buddylist, AIM Chat, AIM ChatNav, AIM Directory, AIM Email, AIM Generic, AIM ICQ, AIM Invitation, AIM Location, AIM Messaging, AIM OFT, AIM Popup, AIM SSI, AIM SST, AIM Signon, AIM Stats, AIM Translate, AIM User Lookup, AJP13, ALC, ALCAP, AMR, ANS, ANSI BSMAP, ANSI DTAP, ANSI IS-637-A Teleservice, ANSI IS-637-A Transport, ANSI IS-683-A (OTA (Mobile)), ANSI IS-801 (Location Services (PLD)), ANSI MAP, AODV, AOE, ARCNET, ARP/RARP, ARTNET, ASAP, ASF, ASN1, ASP, ATM, ATM LANE, ATP, ATSVC, AVS WLANCAP, AX4000, AgentX, Armagetronad, Auto-RP, BACapp, BACnet, BEEP, BER, BFD Control, BGP, BICC, BOFL, BOOTP/DHCP, BOOTPARAMS, BOSSVR, BROWSER, BSSAP, BSSGP, BUDB, BUTC, BVLC, Basic Format XID, BitTorrent, Boardwalk, CAMEL, CAST, CBAPDev, CCSDS, CCSRL, CDP, CDS_CLERK, CDT, CFLOW, CGMP, CHDLC, CIGI, CIMD, CIP, CISCOWL-L2, CLDAP, CLEARCASE, CLNP, CLTP, CMIP, CMP, CMS, CONV, COPS, COSEVENTCOMM, COSNAMING, COTP, CPFI, CPHA, CRMF, CSM_ENCAPS, CUPS, CoSine, DAAP, DAP, DCCP, DCERPC, DCE_DFS, DCOM, DCP, DDP, DDTP, DEC_DNA, DEC_STP, DFS, DHCPFO, DHCPv6, DIAMETER, DIS, DISP, DISTCC, DLSw, DLT User A, DLT User B, DLT User C, DLT User D, DNP 3.0, DNS, DNSSERVER, DOCSIS, DOCSIS BPKM-ATTR, DOCSIS BPKM-REQ, DOCSIS BPKM-RSP, DOCSIS DCC-ACK, DOCSIS DCC-REQ, DOCSIS DCC-RSP, DOCSIS DCD, DOCSIS DSA-ACK, DOCSIS DSA-REQ, DOCSIS DSA-RSP, DOCSIS DSC-ACK, DOCSIS DSC-REQ, DOCSIS DSC-RSP, DOCSIS DSD-REQ, DOCSIS DSD-RSP, DOCSIS INT-RNG-REQ, DOCSIS MAC MGMT, DOCSIS MAP, DOCSIS REG-ACK, DOCSIS REG-REQ, DOCSIS REG-RSP, DOCSIS RNG-REQ, DOCSIS RNG-RSP, DOCSIS TLVs, DOCSIS UCC-REQ, DOCSIS UCC-RSP, DOCSIS UCD, DOCSIS VSIF, DOCSIS type29ucd, DOP, DRSUAPI, - 30 - DSI, DSP, DSSETUP, DTP, DTSPROVIDER, DTSSTIME_REQ, DUA, DVMRP, Data, E.164, E.212, EAP, EAPOL, ECHO, EDONKEY, EDP, EFS, EIGRP, ENC, ENIP, ENRP, ENTTEC, EPM, EPMv4, ESIS, ESP, ESS, ETHERIC, ETHERIP, EVENTLOG, Ethernet, FC, FC ELS, FC FZS, FC-FCS, FCSB3, FC-SP, FC-SWILS, FC-dNS, FCIP, FCP, FC_CT, FDDI, FIX, FLDB, FR, FRSAPI, FRSRPC, FTAM, FTBP, FTP, FTP-DATA, FTSERVER, FW-1, Frame, G.723, GIF image, GIOP, GMRP, GNM, GNUTELLA, GPRS NS, GPRS-LLC, GRE, GSM BSSMAP, GSM DTAP, GSM RP, GSM SMS, GSM SMS UD, GSM_MAP, GSM_SS, GSS-API, GTP, GVRP, Gryphon, H.223, H.225.0, H.235, H.245, H.261, H.263, H.263 data, H1, H248, HCLNFSD, HPEXT, HPSW, HSRP, HTTP, HyperSCSI, IAP, IAPP, IAX2, IB, ICAP, ICBAAccoCB, ICBAAccoCB2, ICBAAccoMgt, ICBAAccoMgt2, ICBAAccoServ, ICBAAccoServ2, ICBAAccoServSRT, ICBAAccoSync, ICBABrowse, ICBABrowse2, ICBAGErr, ICBAGErrEvent, ICBALDev, ICBALDev2, ICBAPDev, ICBAPDev2, ICBAPDevPC, ICBAPDevPCEvent, ICBAPersist, ICBAPersist2, ICBARTAuto, ICBARTAuto2, ICBAState, ICBAStateEvent, ICBASysProp, ICBATime, ICEP, ICL_RPC, ICMP, ICMPv6, ICP, ICQ, IDP, IDispatch, IEEE 802.11, IEEE802a, IGAP, IGMP, IGRP, ILMI, IMAP, INAP, INITSHUTDOWN, IOXIDResolver, IP, IP/IEEE1394, IPComp, IPDC, IPFC, IPMI, IPP, IPVS, IPX, IPX MSG, IPX RIP, IPX SAP, IPX WAN, IPv6, IRC, IRemUnknown, IRemUnknown2, ISAKMP, ISDN, ISIS, ISL, ISMP, ISUP, ISystemActivator, IUA, IrCOMM, IrLAP, IrLMP, IuUP, JFIF (JPEG) image, JXTA, JXTA Message, Jabber, Juniper, K12xx, KADM5, KINK, KLM, KRB4, KRB5, KRB5RPC, Kpasswd, L2TP, LANMAN, LAPB, LAPBETHER, LAPD, LDAP, LDP, LGE_Monitor, LLAP, LLC, LLDP, LMI, LMP, LOOP, LPD, LSA, LWAPP, LWAPP-CNTL, LWAPP-L3, LWRES, Laplink, Line-based text data, Log, LogotypeCertExtn, Lucent/Ascend, M2PA, M2TP, M2UA, M3UA, MACC, MAPI, MAP_DialoguePDU, MATE, MDS Header, MEGACO, MGCP, MGMT, MIME multipart, MIPv6, MMS, MMSE, MOUNT, MPEG1, MPLS, MPLS Echo, MQ, MQ PCF, MRDISC, MS NLB, MS Proxy, MSDP, MSMMS, MSNIP, MSNMS, MSRP, MTP2, MTP3, MTP3MG, Manolito, Media, Messenger, Mobile IP, Modbus/TCP, MySQL, NBAP, NBDS, NBIPX, NBNS, NBP, NBSS, NCP, NCS, NDMP, NDPS, NFS, NFSACL, NFSAUTH, NHRP, NIS+, NIS+ CB, NJACK, NLM, NLSP, NMAS, NMPI, NNTP, NORM, NSIP, NSPI, NS_CERT_EXTS, NTLMSSP, NTP, NW_SERIAL, NetBIOS, Netsync, Null, OAM AAL, OCSP, OICQ, OLSR, OPSI, OSPF, PACKETCABLE, PAGP, PAP, PARLAY, PCLI, PCNFSD, PER, PFLOG, PFLOG-OLD, PGM, PGSQL, PIM, PKCS-1, PKIX Certificate, PKIX1EXPLICIT, PKIX1IMPLICIT, PKIXPROXY, PKIXQUALIFIED, PKIXTSP, PKInit, PKT CCC, PKTC, PN-DCP, PN-RT, PNIO, PNP, POP, PPP, PPP BACP, PPP BAP, PPP BCP, PPP CBCP, PPP CCP, PPP CDPCP, PPP CHAP, PPP Comp, PPP IPCP, PPP IPV6CP, PPP LCP, PPP MP, PPP MPLSCP, PPP OSICP, PPP PAP, PPP PPPMux, PPP PPPMuxCP, PPP VJ, PPP-HDLC, PPPoED, PPPoES, PPTP, PRES, PTP, PVFS, P_MUL, Portmap, Prism, Q.2931, Q.931, Q.933, QLLC, QUAKE, QUAKE2, QUAKE3, QUAKEWORLD, R-STP, RADIUS, RANAP, RDM, RDT, REMACT, REP_PROC, RIP, RIPng, RLM, RMCP, RMI, RMP, RNSAP, ROS, RPC, RPC_BROWSER, RPC_NETLOGON, RPL, RQUOTA, RRAS, RSH, RSTAT, RSVP, RSYNC, RS_ACCT, RS_ATTR, RS_BIND, RS_PGO, RS_PLCY, RS_REPADM, RS_REPLIST, RS_UNIX, RTCP, RTMP, RTP, RTP Event, RTPS, RTSE, RTSP, RTcfg, RTmac, RUDP, RWALL, RX, Raw, Raw_SIP, Raw_SigComp, Redback, Rlogin, SADMIND, SAMR, SAP, SCCP, SCCPMG, SCSI, SCTP, SDLC, SDP, SEBEK, SECIDMAP, SES, SGI MOUNT, SIGCOMP, SIP, SIPFRAG, SIR, SKINNY, SLARP, SLL, SM, SMB, SMB Mailslot, SMB Pipe, SMB2, SMB_NETLOGON, SMPP, SMRSE, SMTP, SMUX, SNA, SNA XID, SNAETH, SNDCP, SNMP, SONMP, SPNEGO, SPNEGO-KRB5, SPOOLSS, SPP, SPRAY, SPX, SRP, SRVLOC, SRVSVC, SSCF-NNI, SSCOP, SSH, SSL, SSS, STANAG 4406, STANAG 5066, STAT, STAT-CB, STP, STUN, SUA, SVCCTL, Serialization, SliMP3, Socks, SoulSeek, Symantec, Synergy, Syslog, T.30, T.38, TACACS, TACACS+, TALI, TANGO, TAPI, TCAP, TCP, TDMA, TDS, TEI_MANAGEMENT, TELNET, TFTP, TIME, TIPC, TKN4Int, TNS, TPCP, TPKT, TR MAC, TRKSVR, TSP, TTP, TUXEDO, TZSP, Teredo, Token-Ring, UBIKDISK, UBIKVOTE, UCP, UDP, UDPENCAP, UDPlite, UMA, V.120, V5UA, VLAN, VNC, VRRP, VTP, Vines ARP, Vines Echo, Vines FRP, Vines ICP, Vines IP, Vines IPC, Vines LLC, Vines RTP, Vines SPP, WAP SIR, WBXML, WCCP, WCP, WHDLC, WHO, WINREG, WINS-Replication, WKSSVC, WLANCERTEXTN, WSP, WTLS, WTP, X.25, X.29, X11, X411, X420, X509AF, X509CE, X509IF, - 31 - X509SAT, XDMCP, XML, XOT, XYPLEX, YHOO, YMSG, YPBIND, YPPASSWD, YPSERV, YPXFR, ZEBRA, ZIP, cds_solicit, cprpc_server, dc, dce_update, dicom, giFT, h221nonstd, h450, iFCP, iSCSI, iSNS, isup_thin, itunes, llb, message/http, nettl, rdaclif, roverride, rpriv, rs_attr_schema, rs_misc, rs_prop_acct, rs_prop_acl, rs_prop_attr, rs_prop_pgo, rs_prop_plcy, rs_pwd_mgmt, rs_repmgr, rsec_login, rss, sFlow, smil. Output can be saved or printed as plain text or PostScript®. Data display can be refined using a display filter. Display filters can also be used to selectively highlight and color packet summary information. All or part of each captured network trace can be saved to disk. - 32 -