Physical & Logical Identity Convergence

CONVERGENCE

Convergence of physical and logical security is more than the consolidation of job titles; it is a fundamental improvement in network architecture. Convergence assures trusted enterprise workflow, creating a more secure and efficient infrastructure. Convergence is almost a science; it is not simply interoperability, but is built into the architecture as an identity framework. The clearest example is the United States Federal government’s Personal Identity Verification (PIV) program, an identity framework for all government employees and contractors. Our inspiration is gained from their success and the National Institute of Standards and Technology’s (NIST’s) comprehensive standards architecture. It has been our belief, since 2005, that PIV forms the basis for a fundamental change in academic and enterprise workflow, based on the convergence of identity across the network.

IAM is pleased to present CONVERGENCE, a series of whitepapers focusing on the future of security in academia and industry. Together we hope these papers help consolidate your thinking, and raise awareness of the value of an integrated security framework, a converged security architecture. Like any architecture it begins on paper, we strongly recommend the investment in a “Blueprint” document clearly detailing your goals and objectives. This is a long-term process with long-term objectives, but like any architecture it impacts short-term decisions. Today, a blueprint helps to guide resource planning, disaster recovery, construction standards, and technology investment. Planning will guide the university or enterprise to a more secure, compliant, audit-able, and efficient architecture.

What is identity? At its roots identity is a process of accreditation: are you who you claim to be? Identity is a set of processes and procedures that provide a basis for trust, whether on the physical edge, a door, or on the network. Identity maps to rights and privileges whether it is physical, logical, or federated to external domains. Identity is a singular concept of providing access privileges (physical or logical) to the individual standing in front of his or her supervisor/administrator. But, identity in the university or enterprise environment is hardly singular. How many identities do you have professionally and personally? We use an identity card to pass security in the morning or to receive a 15% discount at the café, but need a separate collection of user names and passwords on the log into the network? Some universities and enterprises use cryptographic tokens to assure trusted authentication, costing a university or enterprise at least $60 per person/per year in TCO (total cost of ownership), but investing in a smartcard is too expensive? Convergence is about architecture, a framework for enhanced security, compliance and audit-ability across all segments of the educational or enterprise environment. Convergence requires an investment in advanced cryptography and small changes to badging and policy. Convergence drives efficiency and a positive return on the investment. Convergence is today’s technology.

Less than a decade ago, IT systems were “stovepipes,” legacy systems developed for a specific purpose that did not interoperate with other systems. Security mirrored that trend, each application having its own security system and policy. More recently we have migrated to single-sign-on (SSO) functionality, whereby we authenticate once to the network and are authorized to multiple applications and services. Many saw SSO as convergence; the convergence of multiple user names and passwords into a single identity, but this is not our definition. SSO was a great step, but now we need to unify security physical and logical. We espouse one unified identity framework with levels of identity assurance associative to the level of security required for specific room access, application authentication, service log-on, or 3rd party authentication. Advances in technology have made the convergence of identity practical, necessary, and essential.

Convergence is necessary to address the following challenges:

• Disparate security management.

Employees manage numerous credentials (identity cards, user ID/passwords or pins) for numerous unique and independent systems. As security concerns have become greater, the required periodic password changes and complexity of password construction have all become more stringent, exacerbating challenges to memorization and management.

• Inconsistent system-security usage, policies and procedures.

Inconsistent identity policies within a domain, or externally in a partner’s domain, create challenges as to the root authority to base trust upon. Moving to a standards based approach to identity will build cross-domain trust and greater efficiency.

• Evolving nature of the Network

System-wide security means so much more in 2009 than a few short years ago. The University or Enterprise network hosts physical security (access control, IP cameras, Alarm Panels), network security, and provides Identity Services to external networks (SAML Assertions). While IT devices are increasing exponentially, the percentage of systems that are nomadic in their mission, wireless or dynamic in their physical location, is also increasing. Together they form a “Perfect Storm;” and, if you were in New England on that fateful day, we all went to work that morning under a brilliant sun and calm breezes.

• Need for greater trust.

Development of trust involves authentication by each of the parties of a transaction to the level of assurance required by the other party in order to proceed. Universities or global enterprises need to agree on technical definitions for levels of trust, and the standards to measure levels of trust (i.e., metrics).

• Interoperability shortfalls.

Interoperability will be achieved by developing a bridging function that enables disparate identity systems and federations of systems to exchange identity information and reuse existing credentials. This bridging function will permit individual organizations to verify identity claims by querying the data-stores held by others.

A converged identity architecture establishes a pro-active (v. reactive) approach to identity and enterprise security. If we have a unified identity framework then we restrict access to those we know, we establish stringent policies and procedures to assure compliance. Today all security applications should run across the Internet Protocol or IP network, and the foundation of that security is a trusted identity framework which can be easily managed and audited.

