Office of Information Technologies

Christopher Misra

April 2008

Bridging Security and Identity Management

2

Bridging Security and Identity Management

CAMP event • February 13–15, 2008• Tempe Mission Palms, Tempe, Arizona

This workshop offered interactive education and guidance to higher education CIOs and IT managers, IAM architects, security professionals, and application developers.

Institutions sent cross-functional teams, particularly from the IAM and security areas, to work through the planning process together.

http://www.educause.edu/camp081

3

Bridging Security and Identity Management

How do we enhance privacy and security through identity management?

How do we enhance compliance activities through identity management?

How do we secure and protect our identity management infrastructure from rogue applications?

What does it mean to move application security over to our identity management systems?

What does federated identity management mean in terms of privacy, security, and compliance?

4

Common Goals

Security services traditionally focus on preventing badness• protective, defensive and reactive tools and techniques.

Middleware provide infrastructure services that enhance security• identification, authentication, and authorization.

A comprehensive security architecture is necessary to align these services to meet an organization's security needs.

We are trying to solve many of the same problems

5

Traditional Middleware Drivers

Services that enable secure access to networks, services, and applications• Identification• Authorization• Authentication• Directories• Audit

Leveraging enterprise identity and access data to enable business processes

6

Current threat environment

We have traditionally focused our security efforts on systems• Managed or unmanaged

The current and emerging threat environment changes some of our focus to data and privilege• Web-based application assessment

• Cross-site scripting, SQL injection• Data leakage and extrusion prevention

• The risk is in the data, not just the systems• Privilege escalation

• Who manages the assignment of privilege?

7

Security or Middleware?

How do campuses securely provide access to these applications?• Identity and Access Management systems

How do we detect abuse of these applications?• Audit• Log correlation and data orchestration

Why is this our problem?• Aren’t you the Information security officer?• Who gets the phone call when data leaks?

8

The changing security landscape

In security we have a continually changing landscape• Network worms aren’t very interesting any more• We can detect and shut off a port scanner in minutes

Vendor patches have solved many of our Operating System problems• Sometimes very slowly

Application vulnerabilities abound• Cataloging which applications we own and/or operate is

a daunting task• Securing these applications is more daunting

9

Current threat environment

I won’t claim that we have solved all of our systems security problem• Otherwise known as job preservation

However, the environment has changed. The focus should be on the behavior that we don’t understand or manage as well• Everyone wants their own application• Those who operate these applications frequently do not

have a strong security background• Assignment of privilege is decentralized and often

poorly managed

10

How do security and middleware intersect?

We’ve built strong defenses against those outside our organization• And those we don’t trust inside our organization

(ResNet, certain Departments)

Data leakage occurs from inside as often as outside• Faculty posting FERPA protected data on public

websites• Staff posting financial data publicly

Understanding how privilege is granted and managed is key to defending these data and information services

11

Where do security staff see concerns?

SQL injection attacks aside, who provisions access to your critical applications?• How secure are those provisioning applications?• Can you locate and parse the logs and audit trails?

All these applications and authentication services generate a lot of logs• Can you correlate across these disparate applications

and authentication logs?• Can you further correlate these applications against

network-centric data sources?

12

Middleware we all know

Authentication systems• Password files, Kerberos, Directory services (LDAP)• Logs that we use daily to identify those who chose the

dark side• Or just can’t manage their own workstation

Authorization systems• Southwestern Netreg, CMU Netreg, etc• Perhaps not strictly authorization, but they associate a

privilege with an entity (or identity)• User bob registered (authorized) this device on the

campus network• Again used daily

13

Middleware we might already

Data orchestration • GULP • Correlating the behavior of a user across disparate

systems and networks• Understanding how a user should behave

Audit systems• SIM/SEM

• If you have the budget or programmers• NetFlow

• Not middleware, but a correlation point we use to map bad behavior to other sources.

14

Middleware we may come to love (or hate)

Weblogin• Pubcookie, Cosign, JASIG CAS, etc • Web-based authentication services• Limited disclosure of user credentials to less trusted

applications• Often cookie-based tokens encrypted with symmetric

keys shared between the application and the weblogin service

• Some provide authorization functionality

15

Middleware we may come to love (or hate)

Shibboleth• “standards-based, open source middleware software

which provides Web Single SignOn (SSO) across or within organizational boundaries.”

http://shibboleth.internet2.edu/

• Web-based authentication and policy-based attribute exchange framework for authorization• Can also leverage existing weblogin services

• Provides both campus-based and inter-campus federated authentication and authorization

