Core Security Patterns Weblog

Looks like convergence projects are in the limelight… lately I noticed a lot of interests on enabling the use of common credentials for securely accessing physical and logical resources.  Although we find most convergence projects are targeted at the enterprise level but there are serious minds working on using smartcard based PKI credentials for supporting citizen-scale projects (I regret that I cannot discuss the specifics) !  Ofcourse the use of on-card PKI credentials and its on-demand verification with the PKI service provider is in practice for a while now at security sensitive organizations. The DoD CAC, PIV and most smartcard based National ID/eIDs contain PKI certificate credentials and few of them includes Biometric samples of the card holder as well. Using those on-card identity credentials for accessing physical and logical resources becomes critical and also makes sense to  fulfil the ultimate purpose of issuing smartcard based credentials… it cannot be overstated.

Couple of weeks ago, I had a chance to present and demonstrate PIV card credentials based logical access control using Sun IDM, OpenSSO Enterprise, WinXP running on Sun Ray environment. The demo was hosted  one of the Big5 SI.  If you curious to see my preso detailing the pieces of the puzzle…here you go:

A month ago, I had a chance to meet with John Beveridge (Deputy State Auditor at Office of the State Auditor of Massachusetts) at an ISACA event in Boston. During a casual chat, he briefly mentioned about the upcoming regulation highlighting “Mass 201 CMR 17.00 – Massachusetts Standards for Data Protection of Personal Information”  and it’s compelling security requirements !  With all curiousity…I had my first dig at Mass 201 CMR 17.00 last week… it is the toughest data protection law so far (as a Govt initiative for preventing identity theft).. I am quite amazed by the stringent rules imposed by this regulation for protecting the personal identity information of Massachusetts residents. I am not a lawyer or an auditor by profession…so here is a my layman interpretation of the regulation and its dictated requirements for securing personal identity information.

• Comprehensive Information Security Program mandates ALL businesses that deals with personal identity information of Massachusetts residents  (in paper and electronic forms)  to provide  comprehensive documentation of all practiced security measures taken for preventing unauthorized access and ensuring confidentiality and integrity of the personal identity information.
  • Access control policies and rules for all employees who have access to identity information and enforce disciplinary action on those who violated the rules.
  • Upon employee termination, all physical and logical access privileges must be instantly revoked.
  • Third-party service providers need to comply with the Information security program and it requires a contractual binding before providing them access to personal information.
  • Identification of media including Laptops and PDA devices that store identity information and written procedures detailing how the physical access to those media is restricted.
  • Monitoring to verify the information security is operational preventing unauthorized access and support putting safeguards for minimizing both internal and external risks.
  • Require atleast an annual review and also whenever there is a material change has occurred in the business practices that relates to security and integrity of the information.
  • Documentation of incidents, response actions and post-incident review of events and actions.
• Secure User Authentication
  • Control of user identifiers and secure methods for selecting and assigning passwords.
  • Use of authentication technologies such as Token devices and Biometrics.
  • Restricting access to active users only.
  • Blocking access to multiple unauthorized access attempts.
• Data Encryption for all personal information in transit and storage.
  • Encryption of all records/files in storage (Laptops/other media) and transmitted over the wired/wireless networks.
• Firewall protection and Operating System Security Patches must be updated to support maintain the integrity of personal identity information.
• Malware and Virus protections ensuring all patches and definitions are updated on regular basis.
• Education and employee awareness training on the Information security program and practices.

Mass 201 CMR 17 data protection requirements aligns well with Federal Trade Commission’s Red Flag rules on Identity Theft Prevention. Some of the security practices has already been in use at many big companies addressing PCI-DSS, GLBA and HIPAA requirements. At the outset, this is a big business boost to Security architects and consulting companies deal with providing Information Security and identity management infrastructure and solutions.  This regulation supposed to be effective on Jan 1, 2009 and now for some reasons the deadline is extended till May 1, 2009 – Not sure it helps everyone – but the deadline for compliance is chasing and not too far !

