Gaweł Mikołajczyk [email protected]
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
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?
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
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