Privileged Password

Security Policy Template

Policy # Effective Date Email
############ DD/MM/YYYY [email protected]

Version Contact Phone

1.0 Policy Contact 888.641.5000

About this Template

This sample security policy can be used as a starting point template for a privileged
account management policy for your organization. Privileged accounts present a much
greater risk than typical user accounts and thus require a higher level of control. The
policy is divided into several sections according to the common governance areas
regarding privileged accounts. It contains over 40 pre-written information security
statements. Organizations can remove policy statements that do not apply or fit the
organization’s governance requirements.

This template is structured using the “Best Practices Security Policy

Template” from Information Shield. The template has been used by well
over 1000 organizations.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

Table of Contents

Policy Information and About this Template

Customizing the Template ...................................................................................................... 2
Disclaimer .............................................................................................................................. 2
Support................................................................................................................................... 2
1.0 Purpose ................................................................................................ 3
2.0 Scope ................................................................................................... 3
3.0 Policy .................................................................................................... 3
3.1 SYSTEM APPROVAL AND AUTHORIZATION ................................................................ 3
3.2 Password Categorization .................................................................................................. 3
3.3 Password Composition ..................................................................................................... 4
3.4 Password History and Change Interval ............................................................................. 5
3.5 Account Lockout and Compromised Passwords ............................................................... 6
3.6 Acceptable Use Privileged Accounts ................................................................................ 6
3.7 Privileged Account Approval ............................................................................................. 7
3.8 Privileged Account Construction ....................................................................................... 7
3.9 Privileged Account Management ...................................................................................... 8
3.10 Third Party Privileged Accounts ...................................................................................... 9
3.11 Application Development ................................................................................................ 9
3.12 Privileged Account Logging ............................................................................................ 9
4.0 Violations ............................................................................................ 10
5.0 Definitions ........................................................................................... 10
6.0 References ......................................................................................... 11
7.0 Approval and Ownership ..................................................................... 12
8.0 Revision History .................................................................................. 12
9.0 Appendix – Secret Server Policy Enforcement .................................... 13
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

Customizing the Template

To customize this template perform the following steps:

1. Download the template

2. Open the template as a Microsoft Word document
3. Remove the “About this Template” and “Customizing the Template” instructions and other
author comments
4. Replace the term “Company X” with the name of your organization
5. Replace the current logo or add your company logo in the upper left corner
6. Update all of the company-specific contact information (highlighted in yellow)
7. Update the effective date
8. Revise any policy guideline to meet your organization’s policies
9. Revise the Violations section to meet your organization’s policies
10. Save your changes
11. Obtain your management and auditors’ approval of the completed Policy
12. Distribute Policy according to your management guidance

Disclaimer

This document is a template only and should be revised to meet the information security
guidelines of your organization. Organizations should not adopt any security policy without
proper review and approval by senior management, information security, and legal.

Support

Support for the Privileged Password Security Policy Template is available in our Free Tools
forum at http://my.thycotic.com/forums/topics.aspx?ForumID=4
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

1.0 Purpose
This policy defines the requirements for establishing and maintaining account settings for all
privileged user accounts on any Company X computer and communications system.

2.0 Scope
This policy applies to all information security analysts and system administrators responsible for
the maintenance of accounts and password management systems on Company X electronic
information resources.

3.0 Policy
3.1 SYSTEM APPROVAL AND AUTHORIZATION

(Default accounts and passwords present one of the greatest risks to production systems.
This section defines specific controls for controlling and managing privileged accounts
when systems are placed into production. These controls may also be part of a policy
regarding System Configuration Management.)

3.1.1 Default Password Changes - All vendor-supplied default passwords must be

changed before any computer or communications system is used for Company X business.

3.1.2 Privileged User ID Review - Before any production multi-user computer operating
system is installed at Company X, all privileged user IDs that are not assigned to a specific
employee or job role must have their passwords changed to large random values and these
should be recorded in the privileged account management system with appropriate
permissions for the administrators responsible for managing these accounts.
3.1.3 Unnecessary Software - Software features that could be used to compromise
security, and that are clearly unnecessary in the Company X computing environment, must
be disabled at the time when software is installed on multi-user systems.

3.2 Password Categorization

(This section defines specific terminology for understanding different categories of

passwords which is then helpful for prescribing controls on those passwords. Treating all
passwords the same is not effective.)

Passwords fall into two categories:

