Lessons Learned from Federal ICAM

Applications of Identity, Credentialing, and Access Management

Joel Rader, CISSP – Solutions Architect

Agenda

• Introductions– Myself, and your interests as an interactive audience

• Federal History with ICAM

– How we arrived at today

• Enterprise Support

– Identity as a Cornerstone

• Use Cases

– Problems, Solutions, Lessons Learned

Introductions – Joel Rader

• 10 Years in Military and Federal Consulting

– Enterprise Architecture: Focus on identity

management

– PIV/CAC Credentials: Logical and physical access

• Biometrics (fingerprint, iris)

– Federation: Sharing of information among trusted

partners

– Radiant Logic: Why I’m Here

Affiliation

Employee

Agency/Department

Agency Name

Expires

2015JAN31

Contact

Chip

Lastname

Firstname, MI.

JAN2015United States Government

Introductions – Audience Questions

• What Applications of ICAM Interest You?

– Enterprise Architecture? Fundamentals?

– Smart Cards, compatibility with other organizations?

• Other credentials?

– Physical and Logical Access Convergence?

– Federation and Data Exchange?

– Interaction with Federal/State Government, Military?

– Federal Policy? Difficulties in Practical Implementation?

– How RadiantOne Can Enable Your Success?

– Internet of Things?

Federal History with ICAMHSPD-12 & OMB M-11-11

• HSPD-12– Released in August 2004, describes need for common identification

standard

– Leads to development of FIPS-201 (‘05) & PIV Card

– Defines common credentialing standard for Federal Employees & Contractors

• OMB M-11-11– Released in February 2011, requires PIV usage for physical and logical

access

– Agencies must accept and electronically verify other agency PIV credentials

– Standardization as a way to reduce costs and leverage buying power

Federal History with ICAMFICAM Highlights

• FICAM Roadmap and Implementation Guidance

– Version 1.0 released in November 2009, Version 2.0 in December 2011

– Describes a Segment Architecture, Use Cases, and Implementation Guidance

– Drives the development and implementation of interoperable solutions

– Builds out a Transition Roadmap and Implementation Guidance

– Goes beyond just using a standard credential, presents a high-level vision for the government

– NIST 800 series for guidelines, recommendations, and reference materials

Key Takeaway (FICAM Roadmap):

“ICAM efforts within the Federal Government are a key enabler for addressing the nation’s cybersecurity need.”

Federal History with ICAMSo Where Are We Today?

• Credential issuance is generally well understood

• Varying levels of implementation progress

• Guidance from HSPD-12, OMB M-11-11, FICAM,

others

• Significant educational progress across industry

But…. we’re not at a ideal state. Why?

Federal History with ICAMChallenges in Actual Implementation

• Many choices in vendor solutions, architecture designs, etc.

• Significant roadblocks in legacy system integration

• Every organization has unique population demographics

• Cybersecurity failings are a constant distraction

– OMB data breach (20+M records) and cyber “sprints”

• Disconnect between theory and reality

– Pretty pictures and architecture models aren’t actually helpful

– Enterprise architects need to tell you how at a finite level

– That said, DoDAF is a good documentation model to emulate

Department of Defense Architecture Framework

Identity as a CornerstoneWhat Happened to the “I” in ICAM?

• PIV is a credential, not an identity

• Identity should the primary focus for an organization

• Necessary to have high level support, from both

technology and policy

• You have to build a proper foundation first

Key Takeaway:

Identity is the cornerstone of an organization’s ICAM infrastructure

Identity Management System

Notification &Reporting

PerformanceMetric Analysis

Policy &Process Management

AuthoritativeAttributeExchange

Identity RecordDatabase

DataSegmentation

Identity as a CornerstoneBuilding a Digital Identity Record

• Context

– Must be useful, relevant, trustworthy

– Must uniquely identify a subject within a given context

• Consistent

– Must be able to be referenced uniformly across applications

– Where unique identifiers are not supported, mappings must be established

• High Assurance

– Trust that a Digital Identity represents an Identity

– Requires Identity Proofing, Vetting, and Adjudication

Identity as a CornerstoneWhat a Digital Identity Record Looks Like

• Building a Digital Identity Record

– Generating unique identifiers (RFC 4122, UUID)

• Add in credentialing and organization data blocks

– Biographic, Biometric, and Application

• Storing Identity Records – Authoritative Identity

Service

– Federation Support

– Data Sharing – Policy, Payload, and Protocol

Adjudication Results

Human Resources Attributes

Personal Identity Verification (PIV)

Credential Attributes

ClearanceCriminal

Sponsor

Name

Address

Hire Date

PositionMedical Compensation

Dependents

Status

Unique IdentifierUUID

AgencyIssue Date

FASC-NExpiration Date

Active Directory AttributesFull Name

Digital Identity Record

Application #1 AttributesUser ID Role

TitleEmail Company Department

Office

City

Identity as a CornerstoneWhat a Digital Identity Record Looks Like

Auditing and Reporting

Systems and Services

CONUS Employee

or Contractor

Application #1

Application #2

Human Resources (HR)

Information

Data Transfer Standards

(XML, SOAP, REST, TLS, SAML 2.0, etc.)

D1 D2 D3Data Elements

Policy

