Hitachi ID Password Manager Deployment Best Practices

Transcription

1 Hitachi ID Password Manager Deployment Best Practices 2016 Hitachi ID Systems, Inc. All rights reserved.

2 Contents 1 Introduction 1 2 System objectives 3 3 Mission statement 4 4 Metrics 5 5 Stake-holders 6 6 Deployment and support team 8 7 Features and design 10 8 User access to the self-service UI 12 9 Formulating a uniform password policy Strategy Suggested policy rules Where to enforce password policy Equivalent credentials Security questions Security equivalence Memorable questions Other best practices Sample questions Augmenting security questions with a second factor Infrastructure integrations Hitachi ID Password Manager: technical architecture Number and location of servers Configuration of individual servers Development, test and production environments i

3 14.4 Proxy servers for hard-to-reach target systems Hitachi ID Password Manager: server hardening Overview Physical security Operating system access IIS configuration SQL Server configuration Hitachi ID Password Manager: BYOD access to on-premise credential management Auto-discovery of user profiles and accounts Selecting sources of profiles Mapping login IDs to user profiles User enrollment Maximizing user adoption and ROI Minimize password problems User awareness Incentives for enrollment Automated reminders A call to IT support is not the right time to enroll Charge-backs and manager feedback Reduce SLA for help desk calls Plan for user adoption Ongoing administration and support Functional test Password changes Enrollment Transparent password synchronization Help desk logins Sending s Creating call tracking system ticket Hitachi ID Systems, Inc. All rights reserved.

4 IVR (phone call) integration Mobile access Off-site, Windows login screen access Filesystem unlock Changes to target system configuration Monitor service health Monitor utilization Summary Hitachi ID Systems, Inc. All rights reserved.

5 1 Introduction This document outlines best practices for designing, installing and rolling out Hitachi ID Password Manager to manage credentials for on-premise and SaaS systems and applications. The remainder of this document is organized as follows: System objectives what credential management systems are designed to do. Mission statement how organizations should structure their internal communication about priorities and objectives. Metrics how to measure the impact on the system. Stake-holders who to involve in design, implementation and ongoing support. Deployment and support team who the core individuals are that must build out and support the system and what their initial and long term commitment will be. Features and design what processes the system should automate. User access to the self-service UI how to ensure that users can resolve login problems wherever they may be, at any time and on any device in any state. Formulating a uniform password policy how to develop a set of password rules that work for every system and every user community. Equivalent credentials caution about weak links in security and how to avoid them. Security questions design considerations for enrolling security questions and using them to authenticate users who forgot their password. Augmenting security questions with a second factor how to improve security by front-ending security questions with a stronger, one-time-password credential. Infrastructure integrations what systems the credential management automation should integrate with. Password Manager: technical architecture the runtime platform and network architecture on which Password Manager is deployed. Password Manager: server hardening how to lock down OS, DB and web servers to protect the system. Password Manager: BYOD access to on-premise credential management how to enable users to access self-service from their phones or tablets, which are typically not attached to the corporate network. Auto-discovery of user profiles and accounts how to minimize care and feeding of the system using auto-discovery. User enrollment inviting users to answer security questions; install smart phone apps; etc Hitachi ID Systems, Inc. All rights reserved. 1

6 Maximizing user adoption and ROI strategies to get users to enroll and to use the system to resolve login problems. Ongoing administration and support what can be expected in terms of long term care and feeding of the system Hitachi ID Systems, Inc. All rights reserved. 2

7 Hitachi ID Password Manager Deployment Best Practices 2 System objectives A credential management system should deliver three benefits: Improved user service: Fewer credentials for users to remember and manage and simpler, quicker and more convenient resolution for login problems. Lower IT support cost: Fewer help desk calls related to login problems such as forgotten passwords, intruder lockouts or tokens left at home. Stronger security: Stronger and more consistent enforcement of policies around password composition, change frequency and reuse, as well as more reliable processes to authenticate users who experience a login problem, before assisting them Hitachi ID Systems, Inc. All rights reserved. 3

8 Hitachi ID Password Manager Deployment Best Practices 3 Mission statement A mission statement documented before the system is deployed is helpful for getting all stake-holders to cooperate. One way to formulate this mission statement is to capture the state of affairs before the system is deployed and the desired end state. Following is an example: Before User service / SLA Users manage 8 different passwords, on average. Only some passwords expire and they do so at different times Different systems enforce different password policy rules. Users sometimes forget their pre-boot password. Users sometimes forget their OS login password, in some cases while off-site. Credential management system objectives After With password synchronization, users will only have to manage 2 passwords. Users will be prompted to change all passwords at the same time. A uniform password policy will supersede multiple, inconsistent rules. Enable self-service filesystem unlock via smart phone app. Enable self-service password reset from the PC login screen, with VPN+WiFi integration to support users working outside the office. IT support cost 30% of total help desk call volume is due to login problems. 5% of total call volume is due to OTP token problems. Help desk calls to resolve login problems take 10 minutes to resolve, on average. Password synchronization and self-service problem resolution will reduce this call volume by at least 80%. Offer self-service PIN reset and emergency passcodes via smart-phone app. Consolidate caller authentication, technician login, problem resolution and ticket generation behind a single UI, to reduce call duration to 2 minutes. Security / authentication Users have too many passwords and write them down. Different systems and applications enforce different password policies. Users calling the help desk are not reliably identified. Not all systems log password changes. Too many IT support staff have logins with elevated rights, required to reset passwords for people who call the help desk. Synchronization will eliminate the main user motivation for writing down passwords. Implement a uniform policy with a superset of password composition, reuse and change frequency rules. Move most incidents to self-service and apply uniform authentication processes in both self-service and assisted-service contexts. Will record who changed passwords, on a central credential management system. Support staff will reset passwords through an assisted-service portal, eliminating the need for such accounts Hitachi ID Systems, Inc. All rights reserved. 4