User Account Passwords – First, a password is a secret that allows the use of an account. An
account may represent a human being and therefore that password determines a human
identity, for example, an Active Directory user account. The Active Directory user account
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

password is the secret known by the human that identifies that human to the system. These
types of passwords are known as user account passwords and they need to be memorized by
the human whose identity they represent. A goal is to strive for as few user account passwords
per human user as possible, ideally a single user account password per human user. .

Privileged Account Passwords – Privileged account passwords are passwords where the
account does not represent a human being – this could be a system account like UNIX root or a
service account. The passwords on these accounts do not typically provide for any identity of a
human and therefore do not need to be memorized. These passwords can be set to very large
values and stored in the privileged account management system.

The focus of this Privileged Password Security Policy document is on the second type of
password, Privileged Account Passwords. However, because User Account passwords often
have elevated or administrative privileges attached to them, both types of passwords are
described in many of the guidelines in this policy.

3.3 Password Composition

(This section defines specific controls for creating secure passwords for privileged
accounts. Passwords for privileged accounts must generally be more secure than for
regular user accounts.)

3.3.1 Role-Based Password Length - The minimum length for fixed passwords, or
passwords created by users, must be set to six for handheld computers, eight for all
network-connected computers, and ten for administrator and other privileged user IDs.
3.3.2 User Account Password Complexity - All user-chosen passwords for user accounts
must meet the following complexity requirements:
 Must contain at least one alphabetic, one numeric and one symbol character.
 Must be at least 8 characters in length.
 Ideally passphrases should be used to increase length. Increased length provides
more security than complexity and is easier for a human to memorize.
For example:
1) lf@j7asFd! versus 2) Blue5Chandelier2@
The seven extra characters in (2) make it 64 trillion times stronger than (1).

3.3.3 Privileged Account Password Complexity – These passwords should be optimized

for security since no human needs to memorize these passwords. They can be optimized
for the maximum lengths of the platform. For example: Recent versions of Windows allow
for up to 127 characters for the password – therefore random passwords should be
generated between 80 and 127 characters in length to provide the maximum security.
The following requirements should be followed for Privileged passwords:
 Should maximize the possible length of password for each platform.
 Should not be memorized.
 Passphrases should not be used since memorization is not desirable.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

 Should have a complete mix of upper case, lower case, numbers, and symbols.
3.3.4 Seed for Generated Passwords for Privileged Accounts - If system-generated
passwords are used, they must be generated using the low order bits of system clock time
or some other very-frequently-changing and unpredictable source.
3.3.5 Null Passwords Always Prohibited - At no time, may any Systems Administrator or
Security Administrator enable any user ID that permits password length to be zero (a null or
blank password).
3.3.6 Enforce Password Complexity - All passwords must meet the above complexity
requirements and this complexity must always be checked automatically at the time that the
password is created or changed.

3.4 Password History and Change Interval

(This section defines specific controls for changing passwords for privileged accounts.
Passwords for privileged accounts must generally be more secure than passwords for
regular user accounts.)

3.4.1 User Account Password Changes – Users must be required to change their
password at least once every 90 days. It is better to have good passwords that can be
memorized than frequent changes of these passwords. More frequent changes will lead to
more forgotten passwords or weaker passwords being chosen with little security benefit.
3.4.2 User Account Maximum Password Changes – Users must not be permitted to
change their password within 7 days of their previous change. This requirement is only
helpful for passwords that users are memorizing (user accounts)and is used to prevent
users from changing the password multiple times back to a previously used password
(therefore defeating the requirement to change the password).
3.4.3 Privileged Account Password Changes – All privileged accounts must be
automatically required to change their passwords at least once every 90 days. This time
interval should be set based on an internal risk assessment for any potential disruption to
the business. For example: A service account password change can be highly disruptive if
it is part of a mission critical system and therefore this password change could be once
every 90 days. However a Domain Admin account password change would have zero
disruption to the business and is very high risk – these accounts should have their
passwords changed as often as possible – ideally after every use to reduce exposure to
abuse, misuse or exploits such as Pass the Hash attacks.
3.4.4 Password History - On all multi-user Company X computers, system software or
security software must be used to maintain an encrypted history of previously chosen fixed
passwords. This history must contain at least the previous thirteen passwords for each user
ID.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

3.5 Account Lockout and Compromised Passwords

(Privileged accounts must be protected against brute-force password guessing

techniques just as user accounts are protected. The specific parameters of password
attempts and lockout direction should be customized based on the organization’s specific
requirements.)

