Embed Size (px)
Citation preview
===!"§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 KitzoniAryhe SegalEliad BarziMati Kochen
Page 2===!"§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
Page 3===!"§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.
Page 4===!"§Deutsche Telekom
Imagine a Normal shinny day.Our “Normal” employee,
lets call him RAZ,is working inhis cubical …
Background – The Problem – cont.
Page 5===!"§Deutsche Telekom
When he finds himself having to answer a basic call of nature….
00
Background – The Problem – cont.
Page 6===!"§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.
===!"§Deutsche Telekom
Problem
Page 8===!"§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.
Page 9===!"§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
Page 10===!"§Deutsche Telekom
The Problem Domain – cont.
Page 11===!"§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.
Page 12===!"§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.
Page 13===!"§Deutsche Telekom
Functional Requirements
Research RequirementThe 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).
Page 14===!"§Deutsche Telekom
Functional Requirements – cont.
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.
Page 15===!"§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.
Page 16===!"§Deutsche Telekom
Non-Functional Requirements
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.
Capacity: The system should support up to 200 user profiles. Throughput: In all the system should be able to monitor up to 20,000
packets per second. Reliability: The system creates a restore point once a given predefined
time. Enabling reconstruction of the system in case the system collapse.
Page 17===!"§Deutsche Telekom
Non-Functional Requirements
Safety & Security: The gathered information will be encrypted and handled by authorized personal.
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.
Availability: In all the system should be available 99.9% of the time.
Page 18===!"§Deutsche Telekom
Use Cases
Page 19===!"§Deutsche Telekom
Use Case 1Section Purpose
Name System Training
Description System checks network throughput every fixed ∆t, and updates users profiles according to the new data.
Goal To 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
Actor System
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.
Page 20===!"§Deutsche Telekom
Use Case 1 - Sequence Diagram
Page 21===!"§Deutsche Telekom
Use Case 2Section Purpose
Name Anomaly Detection
Description System checks network throughput every fixed ∆t, and alerts the administrator for anomaly if needed.
Goal To 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
Actor System
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.
Page 22===!"§Deutsche Telekom
Use Case 2 - Sequence Diagram
Page 23===!"§Deutsche Telekom
Use Case 3Section Purpose
Name New User Creation
Description New user addition to the system
Goal To 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-Condition The new user exists in the system and .
Course of Action
Alternative course (1)
Alternative course (2)
Actor System
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.
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 . The System adds the users to "pending users".
Page 24===!"§Deutsche Telekom
Use Case 3 - Sequence Diagram
Page 25===!"§Deutsche Telekom
Use Case 4Section Purpose
Name Administrator's system configurations change.
Description System configuration change made by an administrator
Goal To let the administrator manipulate system configurations by his personal preferences.
Pre-Condition Administrator is logged in.
Post-Condition System configuration has changed by the administrator's preferences.
Course of Action
Alternative course (1)
Alternative course (2)
Alternative course (3)
Actor System
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.
Actor System
Administrator presses "restore defaults" The system loads it's default administrator configurations.
Actor System
The administrator does not approve the changes saving. System returns to form filling.
Actor System
The administrator chooses "quit without saving" System closes "administrator's system configuration form" without saving.
Page 26===!"§Deutsche Telekom
Use Case 4 - Sequence Diagram
Page 27===!"§Deutsche Telekom
Use Case 5Section Purpose
Name Domain Expert's system configurations change.
Description System configuration change made by the domain expert.
Goal To let the domain expert manipulate system configurations in order to optimize it to a satisfactory condition.
Pre-Condition Domain expert is logged in to the system
Post-Condition System configuration has changed by the domain expert's preferences.
Course of Action
Alternative course (1)
Alternative course (2)
Alternative course (3)
Actor System
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.
Actor System
Domain expert presses "restore defaults" The system loads it's default domain expert configurations.
Actor System
The domain expert does not approve the changes saving. System returns to form filling.
Actor System
The domain expert chooses "quit without saving" System closes " domain expert's system configuration form" without saving.
Page 28===!"§Deutsche Telekom
Use Case 5 - Sequence Diagram
Page 29===!"§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.
Page 30===!"§Deutsche Telekom
The End
Thanks & Good Luck
(…BEWARE OF ZAR…)
