Popular in Formal Sciences

Formal Sciences

Diameter rigidity for Kähler manifolds with positive bisectional curvature

Indian Institute of Science Ved Datar

Formal Sciences

Rank-Based Multivariate Sarmanov for Modeling Dependence

McMaster University Anas Abdallah

Formal Sciences

The Hybrid High-Order Method for Polytopal Meshes

Monash University

Formal Sciences

Financial Informatics: An Information-Based Approach to Asset Pricing

University of Surrey

Formal Sciences

Multiplicative orders of Gauss periods and the arithmetic of real quadratic fields

University of Newcastle

Formal Sciences

Some Numerical Methods for the Hele-Shaw Equations

University of Massachusetts at Amherst

Formal Sciences

Geometric stabilisation via p-adic integration

University of Toronto

Security Challenges and Opportunities of Software-Defined Networking

View more insights in Sciences - Computer Science - Formal Sciences

View more figures from King Abdullah University of Science and Technology

Next in Computer Science

Software Testing of Generative AI Systems: Challenges and Opportunities

Aldeida Aleti | Monash University

Increasing learner interactions with E-learning systems

Ali Darejeh | UNSW Sydney

Marc Dacier discuss SDN’s security challenges, debate strategies to monitor and protect SDN-enabled networks, and propose methods and strategies to leverage SDN’s flexibility for designing new security mechanisms.

Read the Study

Image courtesy of interviewee. September 22, 2022

Log-in or Sign-up to Faculti
Currently viewing this subject insight as a guest. You have insight(s) remaining for this month. Login to view 8000+ figures on the platform.

Generating Workspace...

Export as PDF

This video discusses software-defined networks (SDN), which centralize network management through a controller that makes routing decisions based on flow rather than individual packets. This video provides finer granularity in flow handling and allows for customized network policies based on various constraints like security, performance, and quality of service. However, centralization also introduces vulnerabilities, such as a single point of failure where the controller could become compromised, leading to severe security risks.

Key challenges include the potential for attackers to manipulate the controller by flooding it with false information, leading to denial-of-service attacks, and the need for assurance that the applications running on the controller are secure and operate correctly. Furthermore, the interaction between multiple applications that make routing decisions can result in conflicting outcomes.

To address these issues, the text emphasizes the importance of network-based intrusion detection and the development of robust policies to govern network behavior. Methods such as behavioral modeling and invariants can be used to monitor network integrity. The flexibility of SDN can also support dynamic security measures, allowing for the rerouting of suspicious traffic for analysis rather than immediate termination.

In conclusion, while SDN offers advantages like improved visibility and control over network flows, it also presents significant security challenges that must be tackled with thorough oversight and protective measures against potential intrusions.

Language:

Export as PDF

X-TIMESTAMP-MAP:LOCAL=00:00:00.000,MPEGTS=900000

00:06.600 --> 00:09.400
So software defined networks, as it names implies

00:09.400 --> 00:12.800
is a term a global

00:12.800 --> 00:15.500
term that encompasses different techniques

00:15.500 --> 00:18.400
to manage a network. Thanks to

00:18.400 --> 00:21.600
a software. And as of today most networks

00:21.600 --> 00:24.900
already rely on on different pieces of software, but

00:24.900 --> 00:27.600
the difference is that these software is typically

00:27.600 --> 00:30.600
run in a distributed fashion in the

00:30.600 --> 00:33.700
various components of the network. So typically the

00:33.700 --> 00:36.100
routing software and and elements like

00:36.100 --> 00:39.100
that. The novelty with sdn is to have a

00:39.100 --> 00:42.900
central component a controller where we

00:42.900 --> 00:46.500
will have a software that runs received information

00:46.500 --> 00:49.500
from the different components of the diva of

00:49.500 --> 00:52.700
the network and that controller takes

00:52.700 --> 00:55.500
decision as to how to route the packet

00:55.500 --> 00:58.200
from A to B. What packets need to

00:58.200 --> 01:01.800
go where and what treatment they need to be given

01:01.800 --> 01:04.300
and when I say packets, it's

01:04.300 --> 01:04.800
not exactly

01:05.500 --> 01:09.300
True we have to talk in terms of flow. So a

01:08.300 --> 01:11.500
series of packets a stream of packets between

01:11.500 --> 01:14.200
two a sender and

01:14.200 --> 01:17.300
a receiver and the advantage of of that