9 Hitachi ID Password Manager Deployment Best Practices 4 Metrics Before deploying a credential management system, it is useful to identify and start recording metrics. Once the system is deployed, continuing measurement of the same metrics will show its impact. Following are some relevant metrics: 1. Number of systems that maintain their own, distinct password, rather than leveraging Kerberos, LDAP, SAML, etc. to externalize authentication. 2. Number of distinct passwords an average user must remember and manage. 3. Average number of login prompts faced by a user, during a work day. 4. Number of systems (with their own passwords) able to enforce password complexity rules consistent with enterprise policy. 5. Password change frequency required versus actually enforced. 6. Help desk call volumes related to login problems: (a) Forgotten passwords, per system, per month. (b) Intruder lockouts, per system, per month. (c) Filesystem lockouts (forgotten pre-boot password), monthly. (d) Token problems (left at home, lost, stolen, forgot PIN), monthly. (e) Forgotten passwords by users off-site, monthly. This is different than forgotten passwords per system because it refers to users who cannot unlock their PC until they bring it back to the office an especially disruptive type of problem Hitachi ID Systems, Inc. All rights reserved. 5

10 5 Stake-holders A credential management system has many integrations, each of which has an owner: endpoint devices, servers, applications, incident tracking systems, infrastructure, VPN, VoIP or other telephony systems and multi-factor authentication platforms. It impacts security, IT support and audit. It is important to get buy-in from every stake-holder early in the project, to avoid objections, delays and implementation risk. An authoritative sponsor is essential to get buy-in from a diverse group of stake-holders. Because of the large number of interested parties, it is almost inevitable that somebody will raise objections, try to change priorities or alter previously agreed-to designs. Too many interruptions like this will derail the project. A high profile business sponsor reduces these risks. The following stake-holders should be engaged as early as possible when deploying the system and should sign off on objectives as described in Section 2 on Page 3: Project Sponsor: Provide mandate and budget for the project. Ensure cooperation from other stake-holders. Project Manager: Ensure the project is managed effectively by providing and coordinating customers resources. Network Architect: Develop and approve network-level design documents. Place servers on the network and specify integrations, for example with VPNs, SSL concentrators, reverse web proxies, etc. Credential management application administrator: Responsible for ongoing configuration, administration, enhancement and upgrades to Hitachi ID Password Manager, post production deployment. Assists in implementation of the system prior to moving to production, in order to gain maximum familiarity with the software and configuration. Security Officer: Review, document and approve any changes that impact corporate security, including policies, authentication processes, SIEM integration, VPN integrations, any service or generic accounts, etc. Auditor: Define audit requirements, such as data retention, periodic review of user privileges, etc. Periodically review activity on the system. IT support manager: Often fund the system, to reduce call volumes and head count. Provide integration details and support for ticketing system. Define user-support processes. System administrators: (for every integrated system) Provide integration details for each target system, provide service accounts and test IDs and verify correct operation. Assist with troubleshooting integrations. Intranet manager: Provide user interface standards, including sample HTML, CSS and JS, to ensure that Password Manager matches enterprise standards Hitachi ID Systems, Inc. All rights reserved. 6

11 Network operations: Support deployment of servers, including hardware, VMs, OS images, DNS names, network routes, SSL certificates and/or termination, load balancing and system health monitoring. Desktop support: Deploy client-side code and policies that allow/block execution of same Hitachi ID Systems, Inc. All rights reserved. 7

12 6 Deployment and support team Identity management and access governance projects tend to be long and indeed may never end, as deliverables are continually added over the life of the system. Organizations go through both business and infrastructure changes: reorganizations, hardware upgrades, new operating systems, new applications, etc. These changes trigger matching requirements in the identity management and access governance infrastructure and consequently lead to implementation and maintenance effort over the life of the system. This is not to imply that individual deliverables cannot be implemented quickly and operated at low cost. Rather, it means that successful implementation of one feature or integration usually triggers interest by a wider range of stake-holders, who request further work, to deliver more features and integrate with more infrastructure. With this in mind, it can be helpful to think of identity management and access governance implementation in terms of a process of continuous optimization, which is the responsibility of a permanent team, rather than a single, finite project. Successful organizations respond to this by instituting a permanent identity management and access governance program, rather than staffing for a finite-term deployment project. This team should include a permanent technical application administrator and a permanent application owner, at a minimum. The Hitachi ID Password Manager product administrator position can be a fractional FTE (e.g., 0.25). As with any long term program, it is important to have clear buy-in from stake-holders and an up-front agreement on project scope, deliverables, duration and cost in order to sustain investment and deliver on business expectations. Without such early commitment by stake-holders, project work may be aborted before deliverables are reached. The permanently assigned customers team should consist of one or two individuals who have as many of the following skills as possible: System and process design: Security policy. Network and data architecture. IT support infrastructure and processes. Product installation, ongoing administration: Windows / AD administration. Web server configuration and management. Web application deployment and administration. Initial integration and ongoing updates and extensions: Familiarity with each target system. IT support infrastructure and processes. infrastructure. IVR (interactive voice response) infrastructure, if telephony integration is in scope. Development of business logic: Programming or scripting (e.g., Perl, VB, Java, etc.) Hitachi ID Systems, Inc. All rights reserved. 8

13 Familiarity with data sources: LDAP, RDBMS, etc. Familiarity with web applications, including HTML and optionally (to support a more interactive UI) JavaScript. UI customization: HTML and CSS markup. JavaScript and AJAX if highly interactive forms are in scope. Deployment and ongoing support: IT support infrastructure and processes. User education. Metrics Hitachi ID Systems, Inc. All rights reserved. 9