We often speak of security as a Board level concern, or a Trustee level concern. Having weak access control policies (ex: bar-code based ID Cards) while investing in enhanced Intrusion Prevention on the network is nonsensical; yet we see it all the time. Building dormitories with magnetic stripe technology in 2009 ignores the reality of the useful life of this technology and others. Placing IP based surveillance cameras in public spaces but not addressing network concerns, storage policies, and video management is equally troubling. Decision makers must realize the value of a comprehensive security plan and execute upon it. We would never build a building without a plan, how are we going to manage security across the university or enterprise environment without one?

Inevitably we hear about divisional directors and their domains, and we too often see politics come before practice. Security is not a secondary decision or a patch job, it is a primary business driver. Proper security and architecture drive improved business function and efficiency.

A Practical Medium

Convergence is in the cards, literally! Convergence is enabled based on new smartcard technology and its related standards, which utilize embedded processors on the smartcard. Clearly, an identity card is not new; this is not your father’s card. Today’s smartcards are capable of carrying multiple identities, signing credentials and biometric data; and can process challenges directly on the card. It is the advancements made in smartcard technology and international standards that allow us to practice convergence.

Smartcards first emerged about a decade ago, vendors began to present smartcards or memory based cards, capable of passing an encrypted identity to another application (ex: a door reader or a copy machine). These memory cards were application siloed and enabled the simple allocation of memory space; one of the more popular applications being a purse for micro-payments. These memory-based smartcards were themselves a siloed approach to security. These first generation smartcards were a generational shift from magnetic stripe and later proximity cards. The next generation of processor based smartcards: Multos or Java Cards allow the card to be identity centric and not segmented by application. Newer smartcards can have a challenge processed directly on the processor of the card, digital keys can be securely seeded with the card, biometrics can securely stored on the card; all allowing for multiple levels of identity authentication. International Standards allow for applications to uniformly use smartcards to authenticate users across physical and logical security domains.

One of the earliest and most influential uses of newer smartcards is the United States Department of Defense (DOD) Common Access Card (CAC), which was designed to be the standard DOD identity card and the primary card to enable both physical access to buildings and logical access to the DOD network. Since October 2000, the DOD has issued over 12 million CAC cards and implemented a worldwide application architecture. Today, support for the CAC card can be found on Windows, Apple, and Linux operating systems, and with portable mobile devices (such as the Blackberry smart phone).

The Federal Government's move to smart cards accelerated with the issuance of Homeland Security Presidential Directive 12 (HSPD-12) on August 27, 2004. HSPD-12 mandates the need “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy by establishing a mandatory, Government-wide standard for secure and reliable forms of identification.” HSPD-12 specifically calls for the use of a common identification credential for “gaining physical access to federally controlled facilities and logical access to federally controlled information systems.” As a result of this directive, the National Institute of Standards and Technology (NIST) published FIPS 201. FIPS 201 defines the identity vetting, enrollment, and issuance requirements for a common identity credential and the technical specifications for a government employee and contractor ID card: the PIV card.

A growing number of approved vendors of logical and physical access systems and applications have developed products built on FIPS 201 and industry standards for smart cards. FIPS 201 has attracted international attention and is under consideration for government, public safety, and critical infrastructure personnel in other countries. Within the next five years, 12 million PIV cards will be used in the Federal Government alone, driving a significant expansion of FIPS 201 infrastructure and applications. And, FIPS 201 is the framework for most State’s first responder cards or FRAC (First Responder Access Cards).

Using processor based smart cards enables the issuer to assert that the receiving party can place a high degree of trust in the information on the card. This information can include personal information (for example, a biometric or signed digital photo) or privileges (such as digital certificates that allow computer logon). In any secure identity credentialing system, the issuance process is as important as the credential’s security. The issuance process needs to bind the person to a level of accreditation, are they who they claim to be? And, after the credential is issued, the credential life cycle management process needs to incorporate authentication, revocation, and reissuance processes. One can only trust a credential if they believe that the issuance and life cycle management processes are secure.

Our CONVERGED whitepaper series will look more closely at the technology and standards of smartcards: It’s in the Cards. This will be the second installment of the Series.

The Importance of PKI