01:17.300 --> 01:20.400
concept is that it enables you to have a

01:20.400 --> 01:23.900
much finer granularity in the handling

01:23.900 --> 01:26.500
of those flows. Typically when we

01:26.500 --> 01:29.800
do some filtering or some

01:29.800 --> 01:33.000
management of of the the routes at

01:32.100 --> 01:35.600
the in the classical systems. We are

01:35.600 --> 01:38.200
very limited and we typically do this by

01:38.200 --> 01:41.600
at the granularity of the IP blogs

01:41.600 --> 01:44.700
or something like that. Whereas now with with these new systems,

01:45.500 --> 01:48.500
Open Flow for instance, which is the main protocol

01:48.500 --> 01:51.300
used for sdn supports something

01:51.300 --> 01:54.500
like 44 different fields that you can use to

01:54.500 --> 01:57.900
decide which flow will receive which treatment

01:57.900 --> 02:01.600
and the controller can actually

02:01.600 --> 02:04.400
use can actually be tailored or customized

02:04.400 --> 02:07.800
to take different kinds of constraints into account. So

02:07.800 --> 02:11.700
if you are mostly concerned with security or

02:11.700 --> 02:14.400
mostly concerned with performance or quality

02:14.400 --> 02:17.400
of services or Equity or other elements

02:17.400 --> 02:21.000
like that, you can actually have your software apply

02:20.100 --> 02:23.600
different policies according to to your

02:23.600 --> 02:25.700
your constraints.

02:26.600 --> 02:29.100
And you can actually combine those constraints you can

02:29.100 --> 02:32.400
say well that kind of flows. I

02:32.400 --> 02:35.700
want to favor performance that kind of other flows.

02:35.700 --> 02:38.300
No, they need to be more they need

02:38.300 --> 02:41.900
to be routed or treated according to this rule that

02:41.900 --> 02:45.300
I have more to do with with security. So it's

02:44.300 --> 02:47.900
a it's a way to virtualize the

02:47.900 --> 02:51.000
network infrastructure and to simplify and

02:50.600 --> 02:53.800
manage centrally what is

02:53.800 --> 02:56.500
going on in a network. This is all good and

02:56.500 --> 02:59.200
nice to have you know, a central point of

02:59.200 --> 03:02.300
command so to speak because it gives

03:02.300 --> 03:05.400
you visibility and control the problem

03:05.400 --> 03:08.800
is that you now have a single point of failure because

03:08.800 --> 03:11.300
that controller if it's

03:11.300 --> 03:14.700
not doing its job if a bad guy is taking control

03:14.700 --> 03:17.900
over it then you are really in trouble because he

03:17.900 --> 03:20.600
has full control over your whole network.

03:20.600 --> 03:23.500
So that is you know, one aspect you

03:23.500 --> 03:26.400
really have to take into account moreover.

03:26.500 --> 03:29.500
Were the this controller

03:29.500 --> 03:32.400
is actually receiving information about the

03:32.400 --> 03:36.200
ongoing flows by from the different devices and

03:35.200 --> 03:39.100
is using this information to make decision. And

03:38.100 --> 03:41.500
so it could be if you

03:41.500 --> 03:44.700
have not designed your network properly that an

03:44.700 --> 03:47.200
attacker could actually overflow in your

03:47.200 --> 03:50.500
controller by sending to it packets that

03:50.500 --> 03:53.500
supposedly come from the device, but they were not

03:53.500 --> 03:56.200
coming from the device and and that suddenly

03:56.200 --> 04:00.100
your controller has to deal with a lot of fake information

03:59.100 --> 04:02.400
about what is going on in network. You

04:02.400 --> 04:05.600
can actually create a denial of service if you want against your

04:05.600 --> 04:06.200
controller.

04:07.500 --> 04:10.900
Another element another very big challenge for

04:10.900 --> 04:13.400
this Paradigm to

04:13.400 --> 04:17.000
be implemented properly and securely is that in the

04:16.500 --> 04:19.300
controller the idea is to

04:19.300 --> 04:22.200
have the equivalent as what you have for

04:22.200 --> 04:26.000
your smartphone by means of apps. So you the idea

04:25.200 --> 04:28.400
is that if you buy a piece of

04:28.400 --> 04:31.500
Hardware that is your controller, you can done

04:31.500 --> 04:34.400
go to a market and download apps that