14 7 Features and design The first step in deploying a credential management system is to specify what processes it will implement. All stake-holders must sign off on a design, preferably in writing. Hitachi ID Systems recommends deploying as many automated processes as possible, as each process adds value. It s a good idea to capture the motivation for each feature before starting deployment, as this helps new stake-holders understand not only what s being undertaken but also why. Following is a list of Hitachi ID Password Manager features. Customers typically deploy most of these, but which ones they include depends on their priorities and whether they actually have the relevant infrastructure (e.g., full disk encryption software, smart cards, etc.). Transparent password synchronization: When users change their password natively on a system where a password synchronization trigger has been installed, the new password is tested for strength against the Password Manager password policy and, if accepted, is changed both locally and on other systems where the user has accounts. Password Manager includes password synchronization triggers for Windows server or Active Directory (32-bit, 64-bit), Sun LDAP, IBM LDAP, Oracle Internet Directory, Unix (various), z/os and iseries (AS/400). Using a familiar and mandatory password change process guarantees 100% user adoption. Web-based password synchronization: Users can change some or all of their passwords using the Password Manager web interface. The password policy is clearly explained on-screen and enforced interactively. Using an interactive web page to change passwords has educational benefits but requires user awareness and cooperation. Self-service password reset: Users who have forgotten a password or triggered an intruder lockout can sign into Password Manager using other types of credentials to reset their password or clear the lockout. Non-password authentication options include security questions, voice biometrics, smart cards, hardware tokens and random PINs sent to a user s mobile phone using SMS. Access to self-service is available from a PC web browser, from the Windows login screen, using a telephone or using the mini web browser on a smart phone. Self-service filesystem unlock (pre-boot, full-disk encryption) Users with full disk encryption software on their PC, who have forgotten the password that unlocks their computer prior to OS startup, can unlock their hard disk using a self-service process accessed via telephone. Password Manager includes a turn-key integrated voice response (IVR) system designed to automate password resets, PIN resets and unlock of encrypted filesystems via a self-service phone call. It ships with connectors for popular full disk encryption products from McAfee, CheckPoint, Symantec and Microsoft. Token and smart card PIN reset: 2016 Hitachi ID Systems, Inc. All rights reserved. 10

15 Users with a token who have forgotten their PIN or need an emergency pass code can access selfservice PIN reset with a web portal or using a telephone. Users with a smart card can also reset their own PIN using an ActiveX control embedded in a web browser launched from their Windows desktop or login screen. Assisted password reset: Authorized IT support staff can sign into a Password Manager web user interface to look up a caller s profile, authenticate the caller by keying in answers to security questions and reset one or more passwords. A ticket can be automatically submitted to the help desk incident management system. Password policy enforcement: Password Manager normally enforces a global password policy to supplement the various policies enforced on each system and application. This policy ensures that passwords accepted by Password Manager will work on every system. The built-in policy engine includes over 50 built-in rules regarding length, mixed-case, digits, dictionary words and more. Regular expressions and plug-ins enable organizations to define new rules. Password history is infinite by default. Password change notification / early warning: Password Manager can remind users to change their passwords, either using a native password change dialog or via the Password Manager web portal. Warnings are normally sent to users before their password actually expires on AD, LDAP or other systems. These invitations can be sent via or launched in a web browser when users sign into their PCs. Users can even be forced to change passwords by launching a kiosk-mode web browser when the user signs into their PC. Password change reminders are normally only sent at the start of users work day and work week, to discourage users from changing passwords right before leaving work and subsequently forgetting the new password Hitachi ID Systems, Inc. All rights reserved. 11

16 Hitachi ID Password Manager Deployment Best Practices 8 User access to the self-service UI Users should be able to resolve login problems wherever they happen to be, using whatever device is most appropriate and convenient, regardless of the state of their device. This means on-site at the office and also remote, from a browser on their PC, or their PC login screen, or a mobile device, and from the password prompt of their PC login screen, which asks for a (forgotten) password. Some of these contexts present technical challenges, which the credential management system should address: 1. A user who forgot or locked out their PC login password needs to be able to navigate to a password reset system from the PC login screen (Credential Provider on Windows Vista and later). Password reset via phone call or mobile app or another PC is not a satisfactory solution, because the user s password is cached locally on the PC and should be updated by the password reset process. For the same reason, VPN integration is required, so that when a user is off-site and forgets their PC login password, the new password can be injected back into the PC, making it usable again. 2. A user who forgot their pre-boot password, used to unlock a full disk encryption product, needs to be able to interact with an unlock process to boot the OS on their PC. Later, once they have started up the OS, they can update the pre-boot password. Since there is no web browser in the pre-boot context, resolving pre-boot lockouts requires either a voice phone call or an app on the user s smart phone. 3. A user who is off-site and has problems signing into the VPN should be able to interact with a solution on the Extranet, or via a phone call, or using an app on their smart phone, to unlock their credentials (typically a one time password token such as RSA SecurID). 4. A user who forgot the PIN to their smart card needs to interact with an application on their PC, rather than a smart phone app or voice phone call, since problem resolution involves inserting the card into a reader and having software push an unblock code into the smart card. Smart cards are often used as the main PC login credential, so this kind of self-service needs to be made available at the PC login screen, rather than just from a web UI available to the already signed-on desktop Hitachi ID Systems, Inc. All rights reserved. 12

