Transcript Improving Mobile Cor..

Improving Mobile Core Network
Security with Honeynets
IEEE Security & Privacy,
July-Aug. 2007, Issue 4, Volume 5,Page(s):40 - 47
Dimitriadis, C.K.;
University of Piraeus
Advisor: Frank Y. S. Lin
Presented by Yu-Shun Wang
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
2
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
3
Introduction


Despite improved security, core network
vulnerabilities continue to threaten thirdgeneration (3G) mobile systems.
To learn what security bottlenecks exist in the
3G network, we first introduce the network
architecture.
2016/4/12
OPLab@IM, NTU
4
Introduction

The 3G core network consists




circuit-switched (CS) domain
packet-switched (PS) domain
Internet Protocol (IP) multimedia subsystem (IMS)
This article focuses on the open security
issues in the PS domain.
2016/4/12
OPLab@IM, NTU
5
Introduction
Cause of vulnerabilities
Such vulnerabilities lead to threats
Lack of intrusion detection systems
billing attacks via gateway filters.
Inadequate firewall architectures
exposure of critical production systems
that implement packet switching to attacks.
No security layers
exposed GPRS elements used as
springboards for critical system attacks.
Uncontrolled communication with
roaming partners.
the mobile operator’s core network turned
into an extension of a roaming partner’s
core network, exposing both to serious
attacks.
2016/4/12
OPLab@IM, NTU
6
Introduction
2016/4/12
OPLab@IM, NTU
7
Introduction


The above figure gives an overview of the
systems in a 3G network affected by a
compromised SGSN or GGSN.
The security assessment described in this
article also revealed that legacy systems
which don’t provide adequate facilities for
logging user actions.
2016/4/12
OPLab@IM, NTU
8
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
9
Threat model


A threat model describes the threats that
attackers can realize by exploiting
vulnerabilities.
We can depict it graphically by using a
combination of attack trees, each of which
has a root node, leaf nodes, and child nodes.
2016/4/12
OPLab@IM, NTU
10
Threat model
2016/4/12
OPLab@IM, NTU
11
Threat model



In AG1, GTP packets with malformed headers
might lead to GSSN or SGSN compromise or
disruption (such attacks exploit badly
configured or nonexistent GTP firewalls).
The compromised GSSN or SGSN can become a
springboard on other critical systems.
Other attacks also exploit badly configured or
nonexistent GTP firewalls, often with the
same results.
2016/4/12
OPLab@IM, NTU
12
Threat model
No. description
2
the submission of non-matching addresses between the GTP payload and the
assigned address as defined in the Packet Data Protocol (PDP) context handshake.
3
a connection attempt from a roaming partner’s unauthorized or compromised
SGSNs or GGSNs.
4
an attempt to connect to target systems in administration ports.
5
an attempt to initiate a great many PDP contexts, which could result in the
disruption of a GGSN or SGSN, leading to loss of system availability.
6
a GTP packet with an invalid payload, which could result in packet spoofing and
non-permitted sessions.
7
a GTP packet with a payload that contains non-permitted source or destination
addresses, which can result in packet spoofing and non-permitted sessions.
8
an over-billing attack based on open sessions in which a specific IP address
requests data from a server and releases the IP address, which is then reassigned
to a new user. The new user keeps receiving the data and thus gets over-billed.
9
This AG focuses on insider attacks caused by uncontrolled communication
between critical systems.
2016/4/12
OPLab@IM, NTU
13
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
14
Feasibility study


To study the benefits of implementing
3GHNET, we used concepts from game
theory.
We wanted to compare a mobile operator
that implements a honeynet with one that
doesn’t, and then study different security
situations.
2016/4/12
OPLab@IM, NTU
15
Feasibility study


We defined a game called 3GHNET-G that is
non-cooperative—the mobile operators don’t
have a common security infrastructure, and
the game is static because players can make
simultaneous moves.
3GHNET-G is also a non-zero sum game,
meaning that the total benefit to all players
isn’t zero because there’s no relationship
between one player’s gain and another’s loss.
2016/4/12
OPLab@IM, NTU
16
Feasibility study


For our two players, mobile operator 1
(MO1) implements a honeynet architecture,
and mobile operator 2 (MO2) doesn’t.
Each player has two possible modes of
behavior, depending on whether a security
incident compromises the player’s nodes or
not:


Mode 1 represents compromised node behavior
Mode 2 represents normal node behavior
2016/4/12
OPLab@IM, NTU
17
Feasibility study


By following this logic we study the gain of
implementing a honeynet or not in
different security-related situations.
The payoff gets specific values from a
definite set P ={P1, P2, …, Pm}. Let each
possible payoff Pi (where i = {1, 2, …, m}) be
a sum of gains from Table 1, depending on a
specific condition.
2016/4/12
OPLab@IM, NTU
18
Feasibility study
These gains correspond
This corresponds to the knowledge
to the threats described
produced by a security architecture
in the previous section.
This is negative, corresponding to the
that can study attacks and evolve in
cost of implementing the honeynet
response to attacker tactics.
2016/4/12
OPLab@IM, NTU
19
Feasibility study



We define the payoff Pi through the following
equation: Pi = a1G1+a2G2+a3G3+a4G4+a5G5.
The parameters an={0, 1}, where n={1, 2, 3, 4,
5}, take a positive value when the player
receives the corresponding gain in a specific
condition and zero value in the opposite
scenario.
A game’s payoff matrix shows what payoff each
player will receive at the game’s outcome; it
depends on the combined actions of all
players.
2016/4/12
OPLab@IM, NTU
20
Feasibility study
MO1 receives all the gains.
MO2 only receives gain
G2 because it’s protected
by MO1’s honeynet.
MO1 doesn’t receive the
G2 gain because MO2 isn’t
attacking, but it receives
the rest of the gains.
MO2 receives gain G2.
MO1 receives gains G2,
G4, and G5, whereas
MO2 receives only gain G3
No player receives any
positive gain, and MO1
pays for the cost of the
honeynet.
2016/4/12
OPLab@IM, NTU
21
Feasibility study


The payoff matrix reveals two Nash equilibriums,
which we find by searching for the best player
response, taking as constant the best response of
the other player.
If MO2 is in an attack mode (greatest payoff = 10),
for example, then MO1’s attack mode is the one
with the greatest payoff (equal to 35).
2016/4/12
OPLab@IM, NTU
22
Feasibility study

Analyzing the game’s results, we conclude the following:




In the attack–attack situation, all players have a net benefit due to
the honeynet because overall security depends on the security of
others. This net benefit could be increased by the proliferation of
knowledge gained by MO1.
The two Nash equilibriums reveal that the implementation of a
honeynet is useful to both players in either situation.
If MO2 is compromised and forced to attack, MO1 clearly benefits
from implementing the honeynet.
MO1 gets the highest payoffs by implementing the honeynet,
except when security incidents don’t arise.
2016/4/12
OPLab@IM, NTU
23
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
24
3GHNET’s architecture


The first countermeasure would be to
separate the mobile operator’s
infrastructure into security zones.
each type of affected element goes in a
separate zone.
2016/4/12
OPLab@IM, NTU
25
3GHNET’s architecture
2016/4/12
OPLab@IM, NTU
26
3GHNET’s architecture

3GHNET’s honeywalls have the following characteristics:




3GHWALL_1 is a layer-2, non-IP-addressable element that controls and
captures data between emulated SGSN and GGSN and the mobile
operator and roaming partner’s real ones.
3GHWALL_ 1 block all traffic from inside 3GHNET to the core network
(or roaming partner).
3GHWALL_2 is a layer-2, non-IP-addressable element that controls and
captures data between emulated SGSN and GGSN and the Internet.
This honeywall also control and log traffic between the two interfaces,
Snort as an intrusion detection system for attacks from the Internet,
and Snort_inline in combination with Netfilter as an IDS for attacks
launched from the 3GHNET and targeted at the Internet.
2016/4/12
OPLab@IM, NTU
27
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
28
Security analysis

we performed several experiments to
emulate various attack scenarios:
2016/4/12
OPLab@IM, NTU
29
Security analysis



According to the threat model, the first security layer
is the establishment or improvement of GTP firewalls.
As a response, 3GHNET might directly address an
attack targeted to it or indirectly contribute to the
improvement of the existing GTP firewall configuration
through the knowledge gained by its operation.
The second security layer involves the emulation of
GGSNs or SGSNs: 3GHNET blocks an attack if it directly
targets the emulated GGSN and SGSN, or it can notify a
roaming partner about a possible compromise of its
infrastructure.
2016/4/12
OPLab@IM, NTU
32
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
33
Conclusion

A mobile operator can use our honeynet as:



A laboratory for security officers and engineers
to customize, build, and enhance a multilayer
security architecture.
A preventive, detective, and reactive security
architecture for the PS domain of a 3G core
network.
A way to transform a flat architecture into a
core network architecture separated into
security zones.
2016/4/12
OPLab@IM, NTU
34
Agenda







Introduction
Threat model
Feasibility study
3GHNET’s architecture
Security analysis
Conclusion
My applying model
2016/4/12
OPLab@IM, NTU
35
My applying model

Assumption



The defender has the complete information of network
that is attacked by several attackers with different
budget, capabilities, and strategy.
The attackers are not aware that there are honeypots
deployed by the defender in the network, i.e., the
attackers have the incomplete information of network.
There are two types of defense resources, the honeypot
and non-honeypot. Further, honeypots can be
subdivided into two categories, one is for wasting
attacker’s resource and learning their tactics, and the
other is used to play the role of fake core node to
distract the attackers.
2016/4/12
OPLab@IM, NTU
36
My applying model

Objective

Attacker:


The attackers want to compromise the core node
under budget constraint.
Defender:

The defenders want to minimize the average
compromised probability of the core node.
2016/4/12
OPLab@IM, NTU
37
My applying model

Given Parameter
Notation
Description
M
The total simulation times for all attacker categories
K
The index set of all attacker categories
D
Total possible defense strategies
The strategies of an attacker, including attack budget,
attacker’s capabilities and strategy for compromising
Ak
next hop.
1 if the kth attacker category can compromise the core
Sk(D , Ak ) node under defense strategy, 0 otherwise, where k
K
2016/4/12
OPLab@IM, NTU
38
My applying model

Decision Variable
Notation
D

Description
The strategy of defender to allocate defense
resource on each node in the network.
Objective function
min
D
 S ( D, A )
kK
k
k
M
subject to D  D
2016/4/12
OPLab@IM, NTU
39
My applying model

A possible scenario



we let D includes honeypots (both wasting attack
resource and distraction) and other defense
resource that raise the attack cost.
For concealing honeypots, we will add artificial
traffic in the network to make the amount of flows
seem balanced between nodes since attackers may
use link utilization as a guide to decide next
candidate node.
To accomplish this goal, we control the link
capacity and the routing of fake traffic to adjust the
utilization.
2016/4/12
OPLab@IM, NTU
40
My applying model

Given Parameter
Notation
Description
B
The total budget of defender
Bk
The total budget of kth type attacker, where kK
N
The index set of honeypots for wasting attacker’s
resource and learning their behavior
F
The index set of honeypots to play the role of fake
core nodes
The index set of all general nodes in the network
I
2016/4/12
OPLab@IM, NTU
41
My applying model

Decision variable
Notation
Description
bi
The budget allocated to protect on a node i, where i  I
hn
hf
rn
rf
The cost of honeypot n deployed in the network ,where
n N
The cost of honeypot f deployed as the fake core node
in the network, where f F
The cost of generating and routing fake traffic to a
honeypopt n in the network, where n N
The cost of generating and routing fake traffic to a
honeypopt f in the network, where f F
2016/4/12
OPLab@IM, NTU
42
My applying model

Decision variable
Notation
Description
cn
The cost of allocating capacity to a honeypopt n for
fake traffic in the network, where n N
cf
the cost of allocating capacity to a honeypopt f for
fake traffic in the network, where f  F
a(bi) The cost of attacking a general node i in the network,
where i  I
a(hn) The cost of attacking a honeypot n in the network,
where n N
a(hf) The cost of attacking a honeypot f in the network,
where f F
2016/4/12
OPLab@IM, NTU
43
My applying model

Constraint
 b   h   hn   rn   rf   cn   c f  B
i
f
iN
f F
n N
n N
f F
n N
f F
(IP 1.1.1)
0  bi  B
i  N (IP 1.1.2)
0  hf  B
f  F (IP 1.1.3)
0  hn  B
n  N (IP 1.1.4)
0  rn  B
n  N (IP 1.1.5)
0  rf  B
f  F (IP 1.1.6)
2016/4/12
OPLab@IM, NTU
44
My applying model
0  cn  B
n  N
(IP 1.1.7)
0  cf  B
f  F
(IP 1.1.8)
 a (b )   a (h )   a (h )  B
i
iI
nN
n
f F
f
k
(IP 1.1.9)
0   a (bi )  Bk
(IP 1.1.10)
0   a (hn )  Bk
(IP 1.1.11)
0   a (hf )  Bk
(IP 1.1.12)
iI
nN
f F
2016/4/12
OPLab@IM, NTU
45
My applying model


The above scenario is a special one that lead
our model clearer.
However, this framework can also be
applied in other situations for security
analysis.
2016/4/12
OPLab@IM, NTU
46/46
2016/4/12
OPLab@IM, NTU
47