04:34.400 --> 04:37.700
will actually satisfy or Implement certain

04:37.700 --> 04:40.300
types of policies you want. So you may have an app

04:40.300 --> 04:43.600
for security you may have an app that will specifically look

04:43.600 --> 04:46.200
at performance. So first of

04:46.200 --> 04:48.900
all, you have to make sure that this app is correct.

04:49.600 --> 04:53.500
and we know that this is already complicated to

04:52.500 --> 04:56.200
do this properly because you

04:55.200 --> 04:56.500
look at

04:57.500 --> 05:00.100
a whole network with many different kind of

05:00.100 --> 05:04.000
corner cases. But so let's assume we can do this. Well, so

05:03.200 --> 05:06.600
we have a correct application. It has

05:06.600 --> 05:09.600
to be correct and it has to be nonverbal. So

05:09.600 --> 05:14.000
it is should not be possible to take control

05:13.300 --> 05:16.300
over this application. So that's problem. Number one

05:16.300 --> 05:19.300
problem. Number two is now you have more than one

05:19.300 --> 05:20.000
app.

05:20.800 --> 05:24.000
Coexisting together in the controller and

05:23.100 --> 05:27.000
so they will receive information about hey

05:26.200 --> 05:29.500
there is this new flow coming in. What am

05:29.500 --> 05:32.200
I supposed to do? Am I supposed to Route it through this

05:32.200 --> 05:33.500
or through this path?

05:34.100 --> 05:37.300
And application number one may actually decide. Oh, this

05:37.300 --> 05:41.000
is from a security point of view. I think you should go through route

05:40.200 --> 05:43.700
number one, but the performance application says

05:43.700 --> 05:46.300
no, this is a streaming so

05:46.300 --> 05:49.600
it has to go through path number two. So you have

05:49.600 --> 05:52.800
to make sure that the composition of the

05:52.800 --> 05:55.100
various application decision.

05:56.300 --> 05:59.500
is eventually leading to something

05:59.500 --> 06:02.300
that you are happy with that that is

06:02.300 --> 06:06.000
consistent with some sort of meta policy

06:05.200 --> 06:08.500
that that you design and how to

06:08.500 --> 06:11.800
define these meta policies these this

06:11.800 --> 06:14.500
environment so to speak as to

06:14.500 --> 06:18.100
what your system should always do is not

06:17.100 --> 06:19.700
something very easy to do and

06:20.600 --> 06:23.800
ensuring the correctness of the composition

06:23.800 --> 06:26.800
of these application is also something pretty

06:26.800 --> 06:30.700
complicated to do properly, especially when

06:30.700 --> 06:33.400
you deal with the fact that some people may actually try

06:33.400 --> 06:34.600
to abuse them by

06:35.400 --> 06:38.400
By by sending by faking some

06:38.400 --> 06:41.600
sort of information for instance simple example. Let's

06:41.600 --> 06:45.900
assume you have one app, which is there to recognize flows

06:44.900 --> 06:48.600
that clearly are streaming video

06:47.600 --> 06:50.400
streaming and they say,

06:50.400 --> 06:53.300
for performance reason, they don't need to go through

06:53.300 --> 06:56.600
the intrusion detection system or through

06:56.600 --> 06:59.500
the fireworks to the firework, right? So for performance

06:59.500 --> 07:03.000
reason, so no need to check them, but then

07:02.200 --> 07:05.400
you have an another app that for

07:05.400 --> 07:08.400
security reasons says decides what needs

07:08.400 --> 07:11.100
to go through the firewall or not when you go to the

07:11.100 --> 07:11.700
outside world.

07:12.800 --> 07:13.600
to be checked

07:14.200 --> 07:17.200
So now if I can actually I'm a bad guy and I

07:17.200 --> 07:20.500
want to actually avoid being checked at the

07:20.500 --> 07:23.800
firewall in the for instance the web application firewall if

07:23.800 --> 07:24.900
I want to avoid that.

07:25.600 --> 07:27.100
if there is a way for me to

07:28.500 --> 07:31.400
pretend that my communication is actually

07:31.400 --> 07:35.000
a video streaming flow. Then

07:34.700 --> 07:37.800
I will be handled by the performance

07:37.800 --> 07:40.300
application and then automatically I

07:40.300 --> 07:43.800
will actually avoid the firewall so these things

07:43.800 --> 07:46.600
need to be taken into account properly to

