Dont be Ignorant!
Boston Globe Metro Desk 2.10.2010: "A Manchester-by-the-Sea man arrested for stockpiling weapons and ammunition in his home allegedly told police he was preparing for Armageddon." This 45 yearold man clearly needs help, but it is a sign of our times. This age group, under extreme job and economic pressure, is a threat against society. Communities rich and poor need to double their efforts to secure public places. Does your communinity, school, place of worship, gathering place... have a security plan, a disaster plan...? What are you doing to secure your buildings, improve your communications with First Responders? I met with a Mayor of a local City this week who was probing his department on all of these questions. Don't wait, act now, call us if you need help. Prepare, outreach, and use your senses as we navigate these difficult times. Don't be ignorant!
New Identity Powerhouse
Many of you probably noticed the merger of SCM Microsystems and Bluehill ID last week to form Identive Group (http://www.identivegroup.com/). SCM Microsystem's component business with Bluhill's smart card properties will make a very strong combination. While this market has been led by HID, they are potentially very vulnerable to a forward-thinking Identive Group. Identive Group with SCM components, MultiCard, and Hirsch software is a true competitor.
God Bless the people of Haiti!
Join me in donating to the American Red Cross http://www.redcross.org
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.
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.
SOA Security and Message Validation
Today's IT environment is driven by the need to connect disparate systems into a flexible, unified, efficiently-performing whole. The connected systems may span continents, enterprise and organizational trust domains, and legal jurisdictions. In order to connect, enterprises are turning to Service-Oriented Architecture (SOA) implemented with SOAP-based Web Services and SAML-based federated identity management. This white paper highlights some of the inherent security features and demands of these new technologies and how the Trust Authority System from IAM Technology helps enterprises achieve real-time identity and data validation in a service-oriented environment with a dynamic membership and regulatory compliance requirements.
SOA, Web Services, and Security
Over the past decade, enterprises have realized that in order to be competitive (or in the case of governments, be effective) they need to be able to easily and effectively share services both within their constituent organizations and with other enterprises. The modern approach for doing so is Service-Oriented Architecture (SOA) and most implementations of service oriented architecture used SOAP-based Web Services.
Security, of course, remains paramount and in the case of Web Services, there is a suite of Web Services Security specifications of which the SOAP Message Security specification defines how to use message-level cryptography such as XML Signature and XML Encryption for SOAP messages.
Another security aspect of SOA is authentication – both for signature validation and authorization. In particular, because SOA is geared to sharing services across organizations, a flexible and robust authentication meta-layer is needed and that is why the SAML (Security Assertion Markup Language) specification has been developed.
SAML enables an assertion about an entity's authentication and/or its attributes to be shared among different organizations no matter what authentication mechanisms or identity management infrastructure they use. SAML's inherent support for federated identity has made it the core technology behind industry federated identity initiatives such as the Liberty Alliance Project and Shibboleth. There is also a Web Services Security specification, the SAML Token Profile, defining how to use SAML-based tokens within SOAP messages. And like the SOAP Message Security specification, the SAML core specification also defines how to use XML Signature and XML Encryption to protect messages.
XML Signature and XML Encryption are particularly valuable for securing SOAP and SAML messages because they enable parts of the message to be signed and/or encrypted in accordance with the specific security needs of that part, the signer, and the target audience. For example, if part of a SOAP message is intended to be modified by intermediaries between the sender and the recipient, that part must be left unsigned or else the signature of the originator would become invalid. Similarly, if parts of a SAML message need to be left in the clear or need to be encrypted for different parties, that can be elegantly done with XML Encryption. The SOAP Message Security specification defines how to include and process XML Signature and XML Encryption objects within SOAP messages. Similarly, the SAML specification does the same for SAML assertions. Finally, both the SAML and SOAP Message Security specifications support signed timestamps to help ensure the freshness of the message.
Multi-Party Processing
In a service-oriented environment, the execution of a service may result in a number of SOAP messages being exchanged among a number of different entities. It is important to note that SOAP is designed for more complicated transactions than simple request/response. The design of SOAP enables the same SOAP message to be received, modified, and forwarded to a different party than from the one it was received. In SOAP terminology, intermediaries perform different roles with respect to the same SOAP message. Some intermediaries may add information; some may delete information; and some may only read existing information all in the due process of fulfilling a service.
The SOAP Message Security specification describes how one or more signatures can be applied and validated to ensure the full security of the SOAP message as it travels from the initiator, through the intermediaries, and the ultimate relying party. Figure 1 illustrates a SOAP message as it is transformed from point to point. In the figure, the originator creates a SOAP message and applies a signature (SigORIG) that signs Parts 1 and 2. An intermediary captures the message appends a new part (Part 3), adding its own signature (SigIM) to cover parts 2 and 3 (by counter-signing Part 2, it may be indicating that it has reviewed and approved it). The message then goes to the relying party who verifies both signatures.
Besides signing parts of a SOAP message dealing with the execution of the service, the SOAP Message Security specification also defines the signing of security tokens and references to security tokens within SOAP messages. With regard to the latter, the SOAP Message Security specification defines a special transform that allows an XML Signature to point to a security token reference but actually sign the referenced object, not the reference. Hence, service-oriented environments have the flexibility of signing the security token reference itself, the object pointed to by the security token reference, or doing both.
Compliance
Both SOAP and SAML have features supporting compliance to rules regarding processing and policies. An (optional) feature of SOAP Message Security of particular value to service-oriented environments where compliance is a priority is the ability of a requester to require that a responder provide evidence in the response that the responder validated the signature in the request. This is so that the requestor can be confident that the response is based on unaltered information sent by the requestor. The feature, called SignatureConfirmation, does not disallow intermediaries from modifying non-protected parts of the SOAP message as long as those intermediaries do not maliciously or accidentally modify parts of the SOAP message signed by the requestor.
In SAML, XML Signatures are used to authenticate and protect the integrity of both requests (e.g. a request for an authentication assertion) and responses (an authentication assertion). The SAML specification states that if a SAML assertion contains an XML Signature, then the relying party must not trust the SAML assertion unless the XML Signature is valid. If the signature is valid, the relying party may then assess “the identity and appropriateness of the issuer and may continue to process the assertion in accordance with this specification and as it deems appropriate”.
SAML also uses signatures for signing the Consent attribute. The Consent attribute indicates whether or not the consent of the principal (the one whom the assertion is about) was obtained or not by the issuer of the message (either a request or response) and under what conditions. As examples of consent, consider a service that would like to obtain an assertion from an identity provider about an attribute of a user. The service may need, due to internal privacy policies or government regulations, to obtain the consent of the user before querying certain information about that user. As well, the user's identity provider may need to obtain the consent of the user before providing that information.
Need for Message-Level Security
Other message-level security formats such as PKCS#7 which are not XML-aware do not inherently have the capability of selectively signing and encrypting message parts for different audiences. PKCS#7 does, however, at least provide unbroken message-level security between the originator and the relying party. In contrast to the message-level security provided by XML Signature, XML Encryption, and PKCS#7, is TLS which operates at the transport layer. For direct server to server communication that does not require application-aware, process-aware, policy-aware, auditable, provable security, TLS is sufficient. In the world of SOA, however, one needs end-to-end security that can be tailored to the specific, dynamic needs of enterprises and their applications; and that is historically auditable in order to prove compliance with the internal and external regulations. That kind of higher-level security requires message-level security.
Need for Speed
In a service-oriented environment, message-level security requires access to the public key material of the constituent organizations. This means that there must be a secure, up-to-date repository of the public keys and a highly efficient means of accessing the public keys in that repository. However the nature of service-oriented environments is that they are distributed (often over a wide geographic area), may contain mobile clients, and yet, because the services are intended to enable machine-to-machine communication, high performance is a necessity. And that means that message-level security too must be of the highest performance or else it will be a bottleneck to the system's primary functionality.
The IAM Trust Authority System
The Trust Authority System from IAM Technology is a hardware appliance that incorporates breakthroughs in cryptographic research made at Brown University for the United States Department of Defense. Specifically, the Trust Authority System enables fast and easy distribution of validated public keys in distributed, federated environments such as those built on SOA using SAML and SOAP-based Web Services. It does so by allowing relying parties to efficiently interact with validation responders. A validation responder is an authenticated dictionary widely distributed throughout Layer 7, and among partner organizations. Validation responders reply to queries about the validity of a public key in real time (tested to 54 micro-seconds) locally. An answer from a validation responder can be trusted as if it came from a source. Validation responders can even issue trust in untrusted environments.
These features distinguish the IAM Trust Authority architecture:
• Trust domains can easily update their public key material through XKMS (XML Key Management Specification) messages to the IAM Trust Authority;
• The IAM Trust Authority can efficiently and securely push updates to validation responders throughout a service-oriented environment; and
• The validation responders can provide near-instantaneous, verifiable responses to public key requests from applications.
Dynamic Membership
In a dynamic, federated environment, new members enter and existing members may leave. As members come and go, so must the status of their public keys within the environment.
The X10 Trust Authority architecture makes management of a dynamic membership easy through its straightforward XKMS interface for registering, reissuing, and revoking the public keys securely stored within the X10 Trust Authority. What is unique about the Trust Authority is how it then updates the information base of the validation responders. Through the STMS update mechanism, the IAM Trust Authority can update multiple validation responders using very little bandwidth and requiring minimal processing power internally and within the validation responders. This makes it possible for the organizations within a service-oriented environment to be assured that the relying parties in that environment have the best possible access to up-to-date trust information.
Historically Provable Validation of the Public Key
Compliance requires evidence. In the area of signature validation, one needs evidence that the public key used to validate signature was valid at the time that the validation occurred. As mentioned in the previous section, participating organizations within the service-oriented environment join, leave, or simply update their keys. Yet how can one know whether a particular public key was valid at the time signature was verified?
To do this, the IAM Trust Authority incorporates each update into the existing authentication dictionary in accordance with IAM’s Persistent Authenticated Dictionary (PAD) technology. With PAD, each update to the authenticated dictionary results in an adjunct to the data structure along with a corresponding Basis. To accommodate the time dimension of PAD, the STMS queries for historic validation include an additional parameter for the time instant of interest and the returned answer proofs are similarly cryptographically dependent on the time instants of the corresponding updates to the status of the public key. Consequently, the validation status of a public key can be proved for any time instant and, as such, that proof can be used as evidence for compliance with respect to signature processing and therefore also with respect to identity-related assertions and Web Services transactions.
Real-time Public Key Validation
As mentioned earlier, dynamic, federated, service-oriented environments cannot be bottlenecked by security. Indeed, many of them are incorporating in-line hardware appliances to realize wire-speed processing of secured SOAP and SAML messages.
Whether signature validation is done in hardware or software, doing it efficiently requires real-time responses to public key validation queries. The IAM Trust Authority architecture makes that possible. The high efficiency of an IAM Trust Authority-based deployment is possible because the placing of the validation responders can be optimized for the particular resident infrastructure as the validation responders need not be secured. This is possible thanks to the use of a unique data structure (called a skip list) that enables efficient updating of distributed validation responders and a corresponding cryptographic mechanism that provides trusted proofs to relying parties about the answers received from a validation responder. With the IAM Trust Authority Architecture, system components within a service-oriented environment can now have up-to-date validation status for public keys, and access to those keys, in real time.
Conclusion
Collaboration among enterprises, or within the constituent organizations of a single large enterprise, is being realized today through service-oriented architecture – much of which is being implemented with SOAP-based Web Services to enable advanced communication among devices and with SAML to ensure that participants in the transaction are identified, authenticated, and authorized.
SOAP and SAML, and their respective security specifications, contain many features that are invaluable to implementing multi-party business processes and ensuring that those processes are conducted in compliance with security policies, privacy policies, internal policies, and government policies. These features are designed to be best secured with message-level security; however, message-level security in a service-oriented environment requires real-time public key validation. Now, with the IAM Trust Authority, real-time public key validation is a reality thanks to its implementation of IAM’s advanced cryptographic research. Furthermore, the revolutionary technology behind the IAM Trust Authority architecture supports dynamic membership among the participating enterprises and provides cryptographically provable evidence about the validity or not of a specific public key for future compliance audits.
SOA, Web Services, and Security
Over the past decade, enterprises have realized that in order to be competitive (or in the case of governments, be effective) they need to be able to easily and effectively share services both within their constituent organizations and with other enterprises. The modern approach for doing so is Service-Oriented Architecture (SOA) and most implementations of service oriented architecture used SOAP-based Web Services.
Security, of course, remains paramount and in the case of Web Services, there is a suite of Web Services Security specifications of which the SOAP Message Security specification defines how to use message-level cryptography such as XML Signature and XML Encryption for SOAP messages.
Another security aspect of SOA is authentication – both for signature validation and authorization. In particular, because SOA is geared to sharing services across organizations, a flexible and robust authentication meta-layer is needed and that is why the SAML (Security Assertion Markup Language) specification has been developed.
SAML enables an assertion about an entity's authentication and/or its attributes to be shared among different organizations no matter what authentication mechanisms or identity management infrastructure they use. SAML's inherent support for federated identity has made it the core technology behind industry federated identity initiatives such as the Liberty Alliance Project and Shibboleth. There is also a Web Services Security specification, the SAML Token Profile, defining how to use SAML-based tokens within SOAP messages. And like the SOAP Message Security specification, the SAML core specification also defines how to use XML Signature and XML Encryption to protect messages.
XML Signature and XML Encryption are particularly valuable for securing SOAP and SAML messages because they enable parts of the message to be signed and/or encrypted in accordance with the specific security needs of that part, the signer, and the target audience. For example, if part of a SOAP message is intended to be modified by intermediaries between the sender and the recipient, that part must be left unsigned or else the signature of the originator would become invalid. Similarly, if parts of a SAML message need to be left in the clear or need to be encrypted for different parties, that can be elegantly done with XML Encryption. The SOAP Message Security specification defines how to include and process XML Signature and XML Encryption objects within SOAP messages. Similarly, the SAML specification does the same for SAML assertions. Finally, both the SAML and SOAP Message Security specifications support signed timestamps to help ensure the freshness of the message.
Multi-Party Processing
In a service-oriented environment, the execution of a service may result in a number of SOAP messages being exchanged among a number of different entities. It is important to note that SOAP is designed for more complicated transactions than simple request/response. The design of SOAP enables the same SOAP message to be received, modified, and forwarded to a different party than from the one it was received. In SOAP terminology, intermediaries perform different roles with respect to the same SOAP message. Some intermediaries may add information; some may delete information; and some may only read existing information all in the due process of fulfilling a service.
The SOAP Message Security specification describes how one or more signatures can be applied and validated to ensure the full security of the SOAP message as it travels from the initiator, through the intermediaries, and the ultimate relying party. Figure 1 illustrates a SOAP message as it is transformed from point to point. In the figure, the originator creates a SOAP message and applies a signature (SigORIG) that signs Parts 1 and 2. An intermediary captures the message appends a new part (Part 3), adding its own signature (SigIM) to cover parts 2 and 3 (by counter-signing Part 2, it may be indicating that it has reviewed and approved it). The message then goes to the relying party who verifies both signatures.
Besides signing parts of a SOAP message dealing with the execution of the service, the SOAP Message Security specification also defines the signing of security tokens and references to security tokens within SOAP messages. With regard to the latter, the SOAP Message Security specification defines a special transform that allows an XML Signature to point to a security token reference but actually sign the referenced object, not the reference. Hence, service-oriented environments have the flexibility of signing the security token reference itself, the object pointed to by the security token reference, or doing both.
Compliance
Both SOAP and SAML have features supporting compliance to rules regarding processing and policies. An (optional) feature of SOAP Message Security of particular value to service-oriented environments where compliance is a priority is the ability of a requester to require that a responder provide evidence in the response that the responder validated the signature in the request. This is so that the requestor can be confident that the response is based on unaltered information sent by the requestor. The feature, called SignatureConfirmation, does not disallow intermediaries from modifying non-protected parts of the SOAP message as long as those intermediaries do not maliciously or accidentally modify parts of the SOAP message signed by the requestor.
In SAML, XML Signatures are used to authenticate and protect the integrity of both requests (e.g. a request for an authentication assertion) and responses (an authentication assertion). The SAML specification states that if a SAML assertion contains an XML Signature, then the relying party must not trust the SAML assertion unless the XML Signature is valid. If the signature is valid, the relying party may then assess “the identity and appropriateness of the issuer and may continue to process the assertion in accordance with this specification and as it deems appropriate”.
SAML also uses signatures for signing the Consent attribute. The Consent attribute indicates whether or not the consent of the principal (the one whom the assertion is about) was obtained or not by the issuer of the message (either a request or response) and under what conditions. As examples of consent, consider a service that would like to obtain an assertion from an identity provider about an attribute of a user. The service may need, due to internal privacy policies or government regulations, to obtain the consent of the user before querying certain information about that user. As well, the user's identity provider may need to obtain the consent of the user before providing that information.
Need for Message-Level Security
Other message-level security formats such as PKCS#7 which are not XML-aware do not inherently have the capability of selectively signing and encrypting message parts for different audiences. PKCS#7 does, however, at least provide unbroken message-level security between the originator and the relying party. In contrast to the message-level security provided by XML Signature, XML Encryption, and PKCS#7, is TLS which operates at the transport layer. For direct server to server communication that does not require application-aware, process-aware, policy-aware, auditable, provable security, TLS is sufficient. In the world of SOA, however, one needs end-to-end security that can be tailored to the specific, dynamic needs of enterprises and their applications; and that is historically auditable in order to prove compliance with the internal and external regulations. That kind of higher-level security requires message-level security.
Need for Speed
In a service-oriented environment, message-level security requires access to the public key material of the constituent organizations. This means that there must be a secure, up-to-date repository of the public keys and a highly efficient means of accessing the public keys in that repository. However the nature of service-oriented environments is that they are distributed (often over a wide geographic area), may contain mobile clients, and yet, because the services are intended to enable machine-to-machine communication, high performance is a necessity. And that means that message-level security too must be of the highest performance or else it will be a bottleneck to the system's primary functionality.
The IAM Trust Authority System
The Trust Authority System from IAM Technology is a hardware appliance that incorporates breakthroughs in cryptographic research made at Brown University for the United States Department of Defense. Specifically, the Trust Authority System enables fast and easy distribution of validated public keys in distributed, federated environments such as those built on SOA using SAML and SOAP-based Web Services. It does so by allowing relying parties to efficiently interact with validation responders. A validation responder is an authenticated dictionary widely distributed throughout Layer 7, and among partner organizations. Validation responders reply to queries about the validity of a public key in real time (tested to 54 micro-seconds) locally. An answer from a validation responder can be trusted as if it came from a source. Validation responders can even issue trust in untrusted environments.
These features distinguish the IAM Trust Authority architecture:
• Trust domains can easily update their public key material through XKMS (XML Key Management Specification) messages to the IAM Trust Authority;
• The IAM Trust Authority can efficiently and securely push updates to validation responders throughout a service-oriented environment; and
• The validation responders can provide near-instantaneous, verifiable responses to public key requests from applications.
Dynamic Membership
In a dynamic, federated environment, new members enter and existing members may leave. As members come and go, so must the status of their public keys within the environment.
The X10 Trust Authority architecture makes management of a dynamic membership easy through its straightforward XKMS interface for registering, reissuing, and revoking the public keys securely stored within the X10 Trust Authority. What is unique about the Trust Authority is how it then updates the information base of the validation responders. Through the STMS update mechanism, the IAM Trust Authority can update multiple validation responders using very little bandwidth and requiring minimal processing power internally and within the validation responders. This makes it possible for the organizations within a service-oriented environment to be assured that the relying parties in that environment have the best possible access to up-to-date trust information.
Historically Provable Validation of the Public Key
Compliance requires evidence. In the area of signature validation, one needs evidence that the public key used to validate signature was valid at the time that the validation occurred. As mentioned in the previous section, participating organizations within the service-oriented environment join, leave, or simply update their keys. Yet how can one know whether a particular public key was valid at the time signature was verified?
To do this, the IAM Trust Authority incorporates each update into the existing authentication dictionary in accordance with IAM’s Persistent Authenticated Dictionary (PAD) technology. With PAD, each update to the authenticated dictionary results in an adjunct to the data structure along with a corresponding Basis. To accommodate the time dimension of PAD, the STMS queries for historic validation include an additional parameter for the time instant of interest and the returned answer proofs are similarly cryptographically dependent on the time instants of the corresponding updates to the status of the public key. Consequently, the validation status of a public key can be proved for any time instant and, as such, that proof can be used as evidence for compliance with respect to signature processing and therefore also with respect to identity-related assertions and Web Services transactions.
Real-time Public Key Validation
As mentioned earlier, dynamic, federated, service-oriented environments cannot be bottlenecked by security. Indeed, many of them are incorporating in-line hardware appliances to realize wire-speed processing of secured SOAP and SAML messages.
Whether signature validation is done in hardware or software, doing it efficiently requires real-time responses to public key validation queries. The IAM Trust Authority architecture makes that possible. The high efficiency of an IAM Trust Authority-based deployment is possible because the placing of the validation responders can be optimized for the particular resident infrastructure as the validation responders need not be secured. This is possible thanks to the use of a unique data structure (called a skip list) that enables efficient updating of distributed validation responders and a corresponding cryptographic mechanism that provides trusted proofs to relying parties about the answers received from a validation responder. With the IAM Trust Authority Architecture, system components within a service-oriented environment can now have up-to-date validation status for public keys, and access to those keys, in real time.
Conclusion
Collaboration among enterprises, or within the constituent organizations of a single large enterprise, is being realized today through service-oriented architecture – much of which is being implemented with SOAP-based Web Services to enable advanced communication among devices and with SAML to ensure that participants in the transaction are identified, authenticated, and authorized.
SOAP and SAML, and their respective security specifications, contain many features that are invaluable to implementing multi-party business processes and ensuring that those processes are conducted in compliance with security policies, privacy policies, internal policies, and government policies. These features are designed to be best secured with message-level security; however, message-level security in a service-oriented environment requires real-time public key validation. Now, with the IAM Trust Authority, real-time public key validation is a reality thanks to its implementation of IAM’s advanced cryptographic research. Furthermore, the revolutionary technology behind the IAM Trust Authority architecture supports dynamic membership among the participating enterprises and provides cryptographically provable evidence about the validity or not of a specific public key for future compliance audits.
The Changing Face of Identity in Healthcare
Healthcare as an industry has the most to gain from a progressive approach to identity both in physical and logical security. Few other industries have the baseline need of assuring identity: whether it’s accessing doors leading to the emergency room or accessing a patient’s electronic medical record. This whitepaper will explore identity from the physical perimeter through the logical network; and, will promote a concept of unified identity. We will discuss the importance of a common architecture which is easily managed and audited. And, we will explore newer technologies and architectures which enable dynamic exchange of health information, but demand non-repudiation of identity.
IAM Health, a division of IAM Technology, is pleased to support the dynamic healthcare industry with our Advanced Security Group, experts in advanced access control and security integration in healthcare. Let us be your guide through this rapidly changing industry.
Earlier this year President Obama signed into law the American Recovery and Reinvestment Act, equally known as ARRA or the Stimulus Act, providing over $38 Billion dollars to the advancement of electronic health records. This investment will transform the healthcare industry. Under the ARRA, physicians will receive a reimbursement premium on Medicaid payments for the use of electronic health records or will be penalized on Medicaid reimbursement beginning in 2015 if they fail to implement electronic health records.
The growth of electronic medical records raises the question of how we trust the integrity of the record: who updated the record, when, who’s liable for misuse, and who has rights to access to the record? It is time for the healthcare industry to embrace a new identity blueprint, an identity proven, flexible and secure. A Blueprint modeled after the success of a similar identity framework instituted throughout the United States federal government.
Building a Unified Path
Whether you are a CIO, CSO, or a Facilities Manager, beginning the process of review, scoping the needs for your future, and developing an identity plan is timely. In fact, you may find your existing access control credentials/cards weak by today’s standards. The vast majority of identity credentials for access control are first generation cards: proximity cards or MiFare Classic Cards. These radio frequency cards simple lack the hardened cryptographic protections to assure security in your healthcare facility. In fact, proximity cards and MiFare Classic Cards have been knowingly compromised by security researchers.
See a MiFare 4K attack in action: http://www.youtube.com/watch?v=NW3RGbQTLhE
Newer smart cards are developed with advanced cryptographic properties and better communication protocols. What this means is a more secure and effective card, one capable of securely authenticating to multiple applications. In fact, newer smart cards actually have a processor, enabling on card computing and advanced access control challenges. This is the case with all United States Federal government identity credentials by law. The Homeland Security Presidential Directive (HSPD) 12 instructed the National Institute of Science and Technology (NIST) to create Federal Information Processing Standard (FIPS) 201, a framework for the vetting, issuance, management and accreditation of identity products throughout the federal government. FIPS 201 is a contact and contactless smart card security framework that standardizes multi-tiered access and authentication. For advance authentication, one or more digital keys are stored on an advanced smart card processor. This is known as a Public Key Infrastructure or PKI, a security infrastructure based on unique private keys issued by a trusted server.
The Emerging Standard
The FIPS 201 standard provides Federal agencies with a blueprint for designing and implementing a comprehensive smart card credentialing program, and also provides the healthcare industry a standard for credentialing and security. The signing of HSPD-12 and the subsequent creation of FIPS 201 has been termed a landmark event for identity worldwide. For the first time, a formal standard now exists for governments and industry to purchase biometric and credentialing solutions with the assurance of interoperability and accredited trust. In conjunction with other federal ID programs like TWIC (the Transportation Worker Identification Credential), Registered Traveler and the FRAC (First Responder Access Card), the healthcare industry can now reliable implement enhanced credentials without fear of non-compliance to either Federal, State, or industry standards.
Progressive healthcare organizations are moving to FIPS 201 compatible architectures as a means of achieving a more holistic approach to security, incorporating personnel review (vetting, background checks, security training and awareness), logical security (network and application access), physical security (facility access), audit, and compliance reviews.
While there are many benefits to an advanced smart card credentialing framework in the near term, the majority of benefits will be gained as the electronic health record standards are implemented in the next three to five years. Today, we know the future standard of security on the health record exchange; this has been clearly established by the standards committees. To identify the creator of the record the healthcare standard is SAML (Security Assertion Mark-up Language). SAML is an authentication assertion that provides assurance of the provenance and integrity of the message (we will explore further below). An advanced identity framework similar in scope to FIPS 201 is not simply the right technical answer; it’s the right economic answer. Today, FIPS 201 shows us how to managed identity from a single card, a smart card.
Electronic Medical Records
The National Health Information Network (nHIN) embraces WS-Security (Web Services Security) as an internal message security protocol. WS-Security provides for XML Signature and XML Encryption, two elements that bind identity and encryption to elements of the message itself. In layman’s terms, the doctor can “notarize” her additions to a health record. She, in turn, can encrypt those additions for select recipients to decrypt. While this reaches beyond a traditional discussion of identity, it begins to reveal the scope of your healthcare institutions identity framework.
An advanced smart card architecture is the foundation for this architecture. It is easily audited and streamlines compliance checks. A common identity architecture that is used system-wide and integrated to HR systems, ERP systems, Active Directory , and physical access systems begins with the next generation of card architecture.
Summary
So we have gone on a journey from the security perimeter through the electronic exchange of medical records. We have highlighted the structural benefits of the United States federal standards for identity and credentialing; standards we believe the United States federal government will recommend for the healthcare industry. We believe there are compelling business drivers: ease of management, integration to ERP systems, convergence of identity physical and logical, lower OPEX (operational expense), possible CAPEX savings (capital expense), stronger cryptographic assurance of identity, multi-factor authentication, seamless integrity with electronic medical system, compliance to international and United States federal standards, federated trust between institutions, among others.
Is it time to explore the benefits of a common identity architecture? We certainly are encouraging our clients to explore the benefits of addressing identity, physical and logical, as one common solution. We have seen firsthand the success of the Federal Government with FIPS 201, and we believe this provides the ideal identity framework for your future. When properly designed, we believe an advanced identity architecture drives business process improvement throughout your institution and will have many institutional benefits. Our biggest obstacle is often not the technology, but getting disparate departments within the institution to work together.
Finally, the greatest benefit of all may be a common compliance and audit trail. When we rely on a unique identifier (a private key) tied to an ID Card with multi-factor authentication, we have a trusted architecture. From that point on, we are not auditing multiple systems, nor fighting weak authentication methods; we simply wear the answer to trusted identity around our neck.
The United States federal government through the Department of Homeland Security and the Federal Emergency Management Agency are also promoting the use of FIPS 201 in healthcare. Properly designed, a healthcare identity architecture would assure proper accreditation of healthcare specialties and training in the case of a natural disaster. Building a national first responder identity framework may be one of the most important things we do to protect our Nation.
IAM Health, a division of IAM Technology, is pleased to support the dynamic healthcare industry with our Advanced Security Group, experts in advanced access control and security integration in healthcare. Let us be your guide through this rapidly changing industry.
Earlier this year President Obama signed into law the American Recovery and Reinvestment Act, equally known as ARRA or the Stimulus Act, providing over $38 Billion dollars to the advancement of electronic health records. This investment will transform the healthcare industry. Under the ARRA, physicians will receive a reimbursement premium on Medicaid payments for the use of electronic health records or will be penalized on Medicaid reimbursement beginning in 2015 if they fail to implement electronic health records.
The growth of electronic medical records raises the question of how we trust the integrity of the record: who updated the record, when, who’s liable for misuse, and who has rights to access to the record? It is time for the healthcare industry to embrace a new identity blueprint, an identity proven, flexible and secure. A Blueprint modeled after the success of a similar identity framework instituted throughout the United States federal government.
Building a Unified Path
Whether you are a CIO, CSO, or a Facilities Manager, beginning the process of review, scoping the needs for your future, and developing an identity plan is timely. In fact, you may find your existing access control credentials/cards weak by today’s standards. The vast majority of identity credentials for access control are first generation cards: proximity cards or MiFare Classic Cards. These radio frequency cards simple lack the hardened cryptographic protections to assure security in your healthcare facility. In fact, proximity cards and MiFare Classic Cards have been knowingly compromised by security researchers.
See a MiFare 4K attack in action: http://www.youtube.com/watch?v=NW3RGbQTLhE
Newer smart cards are developed with advanced cryptographic properties and better communication protocols. What this means is a more secure and effective card, one capable of securely authenticating to multiple applications. In fact, newer smart cards actually have a processor, enabling on card computing and advanced access control challenges. This is the case with all United States Federal government identity credentials by law. The Homeland Security Presidential Directive (HSPD) 12 instructed the National Institute of Science and Technology (NIST) to create Federal Information Processing Standard (FIPS) 201, a framework for the vetting, issuance, management and accreditation of identity products throughout the federal government. FIPS 201 is a contact and contactless smart card security framework that standardizes multi-tiered access and authentication. For advance authentication, one or more digital keys are stored on an advanced smart card processor. This is known as a Public Key Infrastructure or PKI, a security infrastructure based on unique private keys issued by a trusted server.
The Emerging Standard
The FIPS 201 standard provides Federal agencies with a blueprint for designing and implementing a comprehensive smart card credentialing program, and also provides the healthcare industry a standard for credentialing and security. The signing of HSPD-12 and the subsequent creation of FIPS 201 has been termed a landmark event for identity worldwide. For the first time, a formal standard now exists for governments and industry to purchase biometric and credentialing solutions with the assurance of interoperability and accredited trust. In conjunction with other federal ID programs like TWIC (the Transportation Worker Identification Credential), Registered Traveler and the FRAC (First Responder Access Card), the healthcare industry can now reliable implement enhanced credentials without fear of non-compliance to either Federal, State, or industry standards.
Progressive healthcare organizations are moving to FIPS 201 compatible architectures as a means of achieving a more holistic approach to security, incorporating personnel review (vetting, background checks, security training and awareness), logical security (network and application access), physical security (facility access), audit, and compliance reviews.
While there are many benefits to an advanced smart card credentialing framework in the near term, the majority of benefits will be gained as the electronic health record standards are implemented in the next three to five years. Today, we know the future standard of security on the health record exchange; this has been clearly established by the standards committees. To identify the creator of the record the healthcare standard is SAML (Security Assertion Mark-up Language). SAML is an authentication assertion that provides assurance of the provenance and integrity of the message (we will explore further below). An advanced identity framework similar in scope to FIPS 201 is not simply the right technical answer; it’s the right economic answer. Today, FIPS 201 shows us how to managed identity from a single card, a smart card.
Electronic Medical Records
The National Health Information Network (nHIN) embraces WS-Security (Web Services Security) as an internal message security protocol. WS-Security provides for XML Signature and XML Encryption, two elements that bind identity and encryption to elements of the message itself. In layman’s terms, the doctor can “notarize” her additions to a health record. She, in turn, can encrypt those additions for select recipients to decrypt. While this reaches beyond a traditional discussion of identity, it begins to reveal the scope of your healthcare institutions identity framework.
An advanced smart card architecture is the foundation for this architecture. It is easily audited and streamlines compliance checks. A common identity architecture that is used system-wide and integrated to HR systems, ERP systems, Active Directory , and physical access systems begins with the next generation of card architecture.
Summary
So we have gone on a journey from the security perimeter through the electronic exchange of medical records. We have highlighted the structural benefits of the United States federal standards for identity and credentialing; standards we believe the United States federal government will recommend for the healthcare industry. We believe there are compelling business drivers: ease of management, integration to ERP systems, convergence of identity physical and logical, lower OPEX (operational expense), possible CAPEX savings (capital expense), stronger cryptographic assurance of identity, multi-factor authentication, seamless integrity with electronic medical system, compliance to international and United States federal standards, federated trust between institutions, among others.
Is it time to explore the benefits of a common identity architecture? We certainly are encouraging our clients to explore the benefits of addressing identity, physical and logical, as one common solution. We have seen firsthand the success of the Federal Government with FIPS 201, and we believe this provides the ideal identity framework for your future. When properly designed, we believe an advanced identity architecture drives business process improvement throughout your institution and will have many institutional benefits. Our biggest obstacle is often not the technology, but getting disparate departments within the institution to work together.
Finally, the greatest benefit of all may be a common compliance and audit trail. When we rely on a unique identifier (a private key) tied to an ID Card with multi-factor authentication, we have a trusted architecture. From that point on, we are not auditing multiple systems, nor fighting weak authentication methods; we simply wear the answer to trusted identity around our neck.
The United States federal government through the Department of Homeland Security and the Federal Emergency Management Agency are also promoting the use of FIPS 201 in healthcare. Properly designed, a healthcare identity architecture would assure proper accreditation of healthcare specialties and training in the case of a natural disaster. Building a national first responder identity framework may be one of the most important things we do to protect our Nation.
Enterprise & FIPS 201
The FIPS 201 standard has provided Federal agencies with a blueprint for designing and implementing a comprehensive smart card credentialing program, but it also has provided industry a standard for credentialing and security throughout the enterprise. The signing of HSPD-12 and the subsequent creation of FIPS 201 has been termed a landmark event for the industry. For the first time, a formal standard now exists for government and industry to purchase biometric and credentialing solutions with the assurance of interoperability and accredited trust. In conjunction with other federal ID programs like TWIC (the Transportation Worker Identification Credential), Registered Traveler and the FRAC (First Responder Access Card), industry can now reliable implement enhanced credentials without fear of non-compliance to either Federal or industry standards.
Progressive organizations are pointing to FIPS 201 as a means of achieving a more holistic approach to security, incorporating personnel security (vetting, background checks, security training and awareness), logical security (network and application access), physical security (facility access, including video analytics), and incident monitoring and response. Although the current state of enterprise security may arguably be the best ever, enterprises still have a long way to go in terms of recognizing and breaking down various security “stovepipes” that result in disjointed and less than efficient security implementations.
Security convergence is a real and growing concept in the commercial world. Enterprises such as Sun, Boeing, Pfizer, Unisys, Lockheed Martin, Northrop Grumman and others are implementing smart card-based badges that provide employee access to both physical and logical resources. Vendors are building capabilities into systems so that physical access control systems can communicate with enterprise identity management systems and provide consolidated access control. Consolidating access control will enable corporations to realize some of the benefits that government agencies are beginning to enjoy. Centralizing operations that are often performed locally, such as personnel screening and vetting, can improve overall IT security and physical security. In addition, removing redundant stovepipe functions across an enterprise significantly reduces costs.
One of the most important benefits of using a FIPS 201 model in the enterprise is the strong assurance that the identity associated with a credential belongs to the correct individual. Special care needs to be taken early in the process so that the identity and associated credential can be trusted across logical and physical access control applications and across locations. FIPS 201 and the personal identity verification process identify a number of required steps and individuals and describes individual roles in the process:
• Sponsorship. A sponsor’s duty is to vouch for an applicant’s need for an enterprise credential and authorize applicant enrollment. The sponsor may also authorize the cost incurred by the credentialing process.
• Enrollment. The enrollment process is designed to verify the identity of an applicant and collect information from the applicant. Applicants must bring identification and are optionally fingerprinted and photographed at enrollment.
• Adjudication. Trusted adjudicators determine whether an applicant should receive a credential based on the results of the suitability check. Identity vetting procedures are part of the adjudication process, with disqualifiers defined as part of vetting procedures. Successfully passing adjudication triggers credential production. The level of adjudication varies from organization to organization, depending on the level of security/access required. Adjudication can be structured so that individuals who need access to something like a network operations center or security operations center are subjected to more extensive adjudication.
• Credential Production. Credentials can be personalized in a centralized facility or at local issuing stations. Relevant information is printed according to the standards, security features are added, and the electronic smart card chip is encoded with personal data.
• Issuance and Activation. When an applicant arrives to pick up the personalized credential, the issuer verifies the applicant’s identity by re-verifying the identity documents presented at enrollment and possibly matching the applicant’s fingerprint to the one used to enroll. The credential is then “unlocked,” digital certificates and a PIN are loaded onto the chip, and the credential is released to the applicant for use.
• Credential Use. Activated credentials can be used to validate identity electronically and access secure physical locations and computer networks. All of these process steps must be supported not only by technology but also by policies and procedures. It is only by the consistent execution and enforcement of policies and procedures that the overall integrity of the system can be ensured. FIPS 201 provides a best-practice framework for the entire identity proofing and issuance process that can be used by enterprises implementing robust employee identity management systems.
Enterprises have the opportunity to leverage the work that the Federal Government has done in FIPS 201 to define identity vetting and verification processes and specify conforming identity credential technology. While only Federal agencies can issue "official" cards, enterprises can follow FIPS 201 processes, use FIPS 201-defined technologies, and implement credentials that are interoperable or compatible, as appropriate. An interoperable credential is a credential that meets the FIPS 201 technical standards (and can therefore work with infrastructure elements, such as card readers) and also follows the FIPS 201 process for issuing credentials. Following the FIPS 201 process for credential issuance allows all Federal relying parties to trust the card, across organizations. This trust is established by a common enrollment, registration, and issuance process and a strong authentication credential that leverages a cross-certified and federated public key infrastructure. An interoperable credential would be of great value to enterprises that do business with the government and have a requirement to issue interoperable identity credentials. In addition, related organizations within an industry could decide to follow common FIPS 201 processes to establish a basis for trusting identity credentials across organizations or industry.
A compatible credential is a credential that meets the FIPS 201 technical specifications but does not follow the FIPS 201 process for credential issuance. Federal relying parties cannot automatically trust the card. Enterprises issuing compatible credentials can benefit by being able to use the growing range of products on the FIPS-201 Approved Products List. Cards, readers, software, and other products can be purchased from a variety of vendors, be connected, and function as a system.
FIPS 201 provides a defined framework and technical specifications for enterprises to:
• Follow a proven process for employee identity vetting;
• Implement an identity vetting process that provides the basis for trusting identities across organizations or with Federal agencies;
• Implement an identity credentialing solution that has the potential to be interoperable and compatible across organizations or with Federal agencies; and,
• Acquire proven products and services that meet FIPS 201 technical specifications from multiple vendors
The FIPS 201 standard delivers the following benefits to both government organizations and commercial enterprises:
• Specifies a “useful” and “secure” identity card that supports a wide range of use cases;
• Enables card support across a wide range of PCs, servers, and mobile devices;
• Defines processes and technical specifications that enable interoperability across organizations; and,
• Fosters competition to reduce prices
The FIPS 201 card offers the following advantages over other credentialing approaches for enterprises:
• It is supported by a wide range of manufacturers and integrators;
• It does not compel an organization to use a single vendor for key components;
• It provides flexible authentication, signature, and encryption functionality;
• It is well positioned to take advantage of emerging technologies, such as biometrics;
• As a standard that will be used by Federal agencies to issue credentials to millions of U.S. Federal employees and contractors, it has the advantage of scale; and,
• It provides the framework to support interoperable identity credentials across organizations.
Because of these factors, implementing a FIPS 201 card-based approach to identity credentials can be extremely beneficial to organizations. An organization using the FIPS 201 model and standard can take advantage of a high level of functionality at economical volume prices. The identity technology has been thoroughly scrutinized and is trusted at the highest levels. And, the credentialing process is flexible and has been thoroughly vetted to represent best practice.
The standardization of identity credentialing processes and approaches is a major step forward for identity management in both enterprises and government organizations. Standardization fosters interoperability. Standardization simplifies implementation by driving the industry to develop products, applications, processes, and practices that meet the standard and are interoperable. Standardization provides enterprises with a greater variety of products at a lower cost.
The FIPS 201 standard has established a foundation for both government and commercial identity credentialing programs. By using FIPS 201 as the basis for an employee identity credentialing system, enterprises can move toward standardized processes and technologies that enable interoperability and are supported by commercial off-the-shelf products from multiple vendors. By using FIPS 201, enterprises can take advantage of the investment being made by the U.S. government to implement standards-based identity credentialing programs.
Progressive organizations are pointing to FIPS 201 as a means of achieving a more holistic approach to security, incorporating personnel security (vetting, background checks, security training and awareness), logical security (network and application access), physical security (facility access, including video analytics), and incident monitoring and response. Although the current state of enterprise security may arguably be the best ever, enterprises still have a long way to go in terms of recognizing and breaking down various security “stovepipes” that result in disjointed and less than efficient security implementations.
Security convergence is a real and growing concept in the commercial world. Enterprises such as Sun, Boeing, Pfizer, Unisys, Lockheed Martin, Northrop Grumman and others are implementing smart card-based badges that provide employee access to both physical and logical resources. Vendors are building capabilities into systems so that physical access control systems can communicate with enterprise identity management systems and provide consolidated access control. Consolidating access control will enable corporations to realize some of the benefits that government agencies are beginning to enjoy. Centralizing operations that are often performed locally, such as personnel screening and vetting, can improve overall IT security and physical security. In addition, removing redundant stovepipe functions across an enterprise significantly reduces costs.
One of the most important benefits of using a FIPS 201 model in the enterprise is the strong assurance that the identity associated with a credential belongs to the correct individual. Special care needs to be taken early in the process so that the identity and associated credential can be trusted across logical and physical access control applications and across locations. FIPS 201 and the personal identity verification process identify a number of required steps and individuals and describes individual roles in the process:
• Sponsorship. A sponsor’s duty is to vouch for an applicant’s need for an enterprise credential and authorize applicant enrollment. The sponsor may also authorize the cost incurred by the credentialing process.
• Enrollment. The enrollment process is designed to verify the identity of an applicant and collect information from the applicant. Applicants must bring identification and are optionally fingerprinted and photographed at enrollment.
• Adjudication. Trusted adjudicators determine whether an applicant should receive a credential based on the results of the suitability check. Identity vetting procedures are part of the adjudication process, with disqualifiers defined as part of vetting procedures. Successfully passing adjudication triggers credential production. The level of adjudication varies from organization to organization, depending on the level of security/access required. Adjudication can be structured so that individuals who need access to something like a network operations center or security operations center are subjected to more extensive adjudication.
• Credential Production. Credentials can be personalized in a centralized facility or at local issuing stations. Relevant information is printed according to the standards, security features are added, and the electronic smart card chip is encoded with personal data.
• Issuance and Activation. When an applicant arrives to pick up the personalized credential, the issuer verifies the applicant’s identity by re-verifying the identity documents presented at enrollment and possibly matching the applicant’s fingerprint to the one used to enroll. The credential is then “unlocked,” digital certificates and a PIN are loaded onto the chip, and the credential is released to the applicant for use.
• Credential Use. Activated credentials can be used to validate identity electronically and access secure physical locations and computer networks. All of these process steps must be supported not only by technology but also by policies and procedures. It is only by the consistent execution and enforcement of policies and procedures that the overall integrity of the system can be ensured. FIPS 201 provides a best-practice framework for the entire identity proofing and issuance process that can be used by enterprises implementing robust employee identity management systems.
Enterprises have the opportunity to leverage the work that the Federal Government has done in FIPS 201 to define identity vetting and verification processes and specify conforming identity credential technology. While only Federal agencies can issue "official" cards, enterprises can follow FIPS 201 processes, use FIPS 201-defined technologies, and implement credentials that are interoperable or compatible, as appropriate. An interoperable credential is a credential that meets the FIPS 201 technical standards (and can therefore work with infrastructure elements, such as card readers) and also follows the FIPS 201 process for issuing credentials. Following the FIPS 201 process for credential issuance allows all Federal relying parties to trust the card, across organizations. This trust is established by a common enrollment, registration, and issuance process and a strong authentication credential that leverages a cross-certified and federated public key infrastructure. An interoperable credential would be of great value to enterprises that do business with the government and have a requirement to issue interoperable identity credentials. In addition, related organizations within an industry could decide to follow common FIPS 201 processes to establish a basis for trusting identity credentials across organizations or industry.
A compatible credential is a credential that meets the FIPS 201 technical specifications but does not follow the FIPS 201 process for credential issuance. Federal relying parties cannot automatically trust the card. Enterprises issuing compatible credentials can benefit by being able to use the growing range of products on the FIPS-201 Approved Products List. Cards, readers, software, and other products can be purchased from a variety of vendors, be connected, and function as a system.
FIPS 201 provides a defined framework and technical specifications for enterprises to:
• Follow a proven process for employee identity vetting;
• Implement an identity vetting process that provides the basis for trusting identities across organizations or with Federal agencies;
• Implement an identity credentialing solution that has the potential to be interoperable and compatible across organizations or with Federal agencies; and,
• Acquire proven products and services that meet FIPS 201 technical specifications from multiple vendors
The FIPS 201 standard delivers the following benefits to both government organizations and commercial enterprises:
• Specifies a “useful” and “secure” identity card that supports a wide range of use cases;
• Enables card support across a wide range of PCs, servers, and mobile devices;
• Defines processes and technical specifications that enable interoperability across organizations; and,
• Fosters competition to reduce prices
The FIPS 201 card offers the following advantages over other credentialing approaches for enterprises:
• It is supported by a wide range of manufacturers and integrators;
• It does not compel an organization to use a single vendor for key components;
• It provides flexible authentication, signature, and encryption functionality;
• It is well positioned to take advantage of emerging technologies, such as biometrics;
• As a standard that will be used by Federal agencies to issue credentials to millions of U.S. Federal employees and contractors, it has the advantage of scale; and,
• It provides the framework to support interoperable identity credentials across organizations.
Because of these factors, implementing a FIPS 201 card-based approach to identity credentials can be extremely beneficial to organizations. An organization using the FIPS 201 model and standard can take advantage of a high level of functionality at economical volume prices. The identity technology has been thoroughly scrutinized and is trusted at the highest levels. And, the credentialing process is flexible and has been thoroughly vetted to represent best practice.
The standardization of identity credentialing processes and approaches is a major step forward for identity management in both enterprises and government organizations. Standardization fosters interoperability. Standardization simplifies implementation by driving the industry to develop products, applications, processes, and practices that meet the standard and are interoperable. Standardization provides enterprises with a greater variety of products at a lower cost.
The FIPS 201 standard has established a foundation for both government and commercial identity credentialing programs. By using FIPS 201 as the basis for an employee identity credentialing system, enterprises can move toward standardized processes and technologies that enable interoperability and are supported by commercial off-the-shelf products from multiple vendors. By using FIPS 201, enterprises can take advantage of the investment being made by the U.S. government to implement standards-based identity credentialing programs.
Subscribe to:
Posts (Atom)
