Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OpenSec Policy-Based Security Using

  • Be the first to comment

  • Be the first to like this

OpenSec Policy-Based Security Using

  1. 1. By: Akshaya Arunan M1 NE [IT] GECBH Guided By: Simi Krishna K.R Assistant professor Dept. Of IT
  2. 2. OUTLINE  Objective  Introduction  Literature Survey  Proposed System  Conclusion  Reference 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 2
  3. 3. OBJECTIVE • An OpenFlow-based security framework • Allows a network security operator to create and implement security policies written in human-readable language. • Using OpenSec, the user can describe • a flow in terms of Open Flow matching fields, • define security services • specify security levels 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 3
  4. 4. INTRODUCTION • With the advent of software-defined networks (SDN) , efforts to automate and simplify network operation have become popular. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 4
  5. 5. Software Defined Network • Complexity of the network shifts towards the controller • Brings simplicity and abstraction to the network operator. • SDN decouples the control plane from the data plane • Migrates to a logically centralized software-based network controller. • Controller is network-aware. • Dynamic updating of traffic rules. 12/6/2016Government Engineering College, Barton Hill, Trivandrum 5
  6. 6. • New control functions is implemented by writing software-based logic in the control plane. • A network operating system (NOS) in the control plane maps the entire network to different services and applications. • SDN enhances network security • centralized control of network behavior, • global visibility of the network state and • run-time manipulation of traffic forwarding rules. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 6
  7. 7. 12/6/2016Government Engineering College, Barton Hill, Trivandrum 7 Simplified View of an SDN Architecture[2]
  8. 8. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 8 • Application Plane: Contains SDN applications for various functionalities. • Control Plane: It is a logically centralized control framework that • runs the NOS, • maintains global view of the network, and • provides hardware abstractions to SDN applications. • Data Plane: It is the combination of forwarding elements used to forward traffic flows based on instructions from the control plane.
  9. 9. 12/6/2016Government Engineering College, Barton Hill, Trivandrum 9 The three planes/ layers in the SDN architecture[3]
  10. 10. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 10 Layered view of networking functionality[2]
  11. 11. OpenFlow[4] • SDN protocol. • Communication protocol - intermediary - control and forwarding layer. • Standardizes the communication - a software-based controller and layer 2 switches - Open Flow channel. • An OpenFlow-compliant switch exposes an abstraction of its forwarding table to the Open Flow controller. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 11
  12. 12. • The controller can insert, delete or modify flows to the forwarding table of any device. • Flow table - match fields, an action and statistic data about the flow. • If packet does not match any rule, it is forwarded to the controller. • The controller can • listen to incoming packets, • push outgoing packets and • push new rules to the flow table of a switch. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 12
  13. 13. • An Open Flow Switch consists of at least three parts: • A Flow Table, • A Secure Channel • The Open Flow Protocol. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 13
  14. 14. LITERATURE SURVEY • Procera • Cloud Watcher • Fresco 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 14
  15. 15. Procera [5] • It is a controller architecture and high-level network control language. • Reactive - dynamic changes - network conditions. • Incorporates events (user authentications, time of day, bandwidth use) that originate from sources. • Both expressive and extensible. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 15
  16. 16. • Procera has the following features: • Controllers output flow constraint functions - controller - constrain its own behavior. • Customized with a collection of primitive event streams • Does not have access to Open Flow events (flow request events). 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 16
  17. 17. Cloud Watcher[6] • A security monitoring framework for the cloud. • Automatically detours network packets to be inspected by pre-installed network security devices like Open Flow. • A network operator can use a policy • describe a flow and • describe security services. • A cloud administrator can • select algorithms based on network status • can monitor his network by writing simple scripts. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 17
  18. 18. • Goal: • Provide routing algorithms • Provide a script language • A network administrator can easily • register security devices • define security policies 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 18
  19. 19. FRESCO[7] • OpenFlow-based security framework that exposes security modules to external users, who can in turn define security policies using such modules. • Each module includes five interfaces: • input, • output, • event, • parameter, and • action. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 19
  20. 20. • Similar to Procera - allows manipulating network events and handling them through pre-defined modules. • FRESCO exports a scripting API. • FRESCO currently includes a library of reusable modules. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 20
  21. 21. Proposed System • OpenFlow-based network security framework • Allows campus operators to implement security policies across the network. • Consists of • a software layer running on top of the network controller • multiple external devices that perform security services • report the results to the controller. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 21
  22. 22. • Goal: Allow network operators to describe security policies for specific flows in a human readable form automatically. • Policies: A description of the flow, a list of security services that apply to the flow and how to react in case malicious content is found. • Reaction: Alert only, or to quarantine traffic or even block all packets from a specific source. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 22
  23. 23. • Three design requirements of framework : [1] Moving middleboxes away from the main data path data plane: • Traffic should be processed by the processing units (network devices, middleboxes etc). • choke points of the topology traversed by all traffic. • located outside of the main path between the LAN and the Internet • should dynamically create rules to re-route traffic. 12/6/2016Government Engineering College, Barton Hill, Trivandrum 23
  24. 24. • In OpenSec, the controller is subject to • a low workload and is • responsible for implementing policies and • modifying forwarding rules based on the security alerts received from the processing units. [2] Reacting automatically to security events: • To reduce human intervention when suspicious traffic is detected. • It aims at automating this reaction - framework either blocks or alerts the operator. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 24
  25. 25. [3] Creating a Simple Policy Specification Language • To allow operators to redirect traffic to the middleboxes and to enable automated reaction. • Human-readable. • Simple. • Eg: • Three components can easily be identified: • the matching pattern, • the security units that must be visited by this flow and • the type of automated reaction. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 25
  26. 26. Opensec components 12/6/2016Government Engineering College, Barton Hill, Trivandrum 26 The OpenSec framework: • security functions are provided by the processing units, • traffic is routed to each processing unit based on requirements given through security policies, • the reaction to security alerts is automated.
  27. 27. 1] Policy Specification Language • Specifies a matching pattern, • a list of security units that should be traversed by such traffic and • an automated reaction in case of receiving a notification from a unit. 12/6/2016Government Engineering College, Barton Hill, Trivandrum 27
  28. 28. • The policy above specifies that all traffic tagged with VLAN 192 should be re- routed to the DPI unit. • Also, if the DPI middlebox informs of a suspicious sender, OpenSec must only alert the operator via e-mail. • Several match fields and several units can be listed when specifying the policy. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 28
  29. 29. 2] Northbound Interface • The current prototype of OpenSec includes a graphical user interface. • Left: All policies currently implemented and the buttons on the left allow for adding or removing a policy. • Right: Detailed policy is shown on top and the sources that have been blocked automatically using that policy are shown below. • The operator can unblock a source. 12/6/2016Government Engineering College, Barton Hill, Trivandrum 29
  30. 30. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 30 OpenSec’s graphical user interface. This interface allows the network operator to add, remove and view policies. It can also be used to re-authorize blocked sources
  31. 31. • A similar GUI is provided to the user to show the information of each registered processing unit, similar to the data shown on Table. 12/6/2016Government Engineering College, Barton Hill, Trivandrum 31
  32. 32. 3] Policy Manager • Core component of OpenSec. • Parses new policies sent by the GUI and converts them to OpenSec objects. • Implements policy using the southbound interface component (controller). • Checks periodically that the policy is implemented appropriately. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 32
  33. 33. 4] Processing Units • Relies on external processing units (or middleboxes) to analyze traffic. • Performs security scans, such as a firewall, an IPS or DPI. • Suspicious traffic – detected - alert to the OpenSec controller - existing policies. • All units must be known to the OpenSec controller. • A processing unit manager • collects all the registrations and • creates a list of units and the locations in the network where they can be found. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 33
  34. 34. 5] Security Event Processor • Automatic reaction to security alerts. • Defines such a reaction in advance using three possible choices: alert, quarantine or block. • The security event processor is responsible for • collecting the notifications issued by the processing units and • modifying forwarding rules according to the policies involved. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 34
  35. 35. 6] Open Flow Controller • Uses Open Flow to interface with the switches. • To do so, a module running in the Floodlight controller implements the required interfaces to listen to network events and communicate with switches. • When a request is received from the policy implementer to push a new rule, this module is responsible for sending the message to the right switches. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 35
  36. 36. 7] Data Repository • Stores several pieces of information. • Implemented policies are stored to check for conflicts when new policies are received. • information needed to route traffic to the middleboxes • How to react to security events raised by the processing units. • Records when hosts are blocked from accessing the network. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 36
  37. 37. Policy Implementation 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 37 Steps needed to implement a policy
  38. 38. Reacting to Security Event 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 38 Steps needed to react to security event
  39. 39. Advantages from existing systems • Procera and Frenetic: • how it reacts to security alerts raised by external units. • All reaction is defined by the code written by the operator - granular control - flow setup. • OpenSec hides such events from the operator and reacts automatically. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 39
  40. 40. • Cloud watcher: • How controller can find the optimal route to send the traffic to those processing units • policy language is not described in detail. • OpenSec allows the operator to describe how to react. • How to implement the policies instead of optimal routing decisions to find the processing units. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 40
  41. 41. CONCLUSION • An OpenFlow-based framework that allows network operators to describe security policies using human-readable language and to implement them across the network. • OpenSec allows for automated reaction to security alerts based on pre- defined network policies. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 41
  42. 42. • Several advantages of OpenSec: • moving the analysis of traffic away from the controller and into the processing units makes our framework more scalable. • moving the security controls away from the core of the network. • provides mirroring of traffic to monitoring devices. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 42
  43. 43. References 1. A. Lara and B. Ramamurthy, “OpenSec: A framework for implementing security policies using Open Flow,” in Proc. IEEE Globecom Conf., Austin, TX, USA, Dec. 2014. 2. Diego Kreutz, Member, IEEE, Fernando M. V. Ramos, “Software-Defined Networking: A Comprehensive Survey “IEEE, 2014. 3. Ijaz Ahmad, Suneth Namal, Mika Ylianttila,” Security in Software Defined Networks: A Survey”, IEEE 2015 4. N. McKeown et al., “Open Flow: Enabling innovation in campus networks,” SIGCOMM Comput. Commun. Mar. 2008. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 43
  44. 44. 5. A. Voellmy, H. Kim, and N. Feamster, “Procera: A language for high-level reactive network control,” in Proc. Workshop Hot Topics Softw. Defined Netw. (HotSDN), Helsinki, Finland, Aug. 2012. 6. S. Shin and G. Gu, “Cloud Watcher: Network security monitoring usingOpenFlow in dynamic cloud networks (or: How to provide security monitoring as a service in clouds?),” in Proc. 20th IEEE Int. Conf. Netw.Protocols (ICNP), Austin, TX, USA, Oct. 2012. 7. S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, and M. Tyson,“FRESCO: Modular composable security services for software defined networks,” in Proc. Netw. Distrib. Syst. Sec. (NDSS), San Diego, CA, USA, Feb. 2013. 12/6/2016 Government Engineering College, Barton Hill, Trivandrum 44

×