07:46.600 --> 07:47.400
to avoid.

07:48.600 --> 07:51.400
to avoid sdn being

07:51.400 --> 07:53.200
misused by by the people, so

07:54.300 --> 07:57.600
And the complexity of the combination

07:57.600 --> 08:00.600
of all these application is

08:00.600 --> 08:04.700
something that that will potentially lead

08:03.700 --> 08:06.400
to systems that are even

08:06.400 --> 08:10.000
more difficult to really understand and if

08:09.100 --> 08:13.000
the bad guy is then manage managed

08:12.100 --> 08:15.200
to actually misuse a system, then he could actually

08:15.200 --> 08:18.800
run his attacks in a completely hidden way without anyone

08:18.800 --> 08:19.500
noticing it.

08:20.400 --> 08:23.200
Bypassing the security mechanisms that are in place.

08:23.200 --> 08:26.700
So there are a number of things that could go wrong with

08:26.700 --> 08:30.200
the sdn controller and the sdn Paradigm

08:29.200 --> 08:32.700
in general and just to be sure we understand

08:32.700 --> 08:35.400
sdn is a much overloaded term.

08:35.400 --> 08:39.000
So it has it's been used by many different people in different

08:38.600 --> 08:41.700
contexts. So when I speak sdn here

08:41.700 --> 08:44.200
I'm typically talking about sdn being

08:44.200 --> 08:47.500
used within an intranet so data center

08:47.500 --> 08:50.200
or an Enterprise Network or something like

08:50.200 --> 08:53.700
that. I'm not talking about sdn as some

08:53.700 --> 08:54.400
people call it.

08:56.200 --> 08:59.700
Even for you know core Network infrastructures or

08:59.700 --> 09:02.400
internet-wide systems. So

09:02.400 --> 09:05.600
that is that is another or even a

09:05.600 --> 09:09.200
5G when people talk about Network function

09:08.200 --> 09:11.100
virtualization and FV and so on

09:11.100 --> 09:14.300
that that's not what I'm talking about, even though similar problems occur there

09:14.300 --> 09:17.800
so in the case of sdn in

09:17.800 --> 09:20.800
a intranet in the land environment

09:21.900 --> 09:24.300
You definitely need to

09:24.300 --> 09:27.300
have network based intrusion detection in

09:27.300 --> 09:31.200
place to verify that whatever

09:30.200 --> 09:33.300
the sdn controller is

09:33.300 --> 09:36.400
deciding makes sense. And of

09:36.400 --> 09:39.400
course the whole difficulty is to decide what makes sense

09:39.400 --> 09:42.300
is so you need to have some sort of policy.

09:43.400 --> 09:46.700
As I was saying earlier on some invariant that

09:46.700 --> 09:49.500
says that kind of thing should never happen.

09:50.300 --> 09:54.100
And that's really difficult to Define. Right? So either you

09:53.100 --> 09:56.500
are able to do that and you say that kind

09:56.500 --> 09:59.500
of thing should never happen and my my

09:59.500 --> 10:01.900
network based introduction is going to verify that.

10:02.700 --> 10:05.300
That's really difficult. But that's one way of doing

10:05.300 --> 10:09.600
it. Another way of doing it is to say okay. I and

10:08.600 --> 10:11.400
this these are the two Paradigm in

10:11.400 --> 10:14.400
networking in intrusion detection. It's either knowledge base. So I

10:14.400 --> 10:17.100
know what the symptoms of a bad things

10:17.100 --> 10:18.700
are and I'm looking for them.

10:19.600 --> 10:22.800
The other way is behavior-based so I know how my

10:22.800 --> 10:25.300
network normally behaves and I'm looking for

10:25.300 --> 10:28.500
deviation thereof. So if you are capable of

10:28.500 --> 10:31.500
modeling the normal behavior of your networks

10:31.500 --> 10:33.100
in terms of flows and so on.

10:34.100 --> 10:39.000
And you model that and you are capable to check verify

10:37.100 --> 10:40.500
that this normal model

10:40.500 --> 10:43.900
is always the same or is

10:43.900 --> 10:46.200
evolving according to rules that you are happy with

10:46.200 --> 10:50.000
then you can also detect whenever

10:49.700 --> 10:52.100
if at some point and I'd have to

10:52.100 --> 10:55.300
comes in and takes advantage of sdn to change things.

10:56.700 --> 10:58.800
as long as those changes are

