Holistic identitybased networking security approach

An irreducible dichotomy between reality and expectations

Gawe Mikoajczyk gmikolaj@cisco.com

What this session is about

Holistic - 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, NACRADIUS, having goal of authenticating the user and machine, allowing access into the network and providing some more advanced functions

dichotomy between reality and expectations happens when you cannot achieve what you would like to have. Usually results in pain.

Fundamental IBNS Problem statement

I have a LAN/WAN/WLAN/VPN network,

I would like to authenticate users and their machines connecting to it.

Yeah, its 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:

CAPWAP & VLANs for wireless L2 VLANs for wired
Corporate Intranet

Outside DMZ

Firewall

Inside

Guest DMZ

Layer 3 isolation: VRF (Virtual Routing and Forwarding) to Firewall guest interface
WLC
CAPWAP

L3 Switches with VRF

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 Classification

Why 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 Only

What 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 IP

SNMP

Distributed Profiling: IOS Sensor

Switch Device Sensor Cache

Cisco IP Phone 7945

SEP002155D60133

Cisco Systems, Inc. IP Phone CP-7945G

SEP002155D60133

ISE 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 standarization

MACSec 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-256

Builds on 802.1X for Key Management, Authentication, and Access Control 802.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 deployed Intel AES-NI support in CPU (FIPS 140-2 Validated)

Encrypting everything Hop-by-Hop

Physical MiTM into the access link is a feasible attack using very small factor PC and others
The 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 Interconnect

Dual 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.1X 2. ISE is configured to send a TAG in the Authorization Result based on the ROLE of the user/device 3. The Switch Applies this TAG to the users traffic.

Data-plane SGT Enforcement with SGACL

User A User C

SGACL allows topology independent access control Even another user accesses on same VLAN as previous example, his traffic is tagged differently If traffic is destined to restricted resources, packet will be dropped at egress port of Context-Aware hardware devices domain

10
Campus Access

30
Packets are tagged with SGT at ingress interface

Context Hardware Enabled Network

SGACL-D is applied SQL = OK SMB = NO

SRC\ DST User A (10) User B (20)

Server A (111) Permit all SGACL-B

Server B (222) Deny all SGACL-C

Server C (333) Deny all Deny all

Data Center

User C (30)

Deny all
SGACL-D

Permit all

SGACL-D

RADIUS Server

Server A

Server B

Server C

Directory Service

111

222

333

SQL traffic SMB traffic SGACL

permit tcp src dst eq 1433 #remark destination SQL permit permit tcp src eq 1433 dst #remark source SQL permit permit tcp src dst eq 80 # web permit permit tcp src dst eq 443 # secure web permit deny all

How SGACL Simplifies Access Control

User Security Group (Source) Security Group (Destination) Servers D1 D2 Sales SRV (SGT 500)
MGMT B (SGT 20)

SGACL
S1
MGMT A (SGT 10)

S2

D3 HR SRV (SGT 600) D4

S3
HR Rep (SGT 30)

S4
IT Admins (SGT 40)

D5 Finance SRV (SGT 700) D6

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 transport

Problem statement: Not all devices are capable of 802.1AE and SGT

But, remember the session title holistic

We need to provide a way to transport context information Endpoint IP address to SGT binding

This needs to be separated, it is SecOps world Lets call this SXP SGT eXchange Protocol

Security Group Firewalling (SGFW) WAN use case

SGFW SXP
Enforcement on a headend SGACL Policies

Campus Network

SGFW
IP Address 10.1.10.1 SGT 10

Enforcement on a router

Data Center

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
Finance (SGT=4)
SGT=100

Ingress Enforcement

802.1X/MAB/Web Auth

Im an employee My group is HR

HR SGT = 100
S-IP User S-SGT

Egress Enforcement HR (SGT=100)

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 Authentication succeeds. Authorization assigns the SGT for the user. Traffic hits the egress enforcement point Only permitted traffic path (source SGT to destination SGT) is allowed
Pools of VMs WEB Server Cat4500

User A RDP

Connection Broker

802.1x

Auth=OK SXP SGT=10

Data Center

SRC \ DST User A (10) User B (20)

File Server(111) Permit all Deny all

Web Server (222) Deny All SGACL-C

File Server WEB Server SQL Server

Directory Service

ISE

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?
AD Member? Static List? MDM? Certificate?

AuthC Type
Machine Certs? User Certs? Uname/Pwd

Profile
i-Device Android Windows Other

AuthZ Result
Full Access i-Net only VDI + i-Net

Final thoughts Holistic Context-aware Security

Overlay security, which is network infrastructure-independent Confidentiality Enforcement and segmentation Scale Deployment flexibility Meaningful use cases

Maturity

Cisco system-level solution implementation is called Cisco TrustSec.. For more info, http://cisco.com/go/trustsec

THANK YOU.