Public Key Infrastructure (PKI) technology is a fundamental component of the converged identity framework. Public key cryptography provides the trusted framework for absolute assurance of identification, integrity, authenticity, confidentiality, and non-repudiation within services. The public key component provides electronic credentials that are unique, un-forgeable, and trusted for use in network transactions, and supports strong authentication for a broad range of human and non-person entities (devices) requesting access to networks, information and resources. A PKI credential carried on a smartcard provides a card which can be challenged at the physical perimeter. Now, you are more than just the card, you are also something the cardholder knows. This is the principal behind cryptographic tokens, but in a common and easily used form factor, a smartcard. The PKI-based authentication provides the ability to log on to network or Web-based service, thus eliminating the inherent vulnerabilities of user ID/password or pin. In fact, the DOD has reduced unauthorized log-on attempts by 46 percent because of the requirement for all DOD personnel log on to unclassified networks using a smartcard with their associative PKI certificate.

A PKI framework provides a secure infrastructure and common standards for identity proofing, credential issuance and revocation management. It is the framework and services that provide for generation, production, distribution, control, accounting and destruction of identity. A PKI framework is based on the issuance of a unique private key which securely resides on the smartcard; in fact, the private key is non-exportable from the card. The private key is cryptographically associated with a unique public key, which by its very name is public. Therefore, the cardholder can “publish” their public key to be used to challenge the unique private key. It is this challenge and response that makes PKI so unique. Further, we only allow the private key to be accessed based on a second challenge, this could be as simple as a pin or more complex as in a biometric (fingerprint) also stored on the card. In the later example, the cardholder would place their card in a biometric reader, the cardholder would swipe their fingerprint, the card would verify the fingerprint, and the private key would be unlocked. The processing all happens in milliseconds even though our human reaction may be in seconds.

The PKI framework provides a foundation for converged security services to include access control, network authentication, WAN authentication, wireless authentication and access to web services (internally or externally). PKI also supports digital signatures, data integrity, non-repudiation, and confidentiality when associated with encryption. PKI can be used to facilitate broader usage for network logon, e-mail signing, and certificate-based authentication for Web servers. PKI offers a centralized management framework to authorize a new credential or revoke an existing key. Imagine if your academic institution or enterprise can manage all security through one management function, the trust of a single key.

Note: Authentication keys should only be used for authentication, authorizing the cardholder to a building, room, network, or web service. Digital signing and/or encryption should be performed by additional keys created for those purposes, each of which can be stored on the same smartcard.

The Service Oriented Architecture

Universities and enterprises all seek interoperability of their legacy systems, mainframe, ERP, and CRM systems with newer technologies running on web-facing application servers. These web services are a gateway to enabling reuse of critical “back-end” technologies. The Service Oriented Architecture (“SOA”) is a distributed computing framework for these web services deployments. SOA uses standardized middleware components to enable information to flow as needed, and delivers application agility. The goal of SOA is to minimize reworking of existing legacy applications, extend their useful lives, and expand their potential for reuse across a university or enterprise.

As universities and industry empower their SOA deployments, messages will be exchanged between web services internally and externally. Trust is established based on a message level security standard: WS-Security. Under the WS-Security standard the requesting web service signs an assertion of trust to the receiving service. This assertion is called a SAML assertion, which stands for Security Assertion Mark-up Language. Without getting into a more complex technology discussion, the assertion carries authentication properties. In essence the assertion is signed by the identity service, in this case the requesting service, or is signed by the user. Were a service to use basic usernames and passwords, we have done little to solve our identity silos and little to enhance security. But, a converged model, whereby a private key can be challenged by a relying party and used to sign the assertion, forms a secure and trusted identity framework. As important, a unified identity system that issues or revokes a credential when someone joins or leaves an institution enhances the trust, compliance and audit-ability of the SOA.

Our CONVERGED whitepaper series will look more closely at identity on the SOA in: Enterprise SOA Trust. This will be the third installment of the Series.

Conclusion

An identity framework must be consistent with the long-term vision, which can support all entities from users to devices to systems, both physical and logical. The identity capability must be flexible, agile, dynamic, audit-able and scalable to account for and respond to the numerous changes in most organizations and mission operations. The need for higher levels of confidence in claimed identities and the safeguarding of data associated with identities of people, systems, processes and organizations underline the demand for continued identity evolution. University IT or Enterprise staffs must manage local entities (e.g., departments, sponsors of devices and owners of applications); they will have to be registered, issued credentials, and systems configured to use the identity framework. This requires coordinated efforts, standards-based implementations, synchronized execution and a secure IT infrastructure to support the common security architecture.

A successful identity framework will also be required to support a wide variety of privacy and security levels, ranging from low-security password-based single-factor authentication to high-end attribute-based systems employing state of the art privacy-enhancing techniques. Technical aspects of this problem can be addressed conceptually by designing an appropriate identity framework. The identity framework should:

• Associate people and devices with an identity (PKI, biometric, other). This identity will be used to access facilities and networks;

• Use shared standards, protocols and infrastructure to support both logical and physical access to resources; and

• Federate credentials between trusted domains based on common standards and root trust.