11:00.200 --> 11:03.300
Big enough to be noticeable, then you should be able

11:03.300 --> 11:06.300
to detect that so checking the networks and that's

11:06.300 --> 11:09.500
a big challenge how to do it is difficult. But that's something

11:09.500 --> 11:12.600
you have to do checking the networks by means

11:12.600 --> 11:15.600
either of invariants of behavior-based modeling

11:15.600 --> 11:18.300
or detecting symptoms of bad stuff

11:18.300 --> 11:19.200
is important.

11:21.200 --> 11:24.400
But you can also and you should also verify the

11:24.400 --> 11:27.800
Integrity of the controller and the controller

11:27.800 --> 11:30.600
and the applications running with the controller because

11:30.600 --> 11:34.200
we have already seen in the

11:34.200 --> 11:37.200
past a number of fernabies that have

11:37.200 --> 11:41.100
been identified in the software that was either the

11:40.100 --> 11:43.400
controller itself that was hosting the

11:43.400 --> 11:46.800
applications or in the application that we're that we're

11:46.800 --> 11:50.100
running within the controller. So it is

11:50.100 --> 11:53.500
very important to have some sort of security mechanism at

11:53.500 --> 11:57.200
the host level at the controller level to make sure that whatever software

11:56.200 --> 11:59.600
engine is running there is really the

11:59.600 --> 12:02.000
the software that that you wanted to run

12:02.300 --> 12:06.300
there and that it's not another process which has been found thanks

12:05.300 --> 12:08.600
to I don't know attack or

12:08.600 --> 12:09.500
something like that for instance.

12:10.600 --> 12:13.600
And last but not least as I said Also earlier

12:13.600 --> 12:16.300
on the single point of failure needs

12:16.300 --> 12:19.200
to be taken care of. So it's one thing

12:19.200 --> 12:22.300
to say. Oh, yeah, but I have a big machine and it's very

12:22.300 --> 12:25.300
safe and I'm looking at it but you know at some point if

12:25.300 --> 12:26.900
you know crashes happen.

12:27.500 --> 12:30.500
And so you need to make sure that you you have

12:30.500 --> 12:33.600
a duplicated site. And ideally you

12:33.600 --> 12:37.100
you actually need more than one copy. They are

12:36.100 --> 12:39.200
techniques to to do this to

12:39.200 --> 12:42.600
do this, you know, hot synchronizations of

12:42.600 --> 12:46.400
finest State machine. So to speak and most

12:46.400 --> 12:50.200
of them work pretty well with respect to Accidental Falls.

12:49.200 --> 12:54.500
Now when it comes to intrusions, it

12:53.500 --> 12:57.000
might be a bit more complicated because they're

12:56.600 --> 12:59.400
manifestation might not be immediate. So

12:59.400 --> 13:02.500
you probably need to have more than one copy.

13:02.500 --> 13:05.400
You probably try you need to be looking into all

13:05.400 --> 13:08.300
the techniques that have been using independability and

13:08.300 --> 13:12.100
intrusion tolerance mechanism. Maybe have

13:11.100 --> 13:15.300
copies that run on on the diversification

13:14.300 --> 13:18.300
using diversification for making

13:17.300 --> 13:20.300
sure that a given attack will not

13:20.300 --> 13:23.300
work on all the platforms and so on and so forth.

13:23.300 --> 13:26.800
So maintaining the Integrity of the

13:26.800 --> 13:27.400
cont.

13:27.400 --> 13:30.700
Error is is of key importance. But the

13:30.700 --> 13:33.900
need the sdn Paradigm comes with its bag

13:33.900 --> 13:37.200
of problems. But it also comes with a

13:36.200 --> 13:39.400
number of advantages from

13:39.400 --> 13:42.300
a security point of view. And so it is

13:42.300 --> 13:45.300
quite interesting that when you

13:45.300 --> 13:47.400
try to talk to people who

13:49.900 --> 13:52.300
are involved or have

13:52.300 --> 13:55.200
looked at sdn, either from a networking point of

13:55.200 --> 13:57.000
view or from a security point of view.

13:57.700 --> 14:01.600
you have very strong Defenders

14:00.600 --> 14:01.900
of

14:02.800 --> 14:05.800
Positions in favor or against so

14:05.800 --> 14:08.500
you have school of thought, you know networking people

14:08.500 --> 14:11.400
saying this is great. But also networking people saying

