1. ===!"§ Deutsche Telekom THE UTC-IMON PROJECT Users and Terminals Characterization, Identification and Monitoring On a Net Net Anomaly Detection System Company: Deutsche Telekom Academic advisor: Yuval Elovici Technical advisor : Asaf Shabtai & Yuval Fledel Project Team:Raz Kitzoni Aryhe Segal Eliad Barzi Mati Kochen

2. Page 1 ===!"§ Deutsche Telekom 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 Background – The Problem

3. Page 2 ===!"§ Deutsche Telekom We ’ ll try to present the problem and the need for our system by presenting a scenario we like to refer to as : “ Bathroom Attack ” (A.K.A Crap Attack) Background – The Problem – cont.

4. Page 3 ===!"§ Deutsche Telekom Imagine a Normal shinny day. Our “Normal” employee, lets call him RAZ, is working in his cubical … Background – The Problem – cont.

5. Page 4 ===!"§ Deutsche Telekom When he finds himself having to answer a basic call of nature…. 00 Background – The Problem – cont.

6. Page 5 ===!"§ Deutsche Telekom In his absence his open terminal is commandeered by his nemesis, lets call him ZAR, who misuses RAZ privileges… 00 Background – The Problem – cont.

7. ===!"§ Deutsche Telekom Problem

8. Page 7 ===!"§ Deutsche Telekom The Solution UTC-IMON The UTC-IMON system is a security tool which extends the existing layer of standard user authentication protection. Using network traffic observation UTC-IMON identifies and monitors users and terminals.

9. Page 8 ===!"§ Deutsche Telekom The Problem Domain The UTC-IMON will be connected to the main communication channel of the organization net. The system would be sniffing and listening to the data running through the channel. In turn this analyzed data would be used to identify an “order in the chaos” of users behavior

10. Page 9 ===!"§ Deutsche Telekom The Problem Domain – cont.

11. Page 10 ===!"§ Deutsche Telekom UTC-IMON (in a nutshell) UTC-IMON sniffs the network using WireShark, identify and monitor users and their terminals, Characterizing them by analyzing their network conversations. Based on the collected information, the system is able to notice and notify on a a possible threat in cases of a change in user behavior.

12. Page 11 ===!"§ Deutsche Telekom UTC-IMON (in a nutshell) – cont. The 2 major stages of the system are: 1.Training stage: when a new user is identified, UTC-IMON starts learning his behavior, creating a representing profile. 2.Detection stage: in this stage the system is constantly checking user behavior looking for a divert from a profile. In such cases the system alerts the appropriate authority. UTC-IMON keeps learning and updating users profile while activated.

13. Page 12 ===!"§ Deutsche Telekom Functional Requirements n Research Requirement The process of developing the system evolves a comprehensive stage of research in the fields of data mining and anomaly detection. Main requirement: * Traffic recorder. * Traffic analyzer (converts traffic to different behavior profiles). * behavior examiner (checks how good the analysis was).

14. Page 13 ===!"§ Deutsche Telekom Functional Requirements – cont. n Implementation Requirement After the research part is over and conclusions been made, the Implementation part starts Main Requirements User Management Requirements: * User manipulation - creation, modification and removal. * User statistics and details display. Profile Feature Requirements: * Profile manipulation. * Profile statistics and details display.

15. Page 14 ===!"§ Deutsche Telekom Functional Requirements – cont. Identification and Monitoring Requirements: * Alert manipulation - notification, approval and removal. * Alert statistics and details display. Configuration & Settings Requirements: * System configuration – algorithms, defaults and settings. * Configuration statistics and details display. Reports Requirements: * Different reports and system statistics for the adjustment and fitting of the system.

16. Page 15 ===!"§ Deutsche Telekom Non-Functional Requirements n Speed: * The Data analyze algorithm would be half a second up to 15 minutes according to the system initialization. * It takes up to 1 minute to show the analyzed data on the screen after processing. n Capacity: The system should support up to 200 user profiles. n Throughput: In all the system should be able to monitor up to 20,000 packets per second. n Reliability: The system creates a restore point once a given predefined time. Enabling reconstruction of the system in case the system collapse.

17. Page 16 ===!"§ Deutsche Telekom Non-Functional Requirements n Safety & Security: The gathered information will be encrypted and handled by authorized personal. n Usability: The configuration and notifications to the Admin and Domain Expert would be simple and understandable. The common user isn’t aware of the system presence. n Availability: In all the system should be available 99.9% of the time.

18. Page 17 ===!"§ Deutsche Telekom Use Cases

