Gaweł mikołajczyk. holistic identity based networking approach – an irreducible dichotomy between reality and expectations
 

Gaweł mikołajczyk. holistic identity based networking approach – an irreducible dichotomy between reality and expectations

on

  • 141 views

 

Statistics

Views

Total Views
141
Views on SlideShare
141
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Gaweł mikołajczyk. holistic identity based networking approach – an irreducible dichotomy between reality and expectations Gaweł mikołajczyk. holistic identity based networking approach – an irreducible dichotomy between reality and expectations Presentation Transcript

    • Holistic identity-based networkingsecurity approachAn irreducibledichotomy betweenreality andexpectations Gaweł Mikołajczyk gmikolaj@cisco.com
    • What this session is aboutHolistic - a. Emphasizing the importance of the whole and the interdependence of its parts.Identity-Based Networking Security (IBNS) – concepts including 802.1X,CPS, CTS, IBNS, NAC, NPF, NAC Framework, NAC Appliance, OneNAC, NAC-RADIUS, having goal of authenticating the user and machine, allowing accessinto the network and providing some more advanced functionsdichotomy between reality and expectations happens when you cannotachieve what you would like to have. Usually results in pain.
    • Fundamental IBNS Problem statementI have a LAN/WAN/WLAN/VPN network,I would like to authenticate users and their machines connecting to it.Yeah, it’s been solved 10+ years ago.But seriously,...did you try to deploy it (except for WLAN, hands-up please)?...and succeeded? No, but why?
    • What we were lacking, really?Usability and phased deployment options Open, Low Impact, High Security, IP Telephony, dACL, dVLAN, MDA, unmanaged device, Critical, WoL, EAP methods of choice (w/PKI)Flexible wired/wireless authentication options and ordering of those. MAC Authentication Bypass (MAB), 802.1X, Web Authentication (WebAuth)? Guests? Provision. Bridge them to the Internet. Segment and AUP control.System-level testing. OS-1 + Supplicant-2 + Switch-3 + RADIUS Server-4 Funny/Scary, it is totally enough to create a massive DoS + bonus RGE. Vendor should prove it works as documented (and is documented)
    • Guest Deployment and Path Isolation Internet Isolation at access layer (port, SSID) Layer 2 path isolation: Outside  CAPWAP & VLANs for wireless Corporate DMZ Firewall Intranet  L2 VLANs for wired Inside Guest DMZ Layer 3 isolation: VRF (Virtual Routing and Forwarding) to Firewall L3 Switches with VRF guest interface WLC CAPWAP Corporate Corporate Access Layer Guest VRF Employee VRF Global
    • What about context-awareness at ingress? User Device Place Posture Time Access method Other
    • Profiling: The Art of Device ClassificationWhy Classify? Originally: identify the devices that cannot authenticate and automagically build the MAB list. i.e.: Printer = Bypass Authentication Today: Now we also use the profiling data as part of an authorization policy. i.e.: Authorized User + i-device = Internet OnlyWhat is performing the data collection and what can be collected? Dedicated collection devices or existing infrastructure? Must traffic pass inline? CDP/LLDP? SNMP data? DHCP? RADIUS? Packet capture for deeper analysis? HTTP user-agent? Active Polling/Scanning. NMAP?
    • Profiler conditions to build your policies upon NMAP DHCP LLDP CDP Netflow RADIUS SNMP IP
    • Distributed Profiling: IOS Sensor Switch Device Sensor Cache Cisco IP Phone 7945 SEP002155D60133 Cisco Systems, Inc. IP Phone CP-7945G SEP002155D60133ISE Profiling result
    • Profiler Library you can extend and tune Cont ….
    • Ingress control is just the beginning„I have authenticated an endpoint coming to my network.”It is in the proper VLAN, has (d)ACL applied. I have provided enforcement. (BTW. It is easy to overrun hardware ACL TCAM switch resources.)I want to do with the traffic much more: Provide differentiated treatment from the security point of view.I want to make use of the context in the whole network.Make all my devices (switches, routers, firewalls...) context-aware.How to propagate the context information in the network?
    • Bright idea: looking at IEEE standarizationMACSec is a Layer 2 encryption mechanism (Ratified in 2006) 802.1AE defines the use of AES-GCM-128 as the encryption cipher. Cisco is working to extend to AES-GCM-256Builds on 802.1X for Key Management, Authentication, and Access Control802.1X-2010 defines the use of MACSec, MACSec Key Agreement (MKA) (Previously 802.1AF), and 802.1AR (Ratified in 2010)Authenticated Encryption with Associated Data (AEAD)HW implementations run are very efficient 1G and 10G line rate crypto currently deployedIntel AES-NI support in CPU (FIPS 140-2 Validated)
    • Encrypting everything Hop-by-HopPhysical MiTM into the access link is a feasible attack using very small factor PC and othersThe attacks have been demonstrated (DEFCON19 – A Bridge Too Far).802.1X EAP authentication phase is used to derive the 802.1AE session key for encryption.Encryption can be done in software and in hardware on the endpoint.Switch crypto support in hardware is necessary
    • Massively Scalable Encrypted DataCenter InterconnectDual Access with EoMPLS Connectivity DC-1 DC-2 PE Device PE Device vPC vPC MPLS PE Device PE Device
    • Using 802.1AE for data-plane context (SGT) transport Authenticated Encrypted DMAC SMAC 802.1AE Header 802.1Q CMD ETYPE PAYLOAD ICV CRC CMD EtherType Version Length SGT Opt Type SGT Value Other CMD Options Cisco Meta Data Ethernet Frame field  802.1AE Header CMD ICV are the 802.1AE + Context (SGT) overhead  Frame is always tagged at ingress port of Context-(SGT)-capable device  Tagging process prior to other L2 service such as QoS  No impact IP MTU/Fragmentation  L2 Frame MTU Impact: ~ 40 bytes, less than baby giant frame (~1600 bytes | 1552 bytes MTU)
    • How to impose SGT at ingress?A Role-Based TAG:1. A user (or device) logs into network via 802.1X2. ISE is configured to send a TAG in the Authorization Result – based on the “ROLE” of the user/device3. The Switch Applies this TAG to the users traffic.
    • Data-plane SGT Enforcement with SGACL SGACL allows topology independent User A User C access control  Even another user accesses on same VLAN as 10 30 previous example, his traffic is tagged differently Packets are tagged  If traffic is destined to restricted resources, packet will Campus Access with SGT at ingress be dropped at egress port of Context-Aware hardware interface devices domain Context Hardware Server A Server B Server C SRC DST Enabled Network (111) (222) (333) SGACL-D is applied User A (10) Permit all Deny all Deny all SQL = OK SMB = NO User B (20) SGACL-B SGACL-C Deny all Data Center User C (30) Deny all Permit all SGACL-D SGACL-D RADIUS Server permit tcp src dst eq 1433 #remark destination SQL permit permit tcp src eq 1433 dst Server A Server B Server C Directory #remark source SQL permit Service permit tcp src dst eq 80 111 222 333 # web permit SQL traffic permit tcp src dst eq 443 SMB traffic # secure web permit SGACL deny all
    • How SGACL Simplifies Access Control Security Group Security Group User (Source) (Destination) Servers SGACL D1 S1 MGMT A D2 (SGT 10) Sales SRV (SGT 500) S2 MGMT B D3 (SGT 20) S3 HR SRV D4 (SGT 600) HR Rep (SGT 30) S4 D5 Finance SRV IT Admins D6 (SGT 700) (SGT 40) This abstracts the network topology from the policy Reduces the number of policy rules necessary for the admin to maintain Allows to overcome traditional access switches TCAM limits
    • Control-plane (SGT) context transportProblem statement: Not all devices are capable of 802.1AE and SGT But, remember the session title – holisticWe need to provide a way to transport context information Endpoint IP address to SGT bindingThis needs to be separated, it is SecOps world – Let’s call this SXP – SGT eXchange Protocol
    • Security Group Firewalling (SGFW) WAN use case SGFW Enforcement on a headend SGACL Policies SXP Campus Network SGFW IP Address SGT Enforcement on a router Data Center 10.1.10.1 10 SGACL SXP Enforcement on a switch Consistent Classification/enforcement between SGFW and switching. SGT allows more dynamic classification in the branch and DC WAN edge Valid deployment model on devices lacking hardware MACSec/SGT support Scales to thousands of branches
    • Security Group Firewalling (SGFW) Data Center use case Extends the context-awareness Concept to the firewall Use Security-Group Tags (SGTss) in your Firewall Policy Removes concern of ACE explosion on DC Firewalls Ingress Enforcement Finance (SGT=4) SGT=100 802.1X/MAB/Web Auth I’m an employee HR SGT = 100 My group is HR Egress Enforcement HR (SGT=100) S-IP User S-SGT D-IP D-SGT DENY
    • Context-aware firewalling DC use case Source SGT Destination SGT Think of making context-aware other network security services: intrusion prevention, load-balancing, web security, web/file/database application firewalling
    • Applying Context-awareness to VDI Campus Access• User logs into VM which triggers 802.1x authentication User A• Authentication succeeds. Authorization RDP assigns the SGT for the user.• Traffic hits the egress enforcement point Connection Broker Auth=OK Data Center• Only permitted traffic path (source SGT SXP to destination SGT) is allowed 802.1x SGT=10 Pools of VMs WEB Server Cat4500 Directory File Web Server Service SRC DST Server(111) (222) User A (10) Permit all Deny All File Server WEB Server SQL Server ISE User B (20) Deny all SGACL-C
    • BYO* – stretching the NetOps and SecOps You need to think it over. Give the users flexibility to: maintain their devices. self-provision, register and delete They will love you. Corp Asset? AuthC Type Profile AuthZ Result• AD • Machine • i-Device • Full Access Member? Certs? • Android • i-Net only• Static List? • User Certs? • Windows • VDI + i-Net• MDM? • Uname/Pwd • Other• Certificate?
    • Final thoughts – Holistic Context-aware SecurityOverlay security, which is network infrastructure-independent Confidentiality Enforcement and segmentation Scale Deployment flexibility Meaningful use cases MaturityCisco system-level solution implementation is called Cisco TrustSec.. For more info, http://cisco.com/go/trustsec
    • THANK YOU.