14:11.400 --> 14:15.100
this is bad security people saying this is great security

14:14.100 --> 14:18.100
people saying this is bad. So I have covered the whites

14:17.100 --> 14:20.700
bad but it's it's

14:20.700 --> 14:23.200
also important to recognize why might be good.

14:23.200 --> 14:26.400
And actually we with the colleagues we

14:26.400 --> 14:29.800
had organized a Dax tool seminars with with

14:29.800 --> 14:32.800
the art mode konik and Frank cargo.

14:32.800 --> 14:35.800
It's vendittrich and we actually published a

14:35.800 --> 14:38.500
small summary of all the discussions

14:38.500 --> 14:42.000
we have had with the the people from these

14:41.300 --> 14:45.100
two communities. We had something like a bit

14:44.100 --> 14:47.200
more than 30 people in in the room for a

14:47.200 --> 14:50.600
one week to discuss that and it's got the summary of

14:50.600 --> 14:53.800
the findings where publishing Security in

14:53.800 --> 14:56.600
privacy. And so when it

14:56.600 --> 14:59.500
comes to the positive aspects, we have to admit that

14:59.500 --> 15:02.200
as the end has also something to bring for instance.

15:02.900 --> 15:05.600
You can have a much finer grain

15:05.600 --> 15:09.100
and also Dynamic monitoring policy

15:08.100 --> 15:11.600
that you can apply you can say. Oh.

15:12.900 --> 15:15.500
this this flow normally I would

15:15.500 --> 15:16.200
do that but

15:17.100 --> 15:19.700
if certain parameters of that flow are

15:20.600 --> 15:23.300
the different you may decide no that specific

15:23.300 --> 15:26.100
flow. I will reroute it

15:26.100 --> 15:29.800
so that it goes through a certain amount of devices that

15:29.800 --> 15:32.600
will check certain properties

15:32.600 --> 15:35.200
more carefully more in depth

15:35.200 --> 15:38.500
and that treatment might be expensive. So you normally you

15:38.500 --> 15:41.900
would not afford to you would not be able to afford the

15:41.900 --> 15:44.800
cost for all the the

15:44.800 --> 15:47.200
similar requests, but maybe that specific one for

15:47.200 --> 15:50.100
whatever reason you you decide to go through and that's something you

15:50.100 --> 15:52.100
can do with this DN you can also

15:54.100 --> 15:57.600
Apply techniques like randomly sampling certain

15:57.600 --> 16:00.400
flows. So just just to

16:00.400 --> 16:03.800
be sure that you know by default you take that decision, maybe

16:03.800 --> 16:06.400
it for performance degree, isn't it goes through

16:06.400 --> 16:09.200
through the past

16:09.200 --> 16:12.600
that is not checked at all, but you want

16:12.600 --> 16:13.200
to make sure that

16:14.500 --> 16:17.600
Nobody is somehow taking advantage of

16:17.600 --> 16:20.000
that and from time to time randomly. You say

16:20.300 --> 16:23.100
okay that flow I'm gonna check it and and then

16:23.100 --> 16:26.300
maybe I not completely maybe I will move it back to some

16:26.300 --> 16:29.400
to its normal path, but just just

16:29.400 --> 16:32.300
to be sure as a deterrence mechanism as

16:32.300 --> 16:33.900
well with respect to the bad guys.

16:35.800 --> 16:38.300
That along the same line the fact that

16:38.300 --> 16:42.500
you you can apply Dynamic policies that when suddenly

16:41.500 --> 16:43.000
something.

16:44.200 --> 16:47.800
noticeable happens you can let's say

16:48.800 --> 16:51.600
There is a flow and it goes through the web

16:51.600 --> 16:54.600
application firewall to the internet, but the

16:54.600 --> 16:57.500
web the WAFF tells you a that looks like

16:57.500 --> 17:00.300
someone is trying to attack somebody else

17:00.300 --> 17:02.000
on the outside world for instance.

17:02.900 --> 17:05.200
You don't want that to happen. You

17:05.200 --> 17:08.200
don't want somebody from your own network to attack someone on the outside

17:08.200 --> 17:11.100
world. So typically what you would

17:11.100 --> 17:14.900
do is cut the connection and just you know, that's it. So you stop

17:14.900 --> 17:17.600
the attack. But if you do that, you are

17:17.600 --> 17:20.400
not capable of learning a lot about what this

