1. Privileged Access Management
A Key Element of Good Security
Steve Pulley, Information Security Officer
June, 2018

2. Today’s Agenda
Introduction to
Fitch Ratings and myself
Our IAM estate
Our use of Privileged Access Management
Tips for success involving
Good habits to develop
Privileged Access Management
Identity Management
Access Management
Resilience and controls
Taking your questions
My goal for this discussion is to give you an understanding of how we use Privileged Access Management in my organization and some practical advice which you can use to be successful.

3. First piece of advice - Do what it says on my whiteboard.

4. About Fitch Ratings and myself
Overview
Fitch Ratings is a leading provider of credit ratings, commentary and research
Fitch publishes credit ratings on thousands of companies, public institutions, and transactions
Fitch Ratings is a part of Fitch Group, a leading provider of essential financial information and services to the global financial markets
Key Stats
Fitch Group has approx 4,000 staff members spread across its four divisions
The largest, Fitch Ratings, has more than 2,500 users
Fitch has offices in over 30 countries around the world, and is dual-headquartered in London and New York
Trivia
Fitch Ratings is over 100 years old, having celebrated its centennial in 2014
Fitch invented the widely used “AAA” letter scale used for ratings by many firms
About me
Fitch’s Global Information Security Officer. Previously Infrastructure Manager for EMEA and APAC
I’m British so I apologize in advance if I use any British expressions or idioms that make no sense

5. Our IAM Estate
We use products from Hitachi ID Systems to manage our estate
Hitachi ID Password Manager (PM)
Hitachi ID Identity Manager (IDM)
Hitachi ID Privileged Access Manager (PAM)
Synchronizes user passwords across the estate
Enforces password strength requirements
Enables self-service and assisted secure reset via challenge questions
Enforces enrollment in challenge questions for new hires
About to roll out mobile password management for remote password change
Manages identity, accounts, and entitlements across approximately fifty systems, including:
Active Directory
Exchange
Oracle
SAP
~30 bespoke systems
Approx 4,000 users across the Fitch Group companies
Over 10,000 individual entitlements
Auto-provisioning and deprovisioning of access based upon HRIS system changes.
Roles auto-assigned to users based upon HRIS attributes
Enforces over 100 segregation of duty restrictions
Privileged users may “check out” administrative accounts (server or domain admin accounts, local workstation accounts etc) or escalate entitlements for specific app/apps
Access to the administrative account or the escalated entitlements are automatically revoked after preset time period
Bespoke applications may request access to limited lifetime DB passwords via a PAM API programmatically
PAM also manages password rotation of Windows service accounts
Service account use is discovered across hosts and passwords are periodically changed
Focus of today’s discussion

6. PAM IDM PM That being said…
Don’t think PAM, think Identity and Access Management as a whole
Many benefits to greater levels of integration:
Simplification of discovery
Automation of onboarding & offboarding humans, service accounts and systems
Ability to leverage RBAC policies and SOD rules across systems
Operational benefits (fewer servers, cross training etc)
PAM PM
IDM

7. Our use of PAM for privileged users…
A privileged user logs into UI and requests access
Manager approves based upon system policy
PAM begins countdown of when to change the password or revoke access
User “checks out” access
X number of minutes, hours or days later PAM randomizes the password or automatically revokes access
User loses access to system
Some systems are more elevated than others. Not all requests require manager approval.
Manager
step 3
step 2
PAM
User
step 1
step 5
step 4
step 6 – access removed

8. Advice for privileged user use…
Enforce controls around who can request privileged access
Use RBAC policies or access management controls to determine who can access your privileged access management platform and what they can request access to once inside
Not all privileged systems are the same
Not all requests may require the same level of approval
Identify your crown jewels Declaration of Independence and protect it accordingly
Be aggressive with maximum check out window
Start low…depending on the system: minutes rather than hours, hours rather than days
Be flexible if necessary
Certain circumstances may warrant a policy exception
Factor that possibility into your policies if necessary
Consider consolidating authentication across targets
It may benefit you to aggregate certain systems into one set or collection of privileged access
Eg. access to SOX systems or servers for system Y
Bias for escalation rather than admin account
Steer towards temporary privilege escalation where possible rather than secondary administrative accounts
If you need admin accounts then integrate deactivation with standard offboarding procedures

9. Our use of PAM for bespoke applications and tasks…
User uses an app or a scheduled task initiates
App or task successfully logins to DB using its assigned credentials. Then at some point this happens:
Password lifetime expires so PAM randomizes account password in DB
App or task login to DB fails
App or task is coded to request new password using PAM libraries
PAM utility libraries request new password from PAM server via API
PAM server returns updated password
PAM utilities updates local cache and returns password to app or task
Return to step 2
System
Bespoke Fitch Application or scheduled task
step 2 successful logins
Database
step 4 login fails
step 8
step 1
step 3
step 5
step 8
step 7
Server running PAM utilities
step 6
PAM

10. Advice for application and task use…
Build relations with the right teams
Ensure your developers are very familiar with the libraries available and are using them correctly
Ensure system admins and Operations staff are familiar with troubleshooting methods
Ensure DBAs are familiar with process required to onboard new API targets and discover accounts
Include credential security requirements in SDLC
Include credential management as a part of the system design discussion for all internal apps
Ensure QA incorporate suitable tests to validate not only standard operation but also DR scenarios
Follow good change practices for PAM itself
Have a development environment for PAM, test changes
Changes to policy settings can have unexpected consequences
Encrypt any stored passwords
Even though they are disposable, it’s just good practice
Incorporate it as part of your development practices
Develop good naming conventions
Develop a good naming convention for DB application accounts and API accounts
This will make troubleshooting easier

11. Build a resilient PAM infrastructure and monitor it
User access
Application access
Ensure users and apps use load balanced URLs. In the event of DR you’ll be grateful
Don’t forget about the credentials used by PAM
Lock them down so that only PAM can use
Store them in the server vault
Replicate the vault to another location
Introduce regular controls to check password change frequency and replication success
PAM
PAM
Replicate vault between locations
Data center 1
Data center 2

12. General tips for a successful PAM implementation
Eat the privileged elephant one bite at a time
Think carefully about where to begin your oversized meal
Establish what your drivers are and prioritize around those
Engage project management resources and establish success criteria before starting
Socialize the effort
People may not know what’s expected of them: tell them.
Change is scary for some: positive messaging overcomes this.
Be inclusive and hear feedback…but be true to the cause
Establish your PAM evangelists
PAM can affect a lot of areas so build out a network of evangelists
Identify interested personnel in each group and create your working team
Turn objections into wins
People will have objections to what’s changing or what they are losing
Redirect these objections by talking benefits.
Train, Train, Train Test, Test, Test
This may be a new concept for many: plan and offer training for everyone involved.
Train the trainer and lunch and learns are effective
Have a development (pre prod) environment and encourage the use of it often. As mentioned incorporate credential management into the SDLC
Memorialize important information
Don’t rely on oral mythology: write stuff down.
Have an agreed upon set of written rules and procedures.
Particularly around account creation and onboarding
Always have a backup plan
Things won’t always go as planned.
Know how you will manually correct ahead of time – roll back plan
Test in your dev/QA environment
Make sure your DR plan is solid and tested regularly.

13. Questions
Thank you