3.5.1 Maximum Login Attempts - All Company X computer systems that employ fixed
passwords at log on must be configured to permit only five attempts to enter a correct
password, after which the user ID is deactivated.
3.5.2 Lockout Duration – All accounts that have been disabled for incorrect logon attempts
must remain inactive for at least 15 minutes.
3.5.3 Lockout Notification – All disabling of accounts for incorrect logon attempts must be
notified to the security team so that investigation can occur if necessary and anomalies can
be detected.
3.5.4 Password Changes After Privileged User Credential Compromise - If a privileged
user credential has been compromised by an intruder or another type of unauthorized user,
all passwords on that system and any related systems must be immediately changed.
3.5.5 Fixed Password Change Confirmation – System administrators must be
immediately notified when fixed passwords are changed or updated outside of the central
privileged account management system.

3.6 Acceptable Use Privileged Accounts

(Sharing passwords between systems creates great risk. A single compromised system
can allow an attacker to quickly move laterally across the network. This section contains
controls to limit password sharing across systems.)

3.6.1 User Account Password Sharing – User Account Passwords must never be shared
or revealed to anyone other than the authorized user. If they are shared then they are no
longer a User Account since the identity of the user is not known.
3.6.2 Privileged Account Password Sharing - Passwords for privileged accounts can be
shared among administrators as long as controls are in place to know which administrator is
using the account at any one time. This must include full auditing and non-repudiation
mechanisms. Each system must have a unique password.
3.6.3 Password Display And Printing - The display and printing of account passwords
must be masked, suppressed, or otherwise obscured so that unauthorized parties will not be
able to observe or subsequently recover them. Any display of a privileged account
password to a user must be audited and the password should be changed after it has been
used.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

3.7 Privileged Account Approval

(Because of the added risk of compromise, privileged accounts must be strictly

controlled. The following sections contain controls for the approval, creation and
maintenance of accounts. )

3.7.1 Privileged Account Requirements – All privileged accounts on Company X systems

must employ greater security than non-privileged accounts. This includes longer, more
secure passwords and greater audit accountability.
3.7.2 Privileged User Account Approval – The creation or modification of privileged user
accounts must be approved by at least two individuals: The System Owner and an
authorized member of the Information Technology department. System administrators must
not be allowed to create other privileged accounts without authorization.
3.7.3 Number of Privileged User IDs - The number of privileged user IDs must be strictly
limited to those individuals who absolutely must have such privileges for authorized
business purposes.
3.7.4 Role Based Account Privileges – To facilitate secure management of systems,
wherever possible, privileged accounts must be defined based on the specific role of the
system administrator.

3.8 Privileged Account Construction

(One way to reduce confusion and gain oversight is to adopt standards for privileged
accounts that are created by the organization. For proper separation of duties,
administrators must use separate accounts for their day-to-day user activities.)