17 Hitachi ID Password Manager Deployment Best Practices 9 Formulating a uniform password policy 9.1 Strategy Hitachi ID Password Manager is normally configured to enforce a uniform password policy across all systems, to ensure that any new password will be acceptable to every integrated system. This provides the most clear and understandable experience to users. Password Manager is configured such that it will never accept or propagate a password that will not meet this global password policy. For instance, in the case of an organization that has both Windows Active Directory (AD) and z/os passwords, where users may enter very long passwords on AD but only 8 characters on the mainframe, Password Manager can require that passwords be exactly 8 characters long. Alternately, Password Manager can support longer passwords, but truncate them when it updates the mainframe (users generally prefer a fixed length, as it is easier to understand). All systems enforce two types of password rules: Complexity requirements ensure that users do not select easily-guessed passwords. Example rules are: disallowing any permutation of the user s login ID, password history, requiring mixed letters and digits, forbidding dictionary words, etc. Character set and length limits on what can be physically stored in the password field on a given system. A global password policy is normally created by combining and strengthening the best-of-breed complexity requirements from each system affected by the policy. Password Manager then combines these with the most restrictive storage constraints. This forces users to select strong, secure passwords on every system. The alternative, of defining different password policies for every target system or for groups of target systems, is less user friendly. To update their passwords, users must select a system, choose a password, wait for the password update to complete, choose another system, select and input a different password, etc. Users must then remember multiple passwords and will continue to experience many password problems. It has been shown that users with many passwords have a strong tendency to write down their passwords. 9.2 Suggested policy rules The recommended global password policy depends on the system with the most limited password fields. In many large organizations, this is often a z/os mainframe, which only supports 8-character passwords, composed of letters, digits and three special characters (@, #, $). For organizations with a mainframe Length: 7 or 8 characters. Characters: at least 2 letters, at least 1 digit, specials must # or $. Special words: no dictionary word, login ID or permutation thereof Hitachi ID Systems, Inc. All rights reserved. 13

18 Repeats: no more than 1 pair of repeating characters. There are 39 possible characters in a password (letters, digits, 3 specials). Note: the total search space is = 5, 489, 240, 267, 160 possible passwords. For organizations without a mainframe Length: 7 or more characters. Characters: at least 2 letters, mixed case, at least 1 digit. Special words: no dictionary word, login ID or permutation thereof. Repeats: no more than 1 pair of repeating characters. There are 95 possible characters in a password (lowercase, uppercase, digits, 32 symbols on a US keyboard, space). Note: the total search space is no less than 95 7 = 69, 833, 729, 609, 375 possible passwords. 9.3 Where to enforce password policy Password policy is enforced on both the Hitachi ID Password Manager server and each of the managed systems. Ideally, each managed system enforces the largest possible subset of the policy rules enforced on the Password Manager server. In cases where a managed system initially had a rule that conflicts with the new global policy (i.e., it is impossible to compose a password that is simultaneously compatible with both the old native policy and the new global policy), the native policy should be adjusted to be compatible. Password policy must not be disabled on any existing system, as this would allow users to bypass policy by making native password changes, without interacting with Password Manager. Password policy must not be disabled on the Password Manager server, as this would allow users to bypass policy by making password changes using Password Manager, whose password resets are often subject to lesser restrictions when it commits new passwords to integrated systems Hitachi ID Systems, Inc. All rights reserved. 14

19 Hitachi ID Password Manager Deployment Best Practices 10 Equivalent credentials Password synchronization makes the security of managed systems equivalent, in the sense that if an intruder can compromise one password, the intruder can infer the value of the same user s passwords on other systems. Password reset processes make passwords equivalent to the non-password authentication used to identify users who forgot their passwords or locked out their account. Single sign-on makes the security of all in-scope applications the same as the security of an initial authentication. Enrollment processes create security equivalence between the process used to sign into the enrollment system (usually a password) and the security questions or other data that are subsequently enrolled. Organizations that do not take these connections into account can inadvertently lower the security of their entire organization. For example, if password reset processes authenticate users purely using security questions, and if the answers to those security questions are collected in an enrollment process, then the security of user profiles is only as good as the security of the credentials used to enroll those security questions. Some organizations use a PIN, sent via or physical mail, to authenticate users prior to enrolling security questions. This makes the security of all subsequent passwords only as a good as that first PIN incredibly weak. To ensure that user profiles are secure, follow these guidelines: Password synchronization should go hand in hand with a requirement to use strong, frequentlychanging passwords. Password synchronization should not include systems with very weak security infrastructure (e.g., systems that store password in plain-text, or that have no intruder lockout mechanism triggered by repeated failed logins). Self-service password reset should incorporate multi-factor authentication, such as sending a PIN to the user s phone or as a first authentication step and answering security questions as the second step. Where self-service password reset relies on security questions, the number and complexity of questions should be maximized, within the bounds of usability. Security question enrollment can follow authentication with an existing, strong password. It is not acceptable to authenticate users with a static or short PIN, an employee number or a date of birth not even to enroll security questions. IT support staff should authenticate callers with a process just as strong as is used for self-service. Where privacy legislation prohibits some security questions, use other questions at the help desk, but don t use fewer or weaker ones Hitachi ID Systems, Inc. All rights reserved. 15

20 Hitachi ID Password Manager Deployment Best Practices 11 Security questions Most organizations use security questions as at least part of the process for authenticating users who forgot or locked out their password Security equivalence A password reset process makes the security of password authentication equivalent to the security of nonpassword authentication. This means, for example, that there is no sense in enforcing a strong password policy if users are authenticated to a password reset system with a 5 digit PIN, such as the last part of a social security number Memorable questions Since password reset is provided to users who forgot their password, it makes sense to setup security questions whose answers users will not easily forget: 1. It is not reasonable to use yet another password to authenticate users to a password reset system: if they forget the password they use daily, they won t remember a password that was assigned to them months or years in the past. 2. Security questions should have static, factual and memorable answers. Avoid questions whose answers may change over time, such as what is your favorite movie? 11.3 Other best practices Some additional recommendations for authentication with security questions: 1. Combine free-form and pre-defined questions Ask users to enroll answers to standard questions, as the difficulty of guessing answers to these can be estimated. Also ask users to define their own question/answer pairs, as an attacker will not know what questions to research. Users often choose weak questions, so these should always be combined with standard questions, of a known quality. Always prompt users to answer standard questions first, and only ask for answers to self-defined questions if correct answers to standard questions were entered. This reduces the odds that an attacker will know what user-defined questions to research. 2. Avoid personally identifying information Ask legal counsel to review the offered, standard security questions. Avoid questions which may have legal consequences, such as social security numbers Hitachi ID Systems, Inc. All rights reserved. 16

21 Hitachi ID Password Manager Deployment Best Practices 3. Random sample Ask each user to enroll more question/answer pairs than will be used in any given authentication process. Prompt the user to answer only a random sample of those questions at login time. If the user answers incorrectly, prompt the user to answer the same questions again (not a new/random sample after a failed login), as this prevents attackers from "shopping" for questions whose answers they have already worked out. 4. Intruder lockout If a given user fails to sign in several times in a row, lock out his user profile and do not accept further login attempts for a period of time. The number of failed attempts can be higher than might at first seem reasonable say 10 failed logins in 30 minutes. The lockout can be automatically cleared after a while say 20 minutes. The objective is simply to slow down guessing attacks against passwords or security questions. Intruder lockouts should apply to IP addresses as well. If user connections to Password Manager originate at distinct IPs, rather than a load balancer or reverse web proxy, then it s reasonable to lock out addresses that generate many login failures, as those may be used by an attacker. Be sure not to lock out any network infrastructure that aggregates traffic, however Sample questions Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include: Which bank branch do you live closest too? What was the make of your first car? What was the model of your first car? What is your favorite food? Who is your favorite book character? What is your favorite game or sport? What is your favorite movie? What is your favorite pizza topping? What is your favorite season of the year? What is your favorite sports team? In which department in the company did you first work? What was your first position in the company? Who is the person you admire the most? What was the most memorable day in your life? Who was your childhood hero? What is the nickname of your youngest sibling? What is the nickname of your oldest sibling? Who was your first boss? What award are you proudest of? What city were you born in? What is the farthest from home you have traveled? What is the name of the first school you attended? What is the name of the first person you were romantically interested in? What is your astrological sign? What is your father s middle name? 2016 Hitachi ID Systems, Inc. All rights reserved. 17

22 What is your mother s middle name? Who is your favorite actor or actress? What is your favorite musical band? What is your favorite beverage? What is your favorite board game? Who is your favorite book character? Who is your favorite author? What is your favorite dessert? What is your favorite hobby or pastime? What is your favorite ice cream topping? What is your favorite song? What is your favorite television show? What is your favorite vacation spot? What is your mother s maiden name? What is your place of birth? What is your school team s mascot name? What was the breed of your first pet? What was the color of your first automobile? What was the name of your first childhood pet? What was the name of your last childhood pet? What is the name of your first girlfriend/boyfriend? What was the street name of your childhood home? What was your favorite toy when you were a child? What did you do on your first job? What was your first phone number as a child? On what year did you purchase your first car? Who is your favorite politician? Who is your most disliked politician? Who is a famous, living person you would most like to meet? Who was a famous, now deceased person you would have liked to meet? Who is your favorite artist? With whom did you share your first romantic kiss? Who was your favorite elementary school teacher? Sample security questions, that have numeric answers and so are suitable for authentication using a touchtone phone, include: What is your favorite radio station (number on the dial - NNNN)? In what year did you start with your company (CCYY)? On what date were you hired? What is your parents wedding anniversary date (MMDD)? What are the last 4 digits of your SSN or SIN? What are the last 4 digits of your childhood home phone number? What is a birth date of your youngest child (CCYYMMDD)? What is a birth day of your oldest parent (MMDD)? What is a birth day of your youngest parent (MMDD)? On what date were you married (CCYYMMDD)? On what date were you divorced (CCYYMMDD)? What is your employee number? What is your employee number? 2016 Hitachi ID Systems, Inc. All rights reserved. 18

23 What is your date of birth (MM/DD/YYYY)? The last 4 digits of your passport number: The last 4 digits of your driver s license number: 2016 Hitachi ID Systems, Inc. All rights reserved. 19

24 Hitachi ID Password Manager Deployment Best Practices 12 Augmenting security questions with a second factor Security questions can be vulnerable to "social engineering" attacks, where an attacker does background research on a target user and subsequently impersonates that user by answering their security questions. It is therefore desirable to augment security questions with another credential. It is advisable to use the other credential before asking the user to answer security questions, so as not to show a would-be attacker what questions a user has enrolled answers to. Common options for a second factor are: 1. Send a random PIN to the user s mobile phone or personal address. 2. Use a one time password device, such as an RSA SecurID token. 3. Use a smart phone app, such as DuoSecurity. Which factor to use depends on what the user in question has. For example, does the user have an RSA token? Has the user enrolled their mobile phone number? Has the user provided their personal address? 2016 Hitachi ID Systems, Inc. All rights reserved. 20

25 13 Infrastructure integrations A credential management system must first integrate with the systems on which it sets passwords, PINs, certificates, biometrics, etc. This card management systems (smart cards), token authentication servers (OTP validation) and full disk encryption systems. Credential management systems frequently also integrate with other IT infrastructure: System Purpose of the integration When to activate Incident management (ticketing) Full disk encryption system VPN One time password tokens Telephony infrastructure, IVR Mobile device management (smart phones) Invite users to enroll; remind users to change their passwords; notify users of events relating to their profile, such as queued password changes or intruder lockouts. Create, update and/or close tickets to reflect events. Support centralized metrics of IT support activity, including self-service. Raise incidents to resolve technical problems, such as faults reported by connectors. Enable users to unlock their PC if they forgot their pre-boot password. Enable users to reset forgotten, locally cached Windows passwords while off-site. PIN reset, clock synchronization, issuing emergency pass codes. Offer self-service password or PIN reset, filesystem unlock via phone call. Offer self-service via smart phone apps. Initially. Every Hitachi ID Password Manager system should be able to send s. Useful in every deployment, but many defer this beyond the initial deployment. Essential in every organization that has (a) full disk encryption and (b) password authentication pre-boot. Should be deployed early if possible. In organizations where many users work off-site, or even where fewer but high-value people work off-site, providing password reset to these users is essential. This can only be done via deployment of client software and integration with the VPN. Should be deployed early if possible. Enable users who forgot their token at home or forgot their PIN to regain access. Usually deployed in the first phase where required at all. Filesystem unlock and PIN resets for tokens used to sign into the VPN cannot be accessed from a PC browser, because the former is pre-boot and the latter is off-site. Phone call access to self-service can address these problems. Deploy smart phone apps to enable users to manage credentials from BYOD Hitachi ID Systems, Inc. All rights reserved. 21

26 System Purpose of the integration When to activate Smart cards, card management system IAM system HR Proxy system in DMZ or "cloud" PIN reset, emergency pass codes. Requires client-side code to integrate with card readers and integration with the CMS to retrieve card unblock codes. Where users have different login IDs on different systems, any pre-existing mapping data should be leveraged. Accelerate creation of credential management system user profiles (do not wait for auto-discovery to run). Leverage pre-existing security question data. Mediate communication between on-premise systems and BYOD. Enable users who forgot their smart card at home or forgot their PIN to regain access. Usually deployed in the first phase where required at all. The first scenario applies where IDs are inconsistent across systems. The second applies where new users are onboarded and need to use the credential management system immediately. Either an initial bulk load or real-time lookup/validation. Phones and tablets are usually not attached to the corporate network. Allow these BYOD s to connect to a public URL, which authenticates a local app and forwards information to one of a pool of connections accepted from the on-premise credential management system Hitachi ID Systems, Inc. All rights reserved. 22

27 14 Password Manager: technical architecture 14.1 Number and location of servers Most deployments call for two or three Hitachi ID Password Manager servers, preferably at two locations, each with its own local database instance and with the application arranging for real-time data replication between the database instances. User connections are load balanced across the servers. This arrangement has many advantages: 1. No single point of failure. 2. Natural fault tolerance. Loss of a server or even a building only reduces capacity, but does not interrupt service. 3. Excellent scalability. 4. Ability to place Password Manager servers near target systems, to improve performance. Too many servers can create high network traffic for replication. Too few mean inadequate redundancy in the event of a disaster Configuration of individual servers A Hitachi ID Password Manager server is typically configured based on standards set out in the data center where it will be installed. Production Password Manager application servers are normally configured as follows: Hardware requirements or equivalent VM capacity: An Intel Xeon or similar CPU. Multi-core CPUs are supported and leveraged. At least 8GB RAM 16GB or more is typical for a server. At least 500GB disk, preferably configured as RAID for reliability and preferably larger for retention of more historical and log data. More disk is always better, to increase log retention. At least one Gigabit Ethernet NIC. Operating system: Windows 2012R2 Server, with current service packs. The server should not normally be a domain controller and in most deployments is not a domain member. Installed and tested software on the server: TCP/IP networking, with a static IP address and DNS name. IIS web server with an SSL certificate. At least one web browser and PDF viewer Hitachi ID Systems, Inc. All rights reserved. 23

28 A database instance is required to host the Password Manager schema. Microsoft SQL Server 2012 is recommended (Oracle 11gR2 is supported but will be discontinued with the 10.0 release). The SQL Server database software can be deployed on the same server as the Password Manager application, as this reduces hardware cost and allows application administrators full DBA access for troubleshooting and performance tuning purposes. The file-system of the servers may be segmented as follows: Password Manager Server Configuration Drive Size (GB) Contents C: 100 The operating system and downloaded patches. The MSSQL database server software. D: 100 The Password Manager application and any third party software. E: 100 Log files F: 300 or more Database contents (MSSQL) 14.3 Development, test and production environments Three working environments are normally deployed: 1. A development environment, where system administrators implement new versions of Hitachi ID Password Manager, test out configurations, etc. This is where Hitachi ID Systems services staff do most of their work. 2. An integration testing environment, where new versions of Password Manager are validated before being migrated to production. 3. The production environment, which is subject to strict change controls. Separating development from integration testing environments enables Hitachi ID Systems to proceed with developing new features and integrations and with troubleshooting, at the same time that customers tests previously released versions. Separating integration testing from production environments enables customers to apply strict quality and change controls over its production environment, to avoid outages, misconfigurations and ultimately any adverse user or systems impact. These three environments should have the following characteristics: 1. Development (a) May use virtual machines for Password Manager servers. (b) There should be representative instances of each target type, but not necessarily as many of each type as there are in the other environments Hitachi ID Systems, Inc. All rights reserved. 24

29 (c) There should be representative instances of non-target systems with which Password Manager will be integrated (e.g., help desk, , etc.). (d) There should be a small number of users on each target, representing all user types. The number should be kept relatively small in order to expedite testing of code changes. (e) No change control is applied to this environment. (f) Hitachi ID Systems professional services staff should have continuously available remote control access to the Password Manager servers in this environment, to assist in configuring new features and integrations. 2. Integration testing (a) Should be a close mirror of the production environment. (b) May use virtual machines for Password Manager servers. (c) Should have as many Password Manager servers as production, to validate the setup of replication and load balancing. (d) Target systems should mirror production systems, as much as possible, in terms of number and type. (e) Each target system should have a recent snapshot of the user population from its corresponding production target system. (f) Hitachi ID Systems consulting staff may request remote control access to the Password Manager servers in environment, during integration testing. (g) Change control should be used to document changes to this environment. No special schedules or approvals are normally required for changes here. 3. Production (a) Typically two or more load balanced servers. (b) Should be stable and closely monitored. (c) Storage should be reasonably performant, on the assumption that the database server instance runs on the same OS instance as the application. This means SAN or NAS storage when servers are virtualized. (d) Hitachi ID Systems normally requests remote control access to the Password Manager servers in this environment during production migration and subsequently only on an as-needed basis to help customers with any troubleshooting that comes up. (e) Change control should be used to review, approve and schedule changes in this environment, so as to minimize disruption to users and to other production systems Proxy servers for hard-to-reach target systems In some cases, the connection to a target system may be slow, insecure or simply blocked by a firewall. This is often true when the connection is made over a wide area network or requires the use of an insecure protocol but must cross an untrusted network segment. To address such connectivity problems, Hitachi ID Password Manager includes an application proxy server. When a proxy server is deployed, the main Password Manager server ceases to communicate with one or more (usually distant) target systems directly and instead forwards all communication to those systems through one or more proxy servers, which are co-located with the target systems in question. Communication from the main Password Manager server to the proxy server(s) is encrypted, efficient and tolerant of high latency. It uses a single, arbitrarily-numbered TCP port number. Connections are strictly 2016 Hitachi ID Systems, Inc. All rights reserved. 25

30 from the main Password Manager server to the proxy server (never back). A single TCP port supports an arbitrarily large number of target systems at the proxy server s location. These characteristics of the communication between a Password Manager main server and a proxy server mean that firewall administrators will normally be willing and will always be technically able to route or forward a TCP port from the main server IP address to the proxy server IP address. Communication between the proxy server and target systems continues to use native protocols. It is normally physically secured, in a high-bandwidth, low-latency, high-security data center network. Deployment of the secure Password Manager proxy server is illustrated in Figure 1. Hitachi ID Identity and Access Management Suite Firewall Possible Intruder Fast, secure protocol Local Network Firewall Native protocol: Slow? Plaintext? Blocked by firewall? Hitachi ID Proxy Server Target Systems Remote Remote Network Network TCP/IP bit Crypto Various Protocols Figure 1: Target systems connected through a proxy server 2016 Hitachi ID Systems, Inc. All rights reserved. 26

31 15 Password Manager: server hardening 15.1 Overview Hitachi ID Systems makes available detailed instructions for hardening Hitachi ID Password Manager servers. These instructions are available on-line here: Password Manager runs on the Windows server platform, but aside from client libraries for target systems, actually uses very little Windows technology. This makes it possible to disable almost every component of the Windows server OS, significantly reducing the attack surface. Server hardening typically involves the following: 1. Physically securing the Password Manager server. 2. Ensuring that the server has the latest service packs and hot fixes from Microsoft and that new patches are applied automatically. 3. Removing all unneeded login IDs and renaming the Administrator account. 4. Uninstalling every unused service. 5. Minimize the number of system administrators who can sign into the server. 6. Detaching the server from the domain, to block domain administrators from signing in. 7. Enabling inbound packet filtering to only allow defined TCP ports. 8. Removing or disabling any unneeded features of the IIS web server. 9. Locking down filesystem access. 10. Enabling security audit logs, at least of all logins to the server. 11. Port scanning the server to check results. Some of the most effective security measures are common sense: Use a single-purpose server for Password Manager. Sharing this server with other applications introduces more complexity and more administrators, each of which carries its own incremental risk. Use strong passwords for every administrative account on the server. Maintain a current, well-patched operating system on the Password Manager server. This eliminates well-known bugs that have already been addressed by the vendor (Microsoft). Automatically apply patches, especially security patches, to the OS, database server and any third party software Hitachi ID Systems, Inc. All rights reserved. 27

32 Keep the Password Manager server in a physically secure location. Provide security awareness training to all employees. Install, and keep up to date anti-virus software. Do not leave a login session open and unattended on the Password Manager server s console. Attach the Password Manager server to a secure, internal network rather than the public Internet. If access from the Internet is required, mediate it via a reverse web proxy running a different OS an web server platform than Password Manager platform diversity reduces the risk of zero-day exploits. Regularly review Password Manager, OS and network logs. Use the Microsoft Security Compliance Manager to learn more about server hardening Physical security Hitachi ID Password Manager servers should be physically protected, since logical security measures can often be bypassed by an intruder with physical access to the console: Restrict physical access Put Password Manager server(s) in a locked and secured room. Restrict access to authorized personnel only. Password Manager administrators should install and configure the server(s) and then only access it remotely via HTTPS to its web portal or RDP to the OS. Connect a UPS Ensure that server power is protected, that graceful shutdowns occur when power is interrupted and that there is surge protection at least on incoming power connections. Prevent boot from removable media Configure the server to boot from its physical or virtual hard drive and not from USB or optical drives. Where the Password Manager server is virtualized, apply the above controls to the hypervisor Operating system access Install the latest service packs, as these frequently include security patches and updates. Keep up-to-date with the latest Windows security upgrades by subscribing to Microsoft s security bulletin at: One way to limit the number of users who can access the Hitachi ID Password Manager server is to remove it from any Windows domain. If the Password Manager server is not a member of a domain, it reduces the risk of a security intrusion in the domain being leveraged to gain unauthorized access to the Password Manager server Hitachi ID Systems, Inc. All rights reserved. 28

33 Remove unused accounts, leaving just psadmin the Password Manager service account. Create one administrator account to be used by the Password Manager OS administrator to manage the server and set a strong password on this account. Disable the default administrator account. Remove any Guest or unused service accounts. Remove the terminal services user account TsInternetUser. This account is used by the Terminal Service Internet Connector License. For any accounts that must remain, limit their access. At a minimum, block access by members of Everyone to files and folders on the server. If feasible, turn off the remote access and management features on the server to protect the server from remote access attempts using brute force password attacks. This includes the following: Check that "Enable remote management of this server from other computers" is disabled. Turn off "Remote Desktop Administration". If remote administration of the OS is required: Edit the local security policy and remove Administrators from the Allow log on through Remote Desktop Services policy. Add an alternate account with lower privileges to the Remote Desktop Users group. Open ports are an exploitable means of system entry. By limiting the number of open ports, you effectively reduce the number of potential entry points into the server. A server can be port scanned to identify available services. Use packet filtering to block all inbound connections other than the following default ports required by Password Manager: Default TCP port 443/TCP 5555/TCP 2380/TCP 3334/TCP 2340/TCP 4444/TCP Service IIS / HTTPS web service. Password Manager database service default port number (iddb). Password Manager file replication service default port (idfilerep). Password manager service (idpm). Session monitoring package generation service (idsmpg). RSA Authentication Manager Service (psace) - if RSA tokens are managed. On Windows Server 2012, packet filtering is accessed by running the wf.msc control Hitachi ID Systems, Inc. All rights reserved. 29

34 15.4 IIS configuration IIS is more than a web server; it is also an FTP server, indexing server, proxy for database applications, and a server for active content and applications. Disable these features as Hitachi ID Password Manager does not use them. Create two separate NTFS partitions - one for the operating system and one for content IIS serves up. This will protect the OS from IIS compromise. Always deploy a proper, issued-by-a-real-ca SSL certificate to Password Manager servers and disable plaintext HTTP access. Never use a self-signed certificate in a user-facing system, as this may condition users to ignore SSL validity warnings. Assign the IIS user the right to read from but not write to static HTML, image file and Javascript files used by Password Manager. Assign the IIS user the right to execute CGI programs but not other executables on the Password Manager filesystem. Disable directory browsing there is no reason why a user connecting to the Password Manager web portal should be able to list files in any folder SQL Server configuration Don t install anything beyond the core SQL server software. Specifically, leave out or disable: SQL Server Analysis Services (SSAS). SQL Server Integration Services (SSIS). Full-Text Engine. The Filter Daemon Launcher. SQL Server Reporting Services (SSRS). Active Directory Helper. SQL Server VSS Writer service. SQL Server Browser. Hitachi ID Password Manager will connect to the database locally, so network access can and should be disabled. Use SQL Configuration manager to disable all but shared memory access to the database. After installing the SQL Server database software and Password Manager, remove access by the OS Administrators group to the database and change the password for the sa account. Configure a dedicated, local-admin account for use by the The SQL Server Agent service, so that it runs in a different security context than the database itself Hitachi ID Systems, Inc. All rights reserved. 30

35 Password Manager Deployment Best Practices 16 Password Manager: BYOD access to on-premise credential management Since Hitachi ID Password Manager is a sensitive security application, with privileged access to many other systems in an organization and with access to sensitive personal data, most organizations are unwilling to expose Password Manager directly to the public Internet. This creates a problem for mobile device access to self-service, as illustrated in Figure 2. Risky, controversial, likely not allowed Simple, uncontroversial firewall configuration 4G 70% 3:06 PM Mon, 15 June 2015 Type to search... Firewall Personal Device Public Internet Firewall DMZ Private Corporate Network IAM Server Figure 2: Outbound connections are routine, inbound connections are risky and rarely permitted Hitachi ID Systems has developed a solution to this problem, by installing and activating an app natively on ios and Android devices and hosting a proxy server in the cloud. This arrangement is shown in Figure 3. Using this architecture: 1. An app is installed on user devices. 2. Users sign into Password Manager with their PC and ask to activate their device. 3. The PC-based web UI displays an activation QR ode. 4. The user runs the app on their device, which scans this QR code. 5. The QR code includes encryption key material and a URL for a proxy service, in the cloud (i.e., on the public Internet). 6. Users use the app to (indirectly) access the on-premise Password Manager web portal. 7. The app connects to the cloud proxy, requesting content from the on-premise portal. 8. The proxy checks key material provided by the app and may discard connection attempts. In this way, connections from regular browsers or devices which have not been correctly activated for a particular Password Manager instance are easily discarded. 9. Simultaneously, a service on the Password Manager server connects to the proxy server, asking for page requests to fulfill. 10. The proxy passes requests from mobile devices to connections from the Password Manager server Hitachi ID Systems, Inc. All rights reserved. 31

36 Password Manager Deployment Best Practices 11. All connections that cross the corporate perimeter firewall in this architecture are outbound from the Password Manager server to the cloud proxy. 12. All connections are encrypted. HTTPS request: Includes userid, deviceid 4G 70% 3:06 PM Mon, 15 June Type to search... Firewall Personal Device DMZ Public Internet Cloud Proxy 3 Firewall 1 Worker thread: Give me an HTTP request Private Corporate Network IAM Server Messaging passing system: Exchange requests Figure 3: Cloud proxy architecture 2016 Hitachi ID Systems, Inc. All rights reserved. 32