17:20.400 --> 17:23.300
individual was trying to do or what

17:23.300 --> 17:26.700
is intense wear or maybe you have no time to actually trace

17:26.700 --> 17:29.700
it back. So what you can do is sdn is

17:29.700 --> 17:32.100
actually apply policies that says, okay. We are going to

17:32.100 --> 17:35.600
redirect that flow into a kind of a quarantine

17:35.600 --> 17:38.700
environment a fake Internet. So we will

17:38.700 --> 17:41.200
pretend that actually we will let him

17:41.200 --> 17:44.000
think that he's actually connecting to the internet whereas it is

17:44.100 --> 17:47.600
not and then we this will give us more information more

17:47.600 --> 17:50.400
time to record and monitor and analyze what

17:50.400 --> 17:51.300
actually it is doing.

17:52.200 --> 17:55.900
So this this is a way to implement easily

17:55.900 --> 17:58.400
horny Nets and elements like

17:58.400 --> 18:01.200
that and similarly you can do

18:01.200 --> 18:04.300
it the other way around when you have incoming connections and you're not quite

18:04.300 --> 18:07.800
sure if they are perfectly genuine, you

18:07.800 --> 18:10.200
may first start by directing them

18:10.200 --> 18:14.200
to something else and your operational Network and

18:13.200 --> 18:16.200
see first what they do

18:16.200 --> 18:19.400
and then if indeed everything is is okay, then

18:19.400 --> 18:22.600
you can maybe redirect them to the real operational system.

18:22.600 --> 18:25.500
But if instead they actually are trying

18:25.500 --> 18:28.200
to run a buffer overflow against your server or something like that,

18:28.200 --> 18:31.000
then nothing wrong with have happened because it was

18:31.200 --> 18:36.900
not the right system immediately. So you have a lot of flexibility and

18:36.900 --> 18:38.000
control which is

18:39.500 --> 18:42.200
Interesting from a from a security point of view

18:42.200 --> 18:45.800
more generally. There. There

18:45.800 --> 18:49.100
is this buzzword of moving Target defense where

18:48.100 --> 18:51.300
you you say people

18:51.300 --> 18:54.600
say instead of having the server always

18:54.600 --> 18:57.600
at the same place and people just can try again

18:57.600 --> 19:00.300
and again to break into it. We could actually have

19:00.300 --> 19:01.500
the server moving around.

19:02.800 --> 19:04.000
There are people who

19:04.900 --> 19:07.200
claim that sdn might be helpful for

19:07.200 --> 19:09.000
that. There is a lot of debate because

19:09.900 --> 19:13.200
The argument the counter argument is well, if

19:12.200 --> 19:15.600
the good guys can actually find the server

19:15.600 --> 19:18.400
why wouldn't the bad guys be able to find a servers the

19:18.400 --> 19:21.000
same way? It's a long debate. I don't

19:21.100 --> 19:24.400
want to go into that. But potentially let's say as

19:24.400 --> 19:28.800
the end might actually be helpful into into implementing

19:27.800 --> 19:30.400
a Solutions like

19:30.400 --> 19:30.600
that.

19:31.400 --> 19:31.500
So

19:32.600 --> 19:35.400
to summarize centralization is actually

19:35.400 --> 19:39.100
really good for visibility for

19:38.100 --> 19:42.900
quick reaction for fine-grained

19:41.900 --> 19:43.600
control of your network.

19:44.600 --> 19:48.200
But synchronization is also bad as

19:47.200 --> 19:50.700
it is a single point of failure. And now

19:50.700 --> 19:54.000
if actually anything happens

19:53.400 --> 19:56.900
being at the software or through denial

19:56.900 --> 20:02.500
of services or through stealthy flows

20:00.500 --> 20:05.000
being these

20:03.100 --> 20:06.600
guys as genuine one

20:06.600 --> 20:09.200
then bad things can really

20:09.200 --> 20:12.900
happen in your network and you definitely need if you implement sdn.

20:12.900 --> 20:16.700
You definitely need to also have intrusion detection

20:16.700 --> 20:19.500
component to make sure that things are working

20:19.500 --> 20:22.300
the way they should well it's in general. It's true.

20:22.300 --> 20:25.300
You need to have intrusion even the other networks, but it's even

20:25.300 --> 20:28.400
more so true in the Asian based environment.

Faculti AI can make mistakes

Research

Policy

Analysis