3.8.1 Privileged User ID Construction- All privileged user IDs on Company X computers
and networks must be constructed according to the Company X user ID construction
standard, and must conform to one of the following:
 Must clearly indicate the responsible individual’s name.
 Must clearly define the purpose of the account (i.e. purpose of the account, type
of account, etc.
 Must be managed in a system which can clearly associate a single User Account
to each use of the Privileged Account in order to document accountability for the
use of the Privileged ID
3.8.2 Generic User IDs - User IDs must uniquely identify specific individuals and generic
user IDs based on job function, organizational title or role, descriptive of a project, or
anonymous, must be avoided wherever possible. User IDs for service accounts and other
application accounts should also follow the Company X naming convention and
requirements outlined in section 3.8.1 above.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

3.8.3 Re-Use Of User IDs - Each Company X computer and communication system user ID
must be unique, connected solely with the user to whom it was assigned, and must not be
reassigned after a worker or customer terminates their relationship with Company X.
3.8.4 Separate Systems Administrator User IDs - System administrators managing
computer systems with more than one user must have at least two user IDs, one that
provides privileged access and is logged, and the other that provides the privileges of a
normal user for day-to-day work.

3.9 Privileged Account Management

(The variety of privileged account types across various systems presents unique
management challenges. Modern software applications provide ways to automate
account discovery, management and removal. These systems should be used whenever
possible to reduce risk and increase visibility.)

3.9.1 Central Automated Management – All privileged accounts on Company X systems

must be managed by a central system. This system must provide an audit trial that tracks
specific additions, changes, and deletions.
3.9.2 Integration with Native Directories – Any privileged account management system
must integrate with native operating system account management systems or directory
services (such as Active Directory)
3.9.3 Integration with Strong Authentication Methods – Any privileged account
management system must integrate with strong authentication methods (such as multi-factor
authentication) to ensure the identity of the user in addition to their directory authentication.
3.9.4 Password Vault – Company X system administrators must have access to a vault
system that enables the temporary provisioning of access to privileged accounts and
passwords (aka FireID) for emergency maintenance.
3.9.5 Password Vault Encryption – Company X must maintain any credentials stored in a
central management system within an encrypted password vault, using strong encryption
algorithms that meet compliance and/or regulatory requirements.
3.9.6 Privileged Account Inventory – Company X must maintain an inventory of all
accounts with privileged access on production information systems. These include, at a
minimum, local administrator accounts and service accounts.
3.9.7 Account Inventory Update – The privileged account inventory must be updated at
least quarterly to identify new or changed accounts.
3.9.8 Inactive Account Maintenance - All inactive accounts over 90 days old must be
either removed or disabled.
3.9.9 Disaster Recovery – Any privileged account management system must be configured
to utilize robust backup, recovery and availability methodologies in order to ensure resiliency
and availability of the credentials stored within the system as well as the timely recovery of
the system in the event of a system failure.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

3.10 Third Party Privileged Accounts

Third Party User ID Expiration - Every privileged user ID established for a non-employee
or third party application must have a specified expiration date, with a default expiration of
30 days when the actual expiration date is unknown.

3.11 Application Development

(Most applications that require privileged accounts to operate present unique challenges.
In many cases these accounts are not disclosed, or use default accounts with fixed
passwords. Privileged account security can be greatly enhanced using secure application
design and coding principles.

3.11.1 Special Application Accounts – All production applications that require privileged
access must use special application accounts that are created specifically for the given
application. Applications must never use default administrator accounts.
3.11.2 Secret IDs or Passwords - Developers must not build or deploy secret user IDs or
passwords that have special privileges, and that are not clearly described in the generally
available system documentation.
3.11.3 Hard-Coded Passwords In Software - Passwords must never be hard-coded in
software developed by or modified by Company X workers.
3.11.4 Test Account Removal - Test data and accounts used during development and
testing must be removed before a production system becomes active.

3.12 Privileged Account Logging

(To provide audit visibility into privileged accounts, systems must be designed and
configured to log events linked to privileged accounts.)

3.12.1 Privileged System Commands Traceability - All privileged commands issued on

computer and communication systems must be traceable to specific individuals through the
use of comprehensive logs.
3.12.2 Privileged User ID Activity Logging - All user ID creation, deletion, and privilege
change activity performed by Systems Administrators and others with privileged user IDs
must be securely logged.
3.12.3 Privileged User ID Activity Log Review - All logs recording privileged ID activity
must be reviewed at least quarterly via periodic management reports.
3.12.4 Privileged User ID Activity Log Correlation – All logs recording privileged ID
activity must be aggregated into a central log management or Security Information and
Event Management (SIEM) tool in order to correlate privileged ID activity to other security
events, log entries and related non-privileged ID activity.
3.12.5 Privileged User ID Session Logging – In addition to event logging, all activity on
privileged accounts must be logged via session or keystroke recording.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

4.0 Violations
Any violation of this policy may result in disciplinary action, up to and including termination of
employment. Company X reserves the right to notify the appropriate law enforcement
authorities of any unlawful activity and to cooperate in any investigation of such activity.
Company X does not consider conduct in violation of this policy to be within an employee’s or
partner’s course and scope of employment, or in the direct consequence of the discharge of the
employee’s or partner’s duties. Accordingly, to the extent permitted by law, Company X
reserves the right not to defend or pay any damages awarded against employees or partners
that result from violation of this policy.

5.0 Definitions
Account (User ID or Username) - A unique string of characters assigned to a user by which a
person is identified to a computer system or network. A user commonly must enter both a user
ID and a password as an authentication mechanism during the logon process.
Fixed Password – A password created by a user for an account or credential.
Least Privilege - Least privilege means that for each task or process, the administrator is granted
the minimum rights required to perform the task.
Password – An arbitrary string of characters that is used to authenticate an account when
attempting to log on, in order to prevent unauthorized access to the account.
Privileged Account – An account that can either be a user account on any system that has
system privileges beyond those of a normal user or an account that does not represent a human
use. Privileged accounts are typically not assigned to a user, but can, in some cases, be dedicated
user accounts which are given more permissions than a typical user account. Root, local
administrator, domain admin and enable passwords are all examples of privileged accounts that
have elevated access beyond that of a normal user. Passwords for privileged accounts should be
randomized, not memorized by anyone, and changed frequently.
System Administrator – An employee or partner who is responsible for managing a Company
X multi-user computing environment. The responsibilities of the system administrator typically
include installing and configuring system hardware and software, establishing and managing user
accounts, upgrading software and backup and recovery tasks.
Third Party – Any non-employee of Company X who is contractually bound to provide some form
of service to Company X.
User - Any Company X employee or partner who has been authorized to access any Company
X electronic information resource.
User Account – An account that represents a single human user. They are the only person to
ever use the account and it is their way of authenticating into Company X systems. The password
for this account is something they would memorize and would not be shared with any other user.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

6.0 References
(This section contains references to the information security laws and governance
frameworks applicable to this Privileged Password Security Policy.)

Policy and Regulation Section Mapping (for reference only)

NIST 800-66
Thycotic Policy PCI DSS v3
Section HIPAA Security HIPAA Section ISO 17799/27001
Description Section
Rule

User Account 11.2.2, 11.3.1,

3.3.2 8.2.3 164.308(a)(5)(ii)(D)
Password Complexity 12.1.1

Privileged Account
3.3.3 8.2 11.3.1
Password Complexity

User Account 11.2.2, 11.3.1,

3.4.1 8.2.4 164.308(a)(5)(ii)(D)
Password Changes 12.1.1

Privileged Account 11.2.2, 11.3.1,

3.4.3 8.2.4 164.308(a)(5)(ii)(D)
Password Changes 12.1.1

11.2.2, 11.3.1,
3.4.4 Password History 8.2.5 164.308(a)(5)(ii)(D)
12.1.1

Maximum Login 11.2.2, 11.3.1,

3.5.1 8.1.6 164.308(a)(5)(ii)(D)
Attempts 12.1.1

11.2.2, 11.3.1,
3.5.2 Lockout Duration 8.1.7 164.312(a)(1)
12.1.1

Privileged Account
3.7.2 4.14.6 164.312(a)(4) 11.2.4, 12.5.1
Approval

Role-Based Account
3.7.4 7.1.2, 7.1.3 11.2.2
Privileges

Privileged Account
3.8 4.14.3 164.312(a)(4) 11.5.2
Construction

Central Automated
3.9.1 8.5 4.14.5 164.312(a)(4) 11.5.3
Management

Integration with Strong

3.9.3 Authentication 8.3 & 8.2.2 11.5.1
Methods

Password Vault
3.9.5 8.2.1 11.5.3
Encryption

Privileged Account
3.9.6 4.16.1 164.312(c)(1) 8.3.3, 11.2.4
Inventory

Inactive Account
3.9.8 8.1.4 8.3.3
Maintenance

Privileged User ID 4.15.1, 4.14.2,

3.12.2 8.1.2 164.312(b) 11.5.2
Activity Logging 4.14.4
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

7.0 Approval and Ownership

Owner Title Date Signature

Policy Contact Title MM/DD/YYY
Approved By Title Date Signature
Executive Sponsor Title MM/DD/YYYY

8.0 Revision History

Revision Review Reviewer/Approver

Version Description
Date Date Name

1.0 Initial Version 10/25/15

COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

9.0 Appendix – Secret Server Policy Enforcement

This Appendix is optional and should be deleted before you distribute this security policy to your
organization. This Appendix is a table listing the Policy statements in this document that are
enforceable using Thycotic’s Secret Server solution. Having a written Privileged Password
Policy using this template is a great first step, but now you need to enforce this policy—making
sure passwords are vaulted, encrypted, changed, and monitored, all according to this
policy. Thycotic Secret Server automatically discovers, vaults, and manages privileged
passwords, ensuring your compliance with your written policy guidelines. Details on this
enforcement are in the table below.

Guideline Secret Server Enforcement of this

Policy Guideline
# Guideline
Secret Server can be configured through its
All vendor-supplied default passwords must Discovery capabilities to find new systems on
3.1.1 be changed before any computer or the network and automatically secure their
communications system is used. passwords and store them in the vault with
access for the appropriate admins.
Before any production multi-user computer
operating system is installed, all privileged
user IDs that are not assigned to a specific Secret Server offers Discovery capabilities
employee or job role must have their with configurable rules for how to find
passwords changed to large random values systems, accounts, how to securely
3.1.2 randomize their passwords and also who to
and these should be recorded in the
privileged account management system grant access to the secure credentials in the
with appropriate permissions for the Secret Server vault. The entire process is
administrators responsible for managing customizable and automated.
these accounts.

Secret Server provides the secure vault to

Passwords fall into two categories: store all privileged account passwords as well
 User Account Passwords as user accounts with elevated or
3.2
 Privileged Account Passwords administrative privileges. They need to be
large, random and frequently changed –
Secret Server automates this process.
The minimum length for fixed passwords Secret Server uses templates and Password
must be set to six for voice mail boxes and Requirements to set the rules for length and
3.3.1 handheld computers, twelve for all network- complexity on passwords. This makes it easy
connected computers, and longer for to ensure that all passwords have sufficient
administrator and other privileged user IDs complexity and this is automated.
Secret Server has policies, templates and
The following requirements should be
password requirements which allows you to
followed for privileged account passwords:
easily maximize the length and complexity of
3.3.3  Should maximize the possible privileged account passwords. Secret Server
length of password for each can easily generate, enforce and rotate
platform. passwords that are 100 random characters or
more for these accounts. This makes it
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

 Should not be memorized. impractical to memorize or write down. The

use of these passwords is still simple for
 Passphrases should not be administrators using the Secret Server tool.
used since memorization is not
desirable.
Should have a complete mix of upper case,
lower case, numbers and symbols

If system-generated passwords are used, Secret Server uses secure random numbers
they must be generated using the low order to generate large random passwords. The
3.3.4 bits of system clock time or some other libraries used are approved by Microsoft to
very-frequently-changing and unpredictable produce cryptographically secure random
source. numbers.

Secret Server can find weak passwords using

3.3.5 Null Passwords Always Prohibited. the Discovery capability. These passwords
can then be automatically changed by Secret
Server to ensure policy requirements are met.

All passwords must meet the above Secret Server will enforce policy and
complexity requirements and this password requirements on new passwords as
3.3.6 complexity must always be checked they are created and on existing accounts.
automatically at the time that the password Customizable alerts and reporting ensure that
is created or changed all passwords meet your requirements and
can be proven to an auditor.
Secret Server offers an expiration policy
capability that can be enforced as part of your
All privileged accounts must be policy. This ensures that all privileged
3.4.3 automatically required to change their account passwords are changed on a
passwords at least once every 90 days. configurable schedule. Calendar specifics
can also be set – for example: Only change
this password on Sundays at 2am once the
90 day threshold has been met.
On all multi-user computers, system
software or security software must be used
Secret Server automatically tracks history on
to maintain an encrypted history of
all passwords keeping a full log of previous
3.4.4 previously chosen fixed passwords. This
passwords. This is helpful when restoring a
history must contain at least the previous
system from backup and an earlier password
ten passwords for each user ID.
is needed.

If a privileged user ID has been

compromised by an intruder or another type Secret Server provides mechanisms to easily
3.5.4 of unauthorized user, all passwords on that identify vulnerable passwords and
system and any related systems must be automatically change thousands of
immediately changed. passwords in minutes.

System administrators must be immediately Secret Server provides the Heartbeat

notified when fixed passwords are changed capability to constantly test and validate
3.5.5 passwords kept in the vault. If an
or updated outside of the central privileged
account management system. administrator or an intruder changes a
password outside of the vault or creates a
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

backdoor account on a system, then alerts

can be generated to the administrator team or
Security Office.

Passwords for privileged accounts can be Secret Server provides full auditing on all use
shared among administrators as long as of passwords from the vault. If a password is
controls are in place to know which given to an administrator then the CheckOut
3.6.2 capability should be used to ensure that the
administrator is using the account at any
one time. This must include full auditing password is changed when the admins are
and non-repudiation mechanisms finished using it. This ensures there is full
accountability on the usage of all accounts.

The display and printing of account Secret Server provides controls to allow the
passwords must be masked, suppressed, authorized use of a password without
or otherwise obscured so that unauthorized revealing the password itself. This protects
parties will not be able to observe or the password from disclosure while still
3.6.3 auditing its use. If the password has to be
subsequently recover them. Any display of
a privileged account password to a user provided to the administrator (for example, for
must be audited and the password should legacy systems) then Secret Server provides
be changed after it has been used. the CheckOut capability to ensure that the
password is changed after it is used.
All privileged accounts on Company Secret Server takes security on privileged
systems must employ greater security than account passwords to the maximum while
3.7.1 non-privileged accounts. This includes preserving convenience for the administrators
longer, more secure passwords and greater – ensuring long random passwords, auditing
audit accountability. their usage and controlling access.

The creation or modification of privileged

user accounts must be approved by at least Secret Server provides workflow capabilities
two individuals: The System Owner and a with dual approval for sensitive accounts.
3.7.2 member of the Information Technology Backdoor accounts can also be detected,
department. System administrators must secured and the Security Office can be
not be allowed to create other privileged notified to ensure that administrators never
accounts without authorization. create unauthorized accounts.

The number of privileged user IDs must be Granular permissions within Secret Server
strictly limited to those individuals who allow access to be limited to specific
3.7.3 individuals and groups allowing teams to
absolutely must have such privileges for
authorized business purposes. follow the security best practice of “least
privilege” with ease.
Secret Server allows specific access to
To facilitate secure management of privileged accounts, and access can be easily
systems, wherever possible, privileged provisioned to administrators based on their
3.7.4
accounts must be defined based on the membership in Active Directory groups. This
specific role of the system administrator. allows privileged access to be granted only
for certain functions based on role.
User IDs must uniquely identify specific
In the cases where generic user IDs can’t be
individuals, and generic user IDs based on
avoided then Secret Server can be used to
3.8.2 job function, organizational title or role,
manage access using these accounts to
descriptive of a project, or anonymous,
ensure they are both secure and users
must be avoided wherever possible. User
remain accountable.
IDs for service accounts and other
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

application accounts should also follow the

Company naming convention.

Secret Server can be used to effectively

manage named privileged accounts (a
System administrators managing computer common example are Active Directory
systems with more than one user must Domain Admin accounts – these can be
have at least two user IDs, one that vaulted ensuring passwords are very strong,
3.8.4 changed frequently and Pass the Hash
provides privileged access and is logged,
and the other that provides the privileges of attacks are mitigated). While these accounts
a normal user for day-to-day work. are assigned to a user, the high levels of
access and privileges they are given require
that they are governed as privileged accounts
for purpose of this policy.
All privileged accounts on Company Secret Server tracks all usage of privileged
systems must be managed by a central accounts being managed. There is extensive
3.9.1 system. This system must provide an audit auditing of all changes and usage which can
trial that tracks specific additions, changes be configured to provide alerts, daily reports
and deletions. or ad-hoc reporting for auditors.

Any privileged account management Secret Server integrates with Active Directory
system must integrate with native operating for authentication, granular permissions (role
3.9.2
system account management systems based access control) and automation for
(such as Active Directory) password changing.

Any privileged account management

system must integrate with strong Various multi-factor technologies can be used
authentication (such as multi-factor with Secret Server including RSA SecurID,
3.9.3 Duo Security, Google Authenticator (TOTP)
authentication) to ensure the identity of the
user in addition to their directory and any technology that is RADIUS
authentication. compatible (this covers most vendors).

Secret Server provides Unlimited

Company system administrators must have Administrator Mode which can be used in
access to a vault system which enables the emergency situations to gain access to
generation of temporary privileged accounts restricted credentials. All actions are notified
3.9.4 and passwords (aka FireID) for emergency to appropriate groups and everything is fully
maintenance. audited. This ensures that an organization is
prepared for any catastrophe from a
password perspective and includes the ability
for dual control to activate the firecall mode.
Secret Server provides Discovery capabilities
Company must maintain an inventory of all to find new accounts on the network and
accounts with privileged access on automatically track those accounts against
3.9.6 production information systems. These those in the vault. Accounts can also be
include, at a minimum, local administrator automatically imported into the vault using
accounts and service accounts. configurable discovery rules. This ensures
that the vault automates the process of
inventory and reconciliation of accounts.
The privileged account inventory must be Secret Server provides an updated inventory
3.9.7 updated at least quarterly to identify new or of accounts on an ongoing basis through its
changed accounts. automated discovery which is continually
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

reviewing the environment for changes.

There is no need for human intervention or
manual work.
Secret Server provides extensive APIs to
allow configuration of rules such as this.
All inactive accounts over 90 days old must However the risk is much lower with managed
3.9.8
be either removed or disabled. privileged accounts since Secret Server is
setting strong passwords, controlling access
and rotating passwords on a regular basis.
Any privileged account management Secret Server supports load-balanced front
system must be configured to utilize robust end application server configurations and
backup, recovery and availability back-end database clustering to ensure the
methodologies in order to ensure resiliency highest levels of resiliency and system
3.9.9
and availability of the credentials stored uptime. Secret Server also supports all
within the system as well as the timely standard backup and recovery methods for
recovery of the system in the event of a database backups and application recovery
system failure. on standard platforms.

Every privileged user ID established for a Secret Server provides workflow approval for
non-employee or third party application temporary access. The access is approved by
3.10 must have a specified expiration date, with an appropriate manager and the non-
a default expiration of 30 days when the employee / third party application can then
actual expiration date is unknown. use the credentials for the approved period of
time such as 30 days.
Application account credentials can be stored
All production applications that require in Secret Server and then retrieved through
privileged access must use special either a push or pull mechanism with various
application accounts that are created API options. This allows these credentials to
3.11.1 be controlled, access to be audited, and also
specifically for the given application.
Applications must never use default allows these credentials to be rotated on a
administrator accounts. regular basis. Allowing Secret Server to
manage these credentials ensures that they
are strong and meet policy requirements.

Developers must not build or deploy secret Secret Server provides easy APIs that
user IDs or passwords that have special developers can use to remove credentials
3.11.2 privileges, and that are not clearly from their applications and pull them from the
described in the generally available system vault programmatically at runtime. This
documentation. allows the credentials to be secured, audited
and rotated frequently by Secret Server.
Secret Server provides easy APIs that
Passwords must never be hard-coded in developers can use to remove credentials
3.11.3 software developed by or modified by from their applications and pull them from the
Company workers. vault programmatically at runtime. This
allows the credentials to be secured, audited
and rotated frequently by Secret Server.
Test data and accounts used during
development and testing must be removed Secret Server can find test accounts using the
3.11.4 Discovery capability and these accounts will
before a production system becomes
active. then be secured.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

Using the SSH proxy/jump host, Secret

Server intercepts all commands to the target
All privileged commands issued on system and records them in the audit trail for
computer and communication systems must the session for that user. These sessions can
3.12.1
be traceable to specific individuals through then be searched by users of Secret Server
the use of comprehensive logs. with the correct role permissions. This
ensures that users are accountable for their
activity.

All user ID creation, deletion, and privilege Secret Server can control access to all
change activity performed by Systems privileged accounts and can monitor activity
3.12.2
Administrators and others with privileged through alerts, SIEM integration and even
user IDs must be securely logged. video recording of sensitive account usage.

All logs recording privileged ID activity must This can be done in Secret Server through
3.12.3 be reviewed at least quarterly via periodic scheduled reports to be sent each quarter
management reports. and reviewed by the appropriate people.

All logs recording privileged ID activity must

be aggregated into a central log Secret Server supports native integration with
management or Security Information and several SIEM tools and can also output log
3.12.4 Event Management (SIEM) tool in order to files in standard CEF or Syslog formats for
correlate privileged ID activity to other easy integration into most any log
security events, log entries and related non- management or SIEM tool.
privileged ID activity.

In addition to event logging, all activity on Secret Server provides event logging (to a
3.12.5 privileged accounts must be logged via SIEM tool) and can also capture session
session and keystroke recording. activity through recording and keystroke
logging.
COMPANY X | PRIVILEGED PASSWORD SECURITY POLICY

About Thycotic

Thycotic, a global leader in next-generation IT security solutions, delivers an

indispensable, comprehensive Privileged Account Management (PAM) solution to
protect your "keys to the kingdom" from cyber-attacks and insider threats. Unlike any
other security offering, Thycotic Secret Server assures the protection of privileged
accounts while being the fastest to deploy, easiest to use, scalable enterprise-class
solution offered at a competitive price. Already securing privileged account
access for more than 3,000 organizations worldwide, including Fortune 500
enterprises, Thycotic Secret Server is simply your best value for PAM protection. For
more information, please visit www.thycotic.com.

About Information Shield

Information Shield provides time-saving products and services to help build, update and
maintain information security policies. Information Shield’s Common Policy Library
(CPL) contains over 1600 pre-written information security policy templates covering all
aspects of information security. Based in Houston, Texas, Information Shield has over
10,000 satisfied customers in 60 countries. For more policy templates, visit
http://www.informationshield.com, email sales(at)informationshield(dot)com or call
1.888.641.0500.