Description
Overview
You need to design and implement an Email system event modeller & intrusion detection system in accordance with the system descriptions below. The implementation is to be in C, C++ or Java. While there are concrete details on the form of the initial input, and certain inputs along the way, the format of intermediate data is up to each group.
You need to provide a report in a file Report.pdf covering the various points through this assignment where information is required. This report should be broken into sections associated with the components as follows:
• Initial input.
• Activity engine and the logs.
• Analysis engine.
• Alert engine.
Initial Input
You only need command line options at the setup phase, some user input is required later.
IDS Events.txt Stats.txt Days
Events.txt and Stats.txt define the formats and the distributions of the events to be modelled. Days is an integer used in the next section.
Here goes an example Events.txt file. This file describes the events and some of their parameters.
5 Logins:D:0::3:
Time online:C:0:1440:2:
Emails sent:D:0::1:
Emails opened:D:0::1:
Emails deteled:D:0::2:
The first line contains the number of events being monitored. Each subsequent line is of the form
Event name:[CD]:minimum:maximum:weight:
The file Stats.txt contains the distributions to be modelled for the events. Here goes an example Stats.txt file.
5 Logins:4:1.5:
Time online:150.5:25.00:
Emails sent:10:3:
Emails opened:12:4.5:
Emails deteled:7:2.25:
The first line again contains the number of events being monitored. Each subsequent line is of the form
Event name:mean:standard deviation:
Your program should appropriately report events and statistics read in, as evidence this phase works. You should include in your report a description of:
1. How you are going to store the events and statistics internally.
2. Potential inconsistencies between Events.txt and Stats.txt. You should attempt to detect those inconsistencies. If there are inconsistencies you are aware of but haven’t attempted to detect them, note this in your report.
Activity Simulation Engine and the Logs
Once the intial setup has taken place, and you have read in the base files, the activity engine should start generating and logging events. Your program should give some indication as to what is happening, without being verbose.
You are attempting to produce statistics approximately consistent with the statistics specified in the file Stats.txt. You should log for the number of Days specified at the initial running of IDS. You can, if you like, store the events in distinct files for each day, or in a single log file. This collection of events forms the baseline data for the system.
You should include in your report a description of:
1. The process used to generate events approximately consistent with the particular distribution. Thisis likely to differ between discrete and continuous events.
2. The name and format of the log file, with justification for the format. You will need to be able toread the log entries for subsequent parts of the program. The log file needs to be human readable.
Analysis Engine
Your program should indicate it has completed event generation and is going to begin analyse. You can now measure that baseline data for the events and determine the statistics associated with the baseline.
Produce totals for each event for each day, store that in a data file, and determine the mean and standard deviation associated with that event across that data. Report what is happening as you consider appropriate.
Even if you are unable to produce data consistent with a given distribution you can still have the analysis engine reading and reporting on the log file.
You should include in your report the name and format of the file containing the daily totals and statistical data for the events.
Alert Engine
The alert engine is used to check consistency between “live data” and the base line statistics. Once this phase is reached you should prompt the user for a file, containing new statistics, and a number of days. The new statistics file has the same format as Stats.txt from earlier but will generally have different parameters for the events. You should run your activity engine and produce data for the number of days specified. Use the analysis engine to produce daily totals, those are used in alert detection.
For each day generated you need to report on whether the there is an intrusion detected by comparing an anomaly counter with a threshold. You calculate the anomaly counter by adding up the weighted number of standard deviations each specific tested event value is from the mean for that event, where the standard deviation and mean are those you have generated from the base data and reported, and the weight is taken from the original Events.txt file.
For example, if the mean number of logins per day is 4 and the standard deviation is 1.5; then if we get 1 login in a day we are 2 standard deviations from the mean. Referring back to the weight of the login event we see it was 2 so the login event contributes 4 to our overall anomaly counter.
The threshold for detecting an intrusion is 2∗(Sums of weights) where the weights are taken from Events.txt. If the anomaly counter is greater or equal to the threshold you should report this as an anomaly.
You should output the threshold, and give the anomaly counter for each day as well as stating each day as okay or flagged as having an alert detected.
Once the alert engine part has finished you should return to the start of this phase, so another set of statistics and number of days can be considered. An option to quit should be provided.
Notes on submission
1. Submission is via Moodle. Everything will need to be uploaded in a single zip file. Please don’t putsubdirectories in your submission. In addition to addressing the specified points, you can include anything of significance in your report. You should report on any parts not completed. be marked.
2. Include the compilation instructions with your submission (i.e., provide a readme.txt file).
4. Submissions more than three days late will not be marked, unless an extension has been granted.
