Contributed by EDUCAUSE Grant Programs (CAMP)

Effective security efforts are composed of a complex set of interrelated components including policies, procedures, and technical controls. The interrelation between components is not obvious, and the technical details of security systems can obscure perspective with respect to other critical systems. Security architectures provide a coherent plan to ensure that we meet our IT security goals. But you can’t build your security model without an accompanying IAM model as a part of it. This session will discuss models for security and IAM and how they interleave.

How can you control access to social security numbers, personal identifiable information, and payment card industry data? Setting up a few architectural principles, solutions, and related policies and processes can go a long way towards ensuring appropriate distribution and use of these data. This session will provide examples in the administrative and teaching/learning areas of the institution, and explore related issues in the research area.

A step up from using groups, role-based access control enables privileges to be assigned to institutional roles assigned to individuals. Even though this is the brass ring of access control, leading an initiative to define the policy and process guiding this infrastructure is daunting. Questions arise, such as who should be represented in the roles system? You may find you have more than one organizational chart, so which one do you use? Who should decide the roles structure and make the policy decisions? For which resources will you be assigning privileges? And will you list all the roles and their access rights or have the supervisors/area managers assign rights given a set of boundaries? The outcome of the former could be a list of exceptions, and the outcome of the latter could be a pattern that leads to a set of defaults, clustering around the distinct roles. But there is no one way. This panel will explore this complex issue and provide a number of perspectives on how to plan for such an effort.

Complying with privacy requirements is an institution-wide effort that involves end users, data stewards, policy officers, and security professionals. However, the individuals who are expected to actually implement technologies needed to enable privacy aren't always apprised or aware of the reasoning behind what they are being asked to do. If they were, ideas as to how to better satisfy the goals may well result. This session brings together the "right brain" policy people with the "left brain" technologists, in an effort to make each more "whole-brained," in the area of privacy and supporting technologies.

Do you have a practice or interesting approach to share in the security and identity management space? Or would you like to connect up with someone with a similar challenge and collaborate on a solution? This session will provide a final chance for attendees to discuss a good idea or opportunity for peer networking.

Security staff want to keep the bad guys out and IAM folks want to let the good guys in. A hair is being split, to be sure, but it exposes a number of issues rooted in organizational politics and reporting structures. This panel session will explore how a number of institutions have encouraged their security and IAM staff to work together to achieve shared institutional goals.

What are the benefits and issues with correlating identities across the enterprise? What are the issues relating to cross walking and characteristics of identifiers? What strategies are there for getting the most out of logging? It’s important to know if an identifier has been reassigned, for instance, when using it for access to restricted spaces. Are there new institutional processes we should consider, such as logging in to register your IP address and binding an IP with a user? This session will explore these questions and offer a set of common requirements.

How can IAM be helpful in managing network intrusion and access? A researcher wants to show a national grid-enabled resource to her class, but can’t access it because she’s in a classroom and, by policy, unable to get through the firewall. She then clicks on her research icon, authenticates and, because of her researcher status, accesses the research van that is enabled to use the appropriate ports. Can coupling network capabilities and IAM replace the use of IP addresses as the criterion for access with identity, roles, and related attributes? Focusing in on wireless access specifically, can IAM can help correlate identity to an endpoint device by combining network registration and personal identification? This session will explore these questions and how one can identify the person behind the device or address.

Many institutions have developed a privacy approach for their legacy and business systems. For third-party hosted applications, institutions may have a contract in place that specifies privacy requirements. What we don’t have a grip on are the web-based collaborative applications, such as wikis and blogs, where we neither have a comprehensive policy nor a contract to govern privacy or data use. What are the privacy pitfalls and requirements for each of these three categories? This session will explore case studies of various models in place across higher education.

IAM and security must be on the same page regarding web application development to facilitate proper access. What coding practices and assessment practices should web developers use? What tools are out there to help (OWASP)? Do we need cross-site scripting and pup code review to ensure proper leveraging of enterprise IAM or should web applications manage their own IAM/account data? This session will discuss strategies for how to include security and access requirements in the development process and code.

A level of assurance (LoA) refers to the degree of certainty that (1) a resource owner has that a person's physical self has been adequately verified before credentials are issued by a registration authority, and (2) a user indeed owns the credentials they are subsequently presenting to access the resource. The requirements for the level of certainty at both ends of that set of transactions should be driven by a risk assessment based on the value of the resources being protected. This session will describe the concept of LoA, discuss its importance, outline its technical components, and discuss the proposition that roles of the identity management and security staff are critical for a successful implementation of LoA.

Personal privacy is about protecting individuals and them control over their personal information. Institutional privacy is about protecting proprietary information. In either case, privacy requirements must reflect campus values and also meet the institution's legal and regulatory obligations. The requirements must be reflected in the identity management system: its flexibility, how it is used to support access to resources, and who makes the decisions about that access. IAM can provide for the externalization and consolidation of roles that can be used to determine permissions and access without that function being built into each resource. This session will discuss these topics from the auditor, identity management architect, and security staff perspectives and offer a case study on how one campus has addressed these issues.

Provisioning access is an IAM function, and deprovisioning that access is a security objective. How might these combined objectives be met with common process, and what sorts of access should be managed by it? Data, applications, networked services, and physical facilities all have particular provisioning and deprovisioning needs. Campus cards, for instance, mitigate risk only when the access information associated with them is current. When a card's rights get out of sync with its bearer's status, the card itself becomes a risk. Addressing this issue, given all the authorization and access points, can be a challenge unless they are tied into the enterprise identity management system.

Unsure how all the parts of an identity management system fit together and would like to know more? This non-technical, preworkshop seminar offers a functional model of the campus infrastructure and provide attendees a chance to view it through the technology, policy, and business process lenses. Topics covered include technology model, lifecycle of identity, and policy frameworks and governance.

Incident-response processes and tools are, by-and-large, designed to guide reaction to situations within an organization and are geared toward incidents involving local users and systems. With federated identity, we're now expanding this and entering into agreements and relationships that enable an extended community to access our services and our campus constituents to use off-site services in an authenticated and authorized fashion. In this new context, how do you respond when someone from a collaborating organization is hacking your systems? This session will discuss the challenges in the policy, practice, and technology of addressing incident response and mitigation in a federated world.