Download 1 - The Department of Computer Science

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 -