Case Study: Leveraging TPM for Authentication and Key Security

Transcription

1 Case Study: Leveraging TPM for Authentication and Key Security 09/20/2011 Gautam Muralidharan Manager, Advisory Services PwC

2 Speaker Introduction Gautam is a manager in the Advisory Technology practice at PwC. Gautam has 8 years of experience designing, developing, and implementing complex Identity and Access Management (IAM) systems. Gautam brings in-depth knowledge and experience in security architecture, development tools, and IAM software packages. He has combined those experiences with the latest technologies to design and implement scalable Sign-On solutions, user management and authentication/ authorization systems across mixed platform environments. He is currently serving as the chief-of-staff to the US Advisory Security Leader for PwC. gautam.muralidharan@us.pwc.com

3 PwC Advisory Security Services Our Information Security Solutions help IT leaders and decision-makers integrate information security into strategic decision-making processes across the enterprise in order to better drive business performance, manage risk, and increase shareholder value. 4,700 professionals in North America 8,000 professionals in EMEA 3,900 professionals in Asia Pacific 850 professionals providing services in matters related to security and risk to geographies outside of North American, EMEA, and Asia Pac PwC s professional services are delivered to clients by a workforce of over 150,000 employees and partners in 850 locations spread across 142 countries. Primary Lines of Service include Audit, Assurance and Business Advisory Services, Global Tax Services, Business Process Outsourcing, Corporate Finance and Recovery Services, and Human Resource Services. Also composing PwC are Internal Firm Services organizations, which include Finance, internal Human Resources, Infrastructure and Information Technology (IT). The PwC IT organization provides internal IT services to the Firm. For further information visit our web site at: 3

4 Agenda Our Journey Considerations and Lessons learned Questions 4

5 Our Journey 5

6 What do we use PKI for WiFi access (PKI based authentication and tunneling) VPN access (identification and authentication) LAN access (IEEE802.1x pre-authentication) Aura (P2P sync, data transport encryption, authentication). Code signing (trusted applications). Internet Explorer webpages working with Digital Certificates Any other usage when you need more security than a simple Global ID+password. 6

7 Risks we considered with our current solution You have created the key pair. You have fulfilled a process to convince others that it is you they are communicating with (Identity Proofing). All this, only because you are the owner of the Private Key and the accompanying Digital Certificate. But what happens if you are not the sole owner of the Private Key anymore, e.g. your Private Key is stolen or copied by me? Then I can impersonate you! So what? E.g. your colleague wants to exchange an Aura client file and searches on the network for You to setup a peer-to-peer connection. Your name pops up (actually it is me with your Private Key). He trust this and start sending me the sensitive client file. 7

8 Risks we considered with our current solution The Private Key is stored on hard disk and is protected by the CSP. Jailbreak is software that can steal a Private Key. The Public Key is already public so the key pair can be used by others! E.g. a stolen Private Key and certificate on a Debian (Linux) PC running a VPN to PwC and having a Remote Desktop Connection to a PwC Windows server : 8

9 We wanted to move to a more secure alternative This is not what we want to read in the morning papers. So, the Private Key must be protected at all times! But, in the current situation the Private Key cannot be protected because it is stored by software (on the hard disk). Even when the Jaibreak exploit is repaired it could be possible that there will be other exploits. The solution preventing the theft of Private Keys? Store Private Keys in tamper resistant hardware! But, cryptographic hardware is expensive and hard to maintain. And, usually you have to buy proprietary (expensive) hardware which does comply to certain standards only. 9

10 Solutions we considered and challenges USB dongles: Additional hardware costs No open software standard Lost/Stolen management overhead Reluctance of business to have additional device Smartcard (SIM, USB or proximity): Additional Hardware required Expensive No open standard Additional provisioning requirements Additional management costs Lost/Stolen management overhead Reluctance of business to have additional device Not centrally managed Trusted Platform Module (TPM): Possible changes to PwC certificate management application required depending on architecture design. Requires additional laptop/desktop provisioning/lifecycle management processes Tied to single machine 10

11 Why we picked TPM Already in 95+% of our laptops Is based on open standards Gives FIPS protection Can be centrally or locally managed Cheap (no hardware costs) Protects against Jailbreak and similar tools Delivers additional secure cryptographic functions (trusted startup, random number generator, digital signature etc.) Minor changes in PC Lifecycle Management. TPM setup in a few minutes Our applications worked well with TPM often with minimal to no code change 11

12 TPM implementation Example: VPN Multifactor Authentication with TPM When you want to connect to the PwC network through VPN, you need a: 1. Digital Certificate and Private Key (1 st factor, have ) 2. GUID and GUID password (2 nd factor, know ) No changes to the infrastructure when using the TPM and no Jailbreak vulnerability anymore! 12