19. Page 18 ===!"§ Deutsche Telekom Use Case 1 SectionPurpose NameSystem Training DescriptionSystem checks network throughput every fixed ∆t, and updates users profiles according to the new data. GoalTo train the system in order to be able to detect behavior anomaly in the future. Pre- Condition  The system is running and configured. Post- Condition Relevan users profiles were updated. Course of Action ActorSystem Timer signals the system to get the throuput from wireshark. The system extracts the relevant throughput data from Wireshark. The system extracts the relevant feature from the current data. The system updates relevant users profiles.

20. Page 19 ===!"§ Deutsche Telekom Use Case 1 - Sequence Diagram

21. Page 20 ===!"§ Deutsche Telekom Use Case 2 SectionPurpose NameAnomaly Detection DescriptionSystem checks network throughput every fixed ∆t, and alerts the administrator for anomaly if needed. GoalTo detect user behavior if necessary. Pre- Condition  The system is running and configured  The system finished the training phase for at least one user. Post- Condition Anomaly detected/Behaviour is normal. Course of Action ActorSystem Timer signals the system to get the throuput from wireshark. The system extracts the relevant throughput data from 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.

22. Page 21 ===!"§ Deutsche Telekom Use Case 2 - Sequence Diagram

23. Page 22 ===!"§ Deutsche Telekom Use Case 3 SectionPurpose NameNew User Creation DescriptionNew user addition to the system GoalTo handle unfamiliar user login by creating and adding new users to the system and start monitoring them. Pre-Condition  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. Post-ConditionThe new user exists in the system and. Course of Action Alternative course (1) Alternative course (2) ActorSystem The system identifies a new user's login to the network and sends an alert to the network's administrator. The administrator receives the alert and chooses to add a the new user to the system. The system presents a new user's form with relevant fields. The administrator fills the user's details and approves. 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 administrator chooses to start the training process for the user. The system starts the training process for the user. ActorSystem The administrator chooses not to add the new user to the system.The system asks for approval The administrator approves. ActorSystem The administrator isn't logged in.The System adds the users to "pending users".

24. Page 23 ===!"§ Deutsche Telekom Use Case 3 - Sequence Diagram

25. Page 24 ===!"§ Deutsche Telekom Use Case 4 SectionPurpose NameAdministrator's system configurations change. DescriptionSystem configuration change made by an administrator GoalTo let the administrator manipulate system configurations by his personal preferences. Pre-Condition  Administrator is logged in. Post-ConditionSystem configuration has changed by the administrator's preferences. Course of Action Alternative course (1) Alternative course (2) Alternative course (3) ActorSystem The administrator chooses "set/change system configurations" System presents "Administrator's system configuration" form. The administrator changes the relevant fields, and presses "save changes" System asks for approval. Administrator approves.The system saves the new configuration. ActorSystem Administrator presses "restore defaults"The system loads it's default administrator configurations. ActorSystem The administrator does not approve the changes saving.System returns to form filling. ActorSystem The administrator chooses "quit without saving"System closes "administrator's system configuration form" without saving.

26. Page 25 ===!"§ Deutsche Telekom Use Case 4 - Sequence Diagram

27. Page 26 ===!"§ Deutsche Telekom Use Case 5 SectionPurpose NameDomain Expert's system configurations change. DescriptionSystem configuration change made by the domain expert. GoalTo let the domain expert manipulate system configurations in order to optimize it to a satisfactory condition. Pre-ConditionDomain expert is logged in to the system Post-ConditionSystem configuration has changed by the domain expert's preferences. Course of Action Alternative course (1) Alternative course (2) Alternative course (3) ActorSystem The domain expert chooses "set/change system configurations" System presents " Domain expert 's system configuration" form. The domain expert changes the relevant fields, and presses "save changes" System asks for approval. Domain expert approves.The system saves the new configuration. ActorSystem Domain expert presses "restore defaults"The system loads it's default domain expert configurations. ActorSystem The domain expert does not approve the changes saving.System returns to form filling. ActorSystem The domain expert chooses "quit without saving"System closes " domain expert's system configuration form" without saving.

28. Page 27 ===!"§ Deutsche Telekom Use Case 5 - Sequence Diagram

29. Page 28 ===!"§ Deutsche Telekom Possible Risks UTC-IMON success rate anomaly detection is critical. This depend mainly in the various features of the user behavior profile, that are identified an monitored. Not good enough statistics would make the system pointless.

30. Page 29 ===!"§ Deutsche Telekom The End Thanks & Good Luck (…BEWARE OF ZAR…)