Added the gist from last two meetings.

Major sections: Implementation, Cons, Evaluation, Motivation
parent a454d6da
No preview for this file type
......@@ -73,10 +73,76 @@ the traffic or mitigate the attack.
One primary instance to monitor the traffic constantly. And there must be
standby instances ready to monitor rather than instantiating newly. When these
standby's are used then a new instance to be spawned. This is just to make
sure that we react to the situation as soon as possible.
We are looking into BRO IDS as it is easy to add rules to alert when something
goes out of normal. The catch is that these rules are handcrafted.
Another thing to consider is the traffic that is tapped before the firewall
and after the firewall. The traffic after the firewall is always considered to
be safe but it may not be the case in few.
Closed loop has two parts. One the instance creation and the second the
network changes for reacting to the alert. As of now there is no defined way
to have specific actions for some alerts and it is well beyond the scope of
this project. Requires extensive machine learning and extensive parsing rules
and an important thing will be the false positive actions.
We'll be concentrating on the cloud instance creation for the taps rather than
taking network level actions.
Another thing to look out for is that Security Onion is not meant to scale.
Have to manually test the Server Sensor combination to come up with the
maximum capacity.
Few cases for new instance creation are heavy load to one IDS, drastic alert
from single source like a flood of TCP connection. Should come up with various
such cases. This will be good enough to start off with.
Another thought to have SDN in cloud like a pluggable entity. Have a tapping
gateway and just deliver it to the instance to make it more practical. [TO-DO :
Make it clear]
Provision with dedicated fiber connections for tunnelling. We can leverage
this to make the inbound traffic isolated from the core network traffic
wherever possible. Terminologies for the traffic : Inbound, Outbound, Hybrid.
\section{More Motivation}
\item Tapping Issues in Current Network: Mirror costs is very high.
\item If span ports are used, the first thing that is taken down when the
traffic increases are these ports. [+SDN : can be selective on what we
monitor rather than the whole traffic]
\item To have a fully secure network the cost will be multiple times the
actual network setup cost with monitors, taps etc. for it.
\item Hospital Data path are not tapped as it has very high bandwidth and
requires high end tapping optics of high expense.
\item Inbound traffic tunnelling increases network usage in core network.
\item Crossing of administration boundary between the Cloud and the Core
\item True Mirror: Is SDN mirror port a true mirror as claimed.
\item Monitor the router usage with and without our Arch.
\item Numbers always vary when tested with a sampled traffic and a live
\section{Tools Considered}
\item Eucalyptus to be used for the Cloud setup. Use AWS API for
programming as Eucalyptus uses the same programming interface as EC2.
\item GENI to be used for the cloud part (inside GENI itself). [TO-DO Pending
Discussion with Yung Wook]
\item Security Onion (SO) [pluggable interface for various IDS]
......@@ -122,6 +188,9 @@ interface.
\item What kind of rules to be taken care in CLIPS/DROOL to take action in
the network. Example. Load Balancing, Suspicious TCP connections for a
single service etc.
\item Splitting of traffic is done in two areas. One in cloud and other in
the core network. The inbound network usage must be checked when
installing new taps.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment