1 / 45

Improving Mobile Core Network Security with Honeynets

Improving Mobile Core Network Security with Honeynets. Dimitriadis, C.K.; University of Piraeus. IEEE Security & Privacy, July-Aug. 2007, Issue 4, Volume 5,Page(s):40 - 47. Advisor: Frank Y. S. Lin Presented by Yu-Shun Wang. Agenda. Introduction Threat model Feasibility study

ursala
Download Presentation

Improving Mobile Core Network Security with Honeynets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Improving Mobile Core Network Security with Honeynets Dimitriadis, C.K.; University of Piraeus IEEE Security & Privacy, July-Aug. 2007, Issue 4, Volume 5,Page(s):40 - 47 Advisor: Frank Y. S. Lin Presented by Yu-Shun Wang

  2. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  3. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  4. Introduction • Despite improved security, core network vulnerabilities continue to threaten third-generation (3G) mobile systems. • To learn what security bottlenecks exist in the 3G network, we first introduce the network architecture. OPLab@IM, NTU

  5. 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. OPLab@IM, NTU

  6. Introduction OPLab@IM, NTU

  7. Introduction OPLab@IM, NTU

  8. 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. OPLab@IM, NTU

  9. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  10. 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. OPLab@IM, NTU

  11. Threat model OPLab@IM, NTU

  12. 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. OPLab@IM, NTU

  13. Threat model OPLab@IM, NTU

  14. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  15. 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. OPLab@IM, NTU

  16. 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. OPLab@IM, NTU

  17. Feasibility study • For our two players, mobile operator 1 (MO1) implementsa honeynet architecture, and mobile operator 2(MO2) doesn’t. • Each player has two possible modesof behavior, dependingon whether a security incident compromises theplayer’s nodes or not: • Mode 1 represents compromised node behavior • Mode 2 represents normal node behavior OPLab@IM, NTU

  18. 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. OPLab@IM, NTU

  19. Feasibility study These gains correspond to the threats describedin the previous section. This corresponds to the knowledgeproduced by a security architecture that can studyattacks and evolve in response to attacker tactics. This is negative, corresponding to the cost of implementingthe honeynet OPLab@IM, NTU

  20. Feasibility study • We define the payoff Pi through the following equation:Pi = a1G1+a2G2+a3G3+a4G4+a5G5. • The parametersan={0, 1}, where n={1, 2, 3, 4, 5}, take a positivevalue when the player receives the corresponding gain in aspecific condition and zero value in the opposite scenario. • A game’s payoff matrix shows what payoff each playerwill receive at the game’s outcome; it depends on thecombined actions of all players. OPLab@IM, NTU

  21. 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. OPLab@IM, NTU

  22. Feasibility study • The payoff matrix reveals two Nash equilibriums, which we find by searching for thebest 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). OPLab@IM, NTU

  23. 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 benefitsfrom implementing the honeynet. • MO1 gets the highest payoffs by implementing the honeynet, except when security incidents don’t arise. OPLab@IM, NTU

  24. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  25. 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. OPLab@IM, NTU

  26. 3GHNET’s architecture OPLab@IM, NTU

  27. 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 3GHNETto 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. OPLab@IM, NTU

  28. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  29. Security analysis • we performed several experiments to emulate various attack scenarios: OPLab@IM, NTU

  30. 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. OPLab@IM, NTU

  31. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  32. 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. OPLab@IM, NTU

  33. Agenda • Introduction • Threat model • Feasibility study • 3GHNET’s architecture • Security analysis • Conclusion • My applying model OPLab@IM, NTU

  34. 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. OPLab@IM, NTU

  35. 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. OPLab@IM, NTU

  36. My applying model • Given Parameter OPLab@IM, NTU

  37. My applying model • Decision Variable • Objective function subject to OPLab@IM, NTU

  38. My applying model • A possible scenario • we let 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. OPLab@IM, NTU

  39. My applying model • Given Parameter OPLab@IM, NTU

  40. My applying model • Decision variable OPLab@IM, NTU

  41. My applying model • Decision variable OPLab@IM, NTU

  42. My applying model • Constraint OPLab@IM, NTU

  43. My applying model OPLab@IM, NTU

  44. 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. OPLab@IM, NTU

  45. Thanks for your listening OPLab@IM, NTU

More Related