Upload
ezra-harrell
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
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?