13 Considerations and Lessons Learned 13

14 Phased approach to implement multifactor authentication solutions Collect Requirements Develop detailed business and technical requirements Solution & Vendor Selection Develop RFP based on requirements and select vendor Execute Pilot Facilitate pilot with a small subset of users to determine solution suitability Design & Implementation Integrate of the solution into environment Solution Rollout & Ongoing Operations Solution roll-out across enterprise and knowledge transfer to operational resources 14

15 Key steps in a Multi Factor Authentication deployment Determine requirements for two-factor authentication from key stakeholders Conduct a current state ("as-is") analysis of two-factor authentication and supporting processes Design future state of multi-factor authentication along with supporting processes. Solution design will take into account multiple user communities including service accounts, administrators, contractors etc. Select a flexible and scalable vendor solution that supports requirements Integrate solution management with existing Identity management system Ensure that the selected solution is compliant with relevant legal and regulatory requirements Develop end user deployment strategy, including change management and communication. Provide detailed and comprehensive framework to support operational process components (i.e. issuing cards, lost cards, training, policy and procedures, etc) Develop documentation to support rapid solution integration at other businesses 15

16 Ask these questions Business Technology Is the solution currently supported in organizations operating in multiple countries/regions? Are other large conglomerates/industry peers using this vendor? Is the solution scalable? What are the impacts to user experience if this solution is deployed? Is the registration process implicit, transparent, history based or explicit/formal? What are the additional hardware/software (smart card readers/gina modifications/csp additions) requirements for a functioning solution in your environment (Windows/Unix)? What is lost/stolen cards/token process? How is the authenticating information stored on the token/smart card (plain text/encrypted)? How are the end-user private keys protected (pin/password/biometric)? Has the solution been integrated for provisioning with an Identity management solution? What is the extent of integration (automated, notification based) What application integration methods (e.g. API, redirect/filter, agent, etc.) are supported? 16

17 Lessons Learned Project/ Program Structure and Approach Organization and People Process and Data Areas of Concern Project led by technology group without high-level partnership with the business No business executive sponsorship Failure to understand enterprise nature of multi-factor authentication solutions Boil the ocean scope and approach big losses vs. quick wins Failure to set realistic expectations The processes, technology and people span across multiple geographies, business units and functional areas priorities, objectives and agendas aren t always aligned Lack of resources and experience to adequately build and maintain solution Operational impact is not fully contemplated during planning and design phases technical and end user Lack of documented understanding of current and future state processes Regulatory and compliance risks over or under controlled Data management challenges what to protect? How much to protect? Technology Product selection is the strategy Rushing to implement product before business requirements are defined Buying into vendor rhetoric it s not simple Poor understanding of the scale and impact of the technology Critical Success Factors Active high-level business executive sponsorship Clear project/program charter defined Clear definition of roles and responsibilities Agreed upon guiding principles and objectives Short-term, mid-term and long-term milestones Dependencies and inter-dependencies well understood Broadly accepted success criteria Business and IT ownership/sponsorship Communications and change management integration within program Define roles and responsibilities entire lifecycle Training technical, functional and end users Document and maintain current process workflows Develop new process use cases before project requirements Address data issues first Select solutions after business requirement and processes are defined and accepted Form strong, open relationships with implementer and vendor(s) Test, and pilot and test again! 17

18 Summary With 400 million TPMs already deployed it is the best kept secret in information security It is a well defined Open Standard and has low costs to deploy The only universal security device in different brands of PCs that worked for us Key lessons learned Use a phased approach to deploy your solution Get business/senior management to support Understand impact to your users Product selection is the strategy work closely with vendors Pilot, test and document 18

19 Questions Gautam Muralidharan PwC

20 This publication has been prepared for general guidance on matters of interest only, and does not constitute professional advice. You should not act upon the information contained in this publication without obtaining specific professional advice. No representation or warranty (express or implied) is given as to the accuracy or completeness of the information contained in this publication, and to the extent permitted by law, PricewaterhouseCoopers does not accept or assume any liability, responsibility or duty of care for any consequences of you or anyone else acting, or refraining to act, in reliance on the information contained in this publication or for any decision based on it PwC. All rights reserved. "PwC" refers to PricewaterhouseCoopers LLP, a Delaware limited liability partnership, which is a member firm of PricewaterhouseCoopers International Limited, each member firm of which is a separate legal entity. This document is for general information purposes only, and should not be used as a substitute for consultation with professional advisors 20