• Highly privacy preserving• Which can make incident response more challenging

16

Middleware we may come to love (or hate)

Signet• A privilege management service • Provides centralized management of user privileges

across a range of applications.• a standard user interface for privilege administrators• integration with core campus organizational data• improved visibility, understandability, and auditability of

privilege information

17

Middleware Definitions

Federations• “A federation is an association of organizations that use

a common set of attributes, practices and policies to exchange information about their users and resources in order to enable collaborations and transactions”

http://www.incommonfederation.org/docs/guides/faq.cfm

• Fundamentally a policy construct • Combined with a technical toolset

• Often implemented with the Shibboleth toolset in R&E networks

• Provides access to local campus resources to users from remote institutions

18

What concerns me about middleware?

Federations • Seem to be fairly unstoppable

• And I argue to strongly support them on my campus• But it means my user base no longer includes only

individuals that are directly affiliated with my campus• For web applications• For network access

• How do I identify a user from a remote institution• Especially in the environment of a privacy-preserving

technology like shibboleth• How do I handle an incident when the offending user

belongs to another campus• And I may not even know their username

19

What I like about middleware

Integrating incident response workflow with institutional IdM infrastructure• Leveraging campus directory services to provide more

timely and accurate incident notification• Integrating incident response in the campus workflow

applications (Remedy, RT) Federations

• Policy-based management of privilege for intra and inter-institutional applications and resources• Privileges may no longer be provisioned by the grad

student in the chemistry department who hasn’t worked here in 5 years.

• But there remains a lot of work to get here

20

What I like about middleware

Log correlation and data orchestration• There are two presentations here today specifically

focusing on the value and use cases for managing these data well

• And deriving actionable knowledge from them

Audit trails• IdM systems provide a better mechanism of

enumerating goodness• For credential provisioning and privilege management

Additive to traditional security mechanisms• These tools and technologies improve operational

security awareness

21

What else can we do with middleware

Asset identification• Knowing what assets you are trying to protect is a

precondition to properly securing them• Determining ownership and responsible parties

facilitate incident response and remediation• Integrating asset identification with campus identity

management lifecycles ensure continuity of responsibility

22

Confidential Data Handling Blueprint

1. Create a security risk-aware culture that includes an information security risk management program

2. Define institutional data types3. Clarify responsibilities and accountability for safeguarding

confidential/sensitive data4. Reduce access to confidential/sensitive data not absolutely

essential to institutional processes5. Establish and implement stricter controls for safeguarding

confidential/sensitive data6. Provide awareness and training7. Verify compliance routinely with your policies and proceduresFrom: https://wiki.internet2.edu/confluence/display/secguide

Middleware can not be extracted from this process, compliance may be the bridging function

23

Themes and conclusions

Security and Middleware staff need to be engaged with IdM design and implementations• Working with them now may both prevent bad things

and even facilitate good things• We are probably trying to solve some of the same

problems

Educating your user community about realigned middleware drivers is in our collective interest• Preventing data leakage from poorly managed

applications and authorizations

24

Themes and conclusions

Federations need to be understood in the context of operational security needs• How aware are security staff of current federation

activities on your campus?• Embracing these technologies may improve our overall

security posture

Identity Management is a complementary technology to our security toolkits• Integrating business processes with security

requirements• Authentication and authorization are a necessary, but

not sufficient, condition for secure applications

25

Themes and conclusions

Audit and log correlation will allow us to maintain situational awareness• In our increasingly complex environments• Additional abstraction layers is rendering many

traditional detective techniques less effective• Orchestrating logs across systems provides visibility

that many of us don’t currently have Privilege management

• Assignment of authorizations places more of our data at risk of disclosure

• A next step in incident handling

26

Themes and conclusions

Some institutions have organized information security and identity management under a single management structure• Though this is limited in scope currently, this may be an

emerging theme

Business continuity is going to be dependent upon robust IdM infrastructures

Data Security and IdM are intrinsically intertwined• When the data breach occurs, whether the vector was

an IdM failure of Infosec failure is irrelevant.

27

Themes and conclusions

Privacy and compliance• Identity and Access Management (IAM) is used to reduce

exposure of PII and other important resources and services Threat analysis and risk mitigation

• IAM and related functions of logging, tracking, and provisioning access are critical

Scalability• To scale all of this requires an eye toward reducing

complexity, which IAM does by correlating identity and access across campus applications and systems and enabling the consistent application of institutional policy.

Each of these requires a bridge between security and identity management.

28

Questions?