It’s been a while, I had been hearing a lot of talk about unified biometric credentials and using then for convergence of physical and logical access control systems – Like me, you might’ve heard a lot of high-level marketing or analyst’s stuff … so here is some realities from my hands-on experience ! Frankly, there is no magic silver bullet that allows to support provisioning credentials to and from every Biometric middleware providers on the earth (poor standards..they are all proprietary) and it is another uphill task supporting their biometric data provisioning requirements to physical/logical access control systems (PACS and LACS).  With Sun Identity Manager, we can support selected biometric middleware integration through resource adapters but the complexity grows greater when we require provisioning of biometric data to a growing list of biometric middleware (AuthN providers, AFIS systems), PACS, LACS and Smart card management systems (CMS).  Lately, I had been working on a couple of interesting “Convergence” proof-of-concepts for ISVs aligned with PIV and National eID projects. Although it sounds great, converging the biometric credentials with heterogenous systems is not a trivial job, particularly when provisioning them for  smart card issuance  and further support post-issuance scenarios of enabling on-card/off-card biometric data for identification and authentication of individuals at heterogenous PACS and LACS systems. After thoroughly looking into the bottom of the issue, realizing and test-driving several usecases, with no option it become critical for us to enable biometric data as a managed attribute in Identity Manager – to support provisioning/de-provisioning of biometric data, changes and its associated reconciliation operations with PACS and LACS. This certainly helped us to exercise control on those discrete PACS/LACS resources that required provisioning of biometric credentials (for authentication/identification) and then ensuring no back-door account entry exists with the biometric middleware that circumvents IDM initiated biometric enrollment processes or rogue smart card issuance requests. This mandated us the Identity manager to support managing the complete provisioning/de-provisioning lifecycle of the user enrolled biometric information (i.e FIngerprints in CBEFF/INCITS-378 templates, Iris Image Interchange format/INCITS-379 templates, Facial images etc).

With Sun Identity Manager, we accomplished this through interfacing with biometric enrollment systems and enabled support provisioning/de-provisioning/reconciliation of biometric information by extending the identity attributes and establishing a managed database resource that stores CBEFF data as a CLOB.

Pre-requisites:

1. IDM Resource adapter that supports provisioning/de-provisioning/reconcilliation of user accounts with Biometric enrollment middleware.  Alternatively, you would able integrate through Java BioAPI (JNI Wrapper) if the biometric provider support BioAPI.
2. IDM access to Biometric enrollment repository database as a managed resource – Configured as a database resource. This resource is enabled with read-only access to the CBEFF information of the biometric enrollment system.
3. Extend the user attributes to include a Text/String attribute (bioAttribute) that identifies “Biometric Information”.
4. Ensure all user forms of target resources are updated to include a derivation that identifies the bioAttribute.
   <Field name=’accounts[$(TARGET_BIOMETRIC_RESOURCE_NAME)].bioAttribute’>
   <Display class=’Text’>
   <Property name=’title’ value=’bioAttribute’/>
   </Display>
   <Derivation>
   <ref>accounts[Database Table].pivData</ref>
   </Derivation>
   </Field>
5. Configure the  resource adpaters that requires provisioning of biometric information.  Incase, of provisioning of PIV Smart cards you may choose to use the XML Resource Adapter that captures all the demographic data and it can be combined to use the CBEFF information available from the ‘bioAttribute’ data obtained from the database resource.

We verified this solution with selected Biometric vendors and Smart card management systems (CMS) to support enabling “Convergence of biometric credentials use with Physical access control systems (PACS) and Logical access control systems (Using biometrics for Web SSO, Federation, Desktop authentication etc) . Sorry folks, I intentionally avoided identifying the vendor names to avoid any conflicts with my friendly ISV peers.

Last week, I was at the 7th Annual Smart Card in Government Conference and had the  opportunity to join a panel on “Personal Identity Verification (PIV) – Technologies” and presented a session entitled “Managing PIV Lifecycle and Converging Physical and Logical Access Control” with emphasis on implementing HSPD-12/FIPS-201 mandates.  I thoroughly enjoyed my participation in the conference, particularly the overwhelming  Smartcard and Biometric interests  from US Federal Govt organization, Law enforcement, Defence agencies and from other countries as well.

It is quite compelling to note,  the conference gave a big boost to FIPS-201 specfications that has become

Source: GSA USAccess

the de-facto standard for Identity credentialing for Govt. Employee ID, First Responder Credentials, Airport/Transportation worker credentials, Electronic Passports (ePassports) and  also sets the standards for acquiring and incorporating Demographic data, PKI/certificates and Biometrics for enabling Physical and Logical access control.

During my presence, I had quite a lot of conversations with participants for Govt agencies,  SIs and ISVs about implementing FIPS-201/PIV solution and how to automate identity credentialing  and pre/post issuance processes and provisioning/de-provisiong credentails to Physical access control systems and Logical access control systems (SSO/Federation) and finally how to respond to managing and auditing those discrete processes.

Managing PIV Life-cycle

If you are curious to have my presentation slides, you may grab it here : Managing PIV Lifecycle and Converging Physical and Logical Access Control.

Enjoy.