Gaweł Mikołajczyk gmikolaj@cisco.com

Holistic identity-based networking security approach An irreducible dichotomy between reality and expectations

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, NAC-RADIUS, 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, 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

L3 Switches with VRF

Firewall

Outside

Global

Employee VRF

Guest VRF

CAPWAP

Internet

Isolation at access layer (port, SSID)

Layer 2 path isolation:

CAPWAP & VLANs for wireless

L2 VLANs for wired

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

Corporate Access Layer

Corporate

Corporate Intranet

Inside

DMZ

Guest DMZ

WLC

What about context-awareness at ingress?

Device Place User 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

RADIUS

DHCP

IP SNMP

Netflow

NMAP LLDP CDP

Sw

itch D

evic

e S

ensor

Cache

Distributed Profiling: IOS Sensor

Cisco IP Phone 7945

SEP002155D60133

Cisco Systems, Inc. IP Phone CP-7945G

SEP002155D60133

ISE

Pro

filin

g r

esult

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

PE Device

MPLS

DC-1 DC-2

vPC vPC

PE Device

PE Device PE Device

Using 802.1AE for data-plane context (SGT) transport

Cisco Meta Data

DMAC SMAC

802.1AE Header

802.1Q

CMD

ETYPE

PAYLOAD

ICV

CRC

Version

Length

CMD EtherType

SGT Opt Type

SGT Value

Other CMD Options

Encrypted

Authenticated

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)

802.1AE Header

CMD

ICV

Ethernet Frame field

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

Server C Server B Server A Directory Service

Campus Access

Data Center

Context Hardware Enabled Network

User A User C

111 222 333

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

30 10

SRC\ DST Server A

(111)

Server B

(222)

Server C

(333)

User A (10) Permit all Deny all Deny all

User B (20) SGACL-B SGACL-C Deny all

User C (30) Deny all Permit all SGACL-D

SGACL-D

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

Packets are tagged with SGT at ingress

interface

SGACL-D is applied SQL = OK SMB = NO

SMB traffic

SQL traffic

SGACL

RADIUS Server

How SGACL Simplifies Access Control

User

S1

D1

D2

D3

D4

D5

D6

S2

S3

S4

Servers Security Group

(Source)

MGMT A (SGT 10)

HR Rep (SGT 30)

IT Admins (SGT 40)

Security Group (Destination)

Sales SRV (SGT 500)

HR SRV (SGT 600)

Finance SRV (SGT 700)

MGMT B (SGT 20)

SGACL

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 –

Let’s call this SXP – SGT eXchange Protocol

Security Group Firewalling (SGFW) WAN use case

Campus Network

Data Center

SXP

IP Address SGT

10.1.10.1 10

SGFW

SGACL

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

Enforcement on a headend

Enforcement on a switch

SGACL Policies

SXP

SGFW

Enforcement on a router

Egress Enforcement

SGT=100

I’m an employee My group is HR

HR SGT = 100

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

HR (SGT=100)

Finance (SGT=4)

802.1X/MAB/Web Auth

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

SQL Server WEB Server File Server

Campus Access

Data Center

Cat4500 Directory Service

ISE

Connection Broker

Pools of VMs

• 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

RDP

802.1x

SRC \ DST File

Server(111)

Web Server

(222)

User A (10) Permit all Deny All

User B (20) Deny all SGACL-C

User A

WEB Server

SXP Auth=OK SGT=10

Applying Context-awareness to VDI

BYO* – stretching the NetOps and SecOps

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

You need to think it over.

Give the users flexibility to:

maintain their devices.

self-provision, register and delete

They will love you.

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.