Johnson & Johnson Use of Public Key Technology

1. Johnson & Johnson Use of Public Key Technology Rich Guida Director, Information Security

2. Johnson & Johnson • The world’s largest and most comprehensive manufacturer of health care products • Founded in 1886 • Headquartered in New Brunswick, NJ • Sales of $41.9 billion in 2003 • 198 operating companies in 54 countries • Over 110,000 employees worldwide • Customers in over 175 countries

3. Four Business Groups • Pharmaceuticals • Prescription drugs including EPREX, REMICADE • Medical Devices and Diagnostics • Blood analyzers, stents, wound closure, prosthetics, minimally invasive surgical equipment • Consumer Products • E.g., Neutrogena; SPLENDA • Consumer Pharmaceuticals and Nutritionals • E.g., TYLENOL

4. Statistics • 400+ UNIX servers; 1900+ WinNT/2000 servers • 96,000+ desktops/laptops (Win2K) • 60,000+ remote users • Employ two-factor authentication (almost all using PKI; a few using SecurID but being migrated) • 50M+ e-mails/month; 50+ TB of storage • 530+ internet and intranet servers, 3.3M+ website hits/day

5. Enterprise Directory • Uses Active Directory forest • Separate from Win2K OS AD but some contents replicated • Populated by authoritative sources only • Uses World Wide Identifiers (WWIDs) as index • Supports entire security framework • Source of all information put into certificates • 250K+ entries (employees, partners, retirees, former) • LDAP accessible

6. J&J PKI • Directory centric – certificate subscriber must be in Enterprise Directory • Certificate contents dictated by ED info (none based on “user-supplied input”) • Certificates issued with supervisor ID proofing • Simple hierarchy – root CA and subordinate online CA • Standard form factor: hardware tokens (USB) • Production deployment began early 2003 • Total of over 105,000 certificates (signature and encryption) issued to date • Most important initial applications: • Remote authentication • Secure e-mail • Some enterprise applications

7. Experience (1) • Training help desks (you can’t do too much of this…) • Ensuring sufficient help desk resources to respond to peaks (>100% of average level; fortunately reasonably short half-life) • Shifting user paradigms (always hard to change human behavior…) • Patience • Clear, unequivocal instructions/steps

8. Experience (2) • Hardware tokens • CSP issues of “passphrase caching” • User recovery from lost, stolen or destroyed token • Short term recovery (network userID/PW) • Long term recovery (new cert(s)) • Certificate revocation • Reason codes in CRL (25% increase in size of CRL) • Don’t give users options to select (too confusing to them) – ask questions instead (then automate reason code selection)

9. Experience (3) • We put in three identifiers in each cert (e-mail address, WWID, UPN) • Right thing to do for apps • Means employee transfer out/transfer in processes require getting new certs (since e-mail address changes) • HR controls those processes, not IM • Moral: smart IM technical/policy decisions may require implementation outside IM

10. Experience (4) • Once user gets new certs: • Register them with apps (e.g., Outlook S/MIME profile changes) • Link them to other user accounts (e.g., Nortel VPN client) • Thus – there are some additional steps to “migrate” to new certs • Not yet seamless

11. Experience (5) • Decryption private key recovery • User can do for his/her own (after authenticating) • Local Key Recovery Authority Officer can request for others • Global KRAO must approve • But – important to distinguish key recovery from revocation or getting new certs • Unclear terminology (to users) resulted in lots of unnecessary requests, none of which required approval

12. Experience (6) • CRL growth is always faster than you predict • Ours is approaching 1MB (expected it to be less than half that size) • Caching CRLs in Windows is “easy” but not obvious • IE manages CRL cache as part of “termporary internet files” folder • Standard setting for us was: flush that folder when IE is closed • Results in lots of CRL downloads