(Purpose, Owners, Legal, Data)

Phase 2

Create Digital

Identity

Notify

Application #3

(Phases 2 & 3)

Authoritative

Identity ServiceSystem or

Service

Active Directory

Authoritative Identity Service

Authoritative Attribute Sources

External User

Data Connection & Exchange Details

Phase 3

OCONUS User

Identity Management

System (IDMS)

External Source

(Phases 2 & 3)

Identity

Digital Identity

Universally Unique

Identifier Database

(UUID)

Federal Background

Investigation Systems

Digital Identity

Records

On-Boarding

Store

Send/Receive

AttributesProvide Attributes

Credential

Report

Access

Report

Hiring

Report

Accounts

and

Privileges

• Key Areas

– Onboarding/Offboarding

Processes

– Authoritative Sources of Data

– Application Usage

– Auditing/Reporting

• Policy, Payload, and Protocol

– Why we’re sharing

– What we’re sharing

– How we’re sharing

• Designed for Department of State

Identity as a CornerstoneWhat a Digital Identity Record Looks Like

Adjudication Results

Human Resources Attributes

Personal Identity Verification (PIV) Credential Attributes

ClearanceCriminal Background

Sponsor

Name

Address

Hire Date

PositionMedical Compensation

Dependents

Clearance

Unique Identifier

Human Resources (HR) Information

UUID

Cardholder Unique Identifier (CHUID)

Issue Date

FASC-NExpiration Date

Active Directory AttributesDisplay Name

Application #1

Application #2

Digital Identity Record

Application #2 AttributesUser ID Role

PKI AttributesIssue Date

Expiration DateCertificate

HiringReport

CredentialReport

Accountsand

Privileges

Title

Data Pull

Data Pull

Data Push

Da

ta C

on

nec

tio

n &

Exc

han

ge

Email Company Department

Office

City

Public Key Infrastructure (PKI) Issuance System

Global Address List (GAL)

Standardization Report

Data Pull

Identity Management System

(IDMS)

Active Directory

Authoritative Attribute Sources

Systems and Services

Auditing and Reporting

Att

rib

ute

Dis

cove

ry

Unique Identifier Generation System

Federal Background Investigation Systems

Phase 2 & 3 Attributes

Future Application #1Attribute 1

Attribute 2Attribute 3

Future Application #2Attribute 1 Attribute 2

• Building Digital Identity

Record

• Attribute Discovery

• Data Exchanges

• Applications can be both

sources and sinks for

attributes

Use CasesCredentialing in a Classified Environment

Unclassified Access - PIN #1, Proximity, Contactless

• Unclassified Physical Access

• Unclassified Logical Access via Unclassified PKI

Certificate

Classified Access - PIN #2 + Biometric (Iris or Fingerprint)

• Classified Logical Access via Classified PKI Certificate

Benefits

Maintains unclassified physical topology for privacy

PIV interoperability in unclassified environments

Single credential to track and support

Allows for multi-factor classified access

No direct link between identities if card compromised

Maintains separate PKI certificate revocation status

Affiliation

Employee

Agency/Department

Agency Name

Expires

2015JAN31

Contact

Chip

Lastname

Firstname, MI.

JAN2015United States Government

Customized chip firmware & middleware

Use CasesAmtrak Enhanced Employee ID (EID)

Affiliation

Employee

Agency/Department

National Railway

Passenger

Corporation

Expires

2015JAN31

Contact

Chip

Lastname

Firstname, MI.

16026722-1A 44742

IF FOUND, PLEASE RETURN BY DROPPING IN A MAILBOX. RETURN POSTAGE GUARANTEED

Return To:National Railroad PassengerCorporation (AMTRAK)P.O. Box 2597Washington, DC 20013

Bac

k o

f

Co

nta

ct

Ch

ipTo report a crime or suspicious activity, call the AMTRAK Police at 1-800-331-0008

• Problem: Need a modern credential to replace legacy

• PIV Card or TWIC?

• Why choose PIV? Need compatibility

• PIV Card, PIV-I, PIV-C, what are the differences?

• Design considerations for security and roles

• Non-Federal Credential Decisions

• Form factor

• Multi-factor authentication

• Mobile devices

Use CasesEnterprise Physical Access Control Systems (ePACS)

Data Cache & Reconciliation

1:N

Facility PACSServer

PIV / PIV-I Readers

Enterprise SAFE

IdentityData

Active Directory

PIV System /

Non-PII Store

Credential Management System

ENTERPRISE SYSTEMS

ENTERPRISE PACSMANAGEMENT

Door & PanelHardware

Single PACS Facility

Validation Authority

RS-485

Facility PACS Server (Virtualized)

Local SAFE PACS Head-End

Local Facility Data

*optionalOther Facility

PACS

Local Enrollment

Console(s)

PersonnelDashboard *optional

Enterprise Local Facilities

SAFE

NOTES: Local SAFE (Optional) – Allows for future connectivity to an enterprise

version of SAFE to be streamlined Top PACS Server – A “reference” build can be established for new sites to

allow for quick deployment and integration

NOTES: Data Cache and

Reconciliation – Allows for authoritative data to be provided for PACS

Enterprise SAFE – Allows for Facility PACS to stay local, but leverage Enterprise data