secret server best practices guide - thycotic · pdf filepage 3 i. getting started this...
TRANSCRIPT
Copyright © 2012, Thycotic Software Ltd. Last Updated: August 4, 2014
Secret Server Best Practices
I. Getting Started ............................................................................................................................................... 3
1. Get Installed ................................................................................................................................................................. 3
2. Get Licenses.................................................................................................................................................................. 3
3. Terminology ................................................................................................................................................................. 3
II. What sensitive data or passwords do you want to store? .............................................................. 4
4. Secret Templates........................................................................................................................................................ 5
5. Things to consider ..................................................................................................................................................... 5
a. Password Requirements ................................................................................................................................................ 5
b. Secret Expiration .............................................................................................................................................................. 6
c. Soft Deletes .......................................................................................................................................................................... 6
d. Password History .............................................................................................................................................................. 6
e. Session Launcher .............................................................................................................................................................. 6
f. Override Settings at the Secret .................................................................................................................................. 6
g. Limit Secret Template Administrators ................................................................................................................... 7
h. Use Descriptive Secret Template Names ............................................................................................................... 7
i. Create All Your Secret Templates Before Rollout .............................................................................................. 7
j. Create New Secret Templates Correctly ................................................................................................................ 7
k. Implement Naming Patterns ...................................................................................................................................... 7
l. Deactivate Unused or Retired Templates .............................................................................................................. 7
m. Don’t Forget Your Files .................................................................................................................................................. 7
III. Who will manage these passwords and sensitive data? ................................................................. 8
6. Use Active Directory Integration ......................................................................................................................... 8
7. Use Local Groups and Users .................................................................................................................................. 8
IV. How will you control access to Secrets? ............................................................................................... 8
8. AD Groups or Local Groups? ................................................................................................................................. 9
a. Using Existing AD Groups ............................................................................................................................................. 9
b. Creating New AD Groups .............................................................................................................................................. 9
c. Creating New Local Groups and Using AD Users ............................................................................................... 9
d. Using Local Users and Local Groups ........................................................................................................................ 9
9. Using Folders to Control Access (Inherit Permission) ............................................................................... 9
Page 2
10. Deciding on your Folder Structure ................................................................................................................... 10
V. Controlling Access to Features using Roles ...................................................................................... 11
11. Things to consider ................................................................................................................................................... 11
a. Export ................................................................................................................................................................................. 11
b. Unlimited Administrator Mode ............................................................................................................................... 11
c. Role Definition and Assignment ............................................................................................................................. 12
d. Group Assignment ......................................................................................................................................................... 12
e. Secret Templates ........................................................................................................................................................... 12
f. Event Subscriptions ...................................................................................................................................................... 12
12. Locking Down the Unlimited Administrator Mode ................................................................................... 12
a. How it works .................................................................................................................................................................... 12
b. The Problem ..................................................................................................................................................................... 13
c. The Solution ..................................................................................................................................................................... 13
VI. How do I secure my Secret Server? ..................................................................................................... 14
13. Things to consider ................................................................................................................................................... 14
a. General ............................................................................................................................................................................... 14
b. Database ............................................................................................................................................................................ 14
c. Application Server - Web ........................................................................................................................................... 15
d. Application Server – Operating System and File System ............................................................................ 15
e. Application Settings ..................................................................................................................................................... 16
VII. Further Resources ..................................................................................................................................... 17
VIII. Suggestions? ................................................................................................................................................ 17
Page 3
I. Getting Started
This document was written after helping many customers successfully deploy Secret Server in their
organizations. It covers the issues that most customers tackle as they consider which data to store, who
needs access, what permissions to apply and how to organize all their sensitive data. This document is
not meant to cover everything; please see the Further Resources section if your question is still
unanswered.
Think of Secret Server as a platform for your organization to store all of its passwords and sensitive data.
This means that it can be configured to work in many different ways depending on your industry,
compliance requirements and ultimate end goals. The trick is to decide on your objectives and then
match the capabilities and best practices to your situation.
1. Get Installed
Secret Server is distributed as an MSI (setup.exe) which installs the web application (a zip file option is
also available if needed but not recommended as the setup.exe is much easier). To install Secret Server,
simply run the setup.exe. For more detailed information on setting up the prerequisites (IIS, ASP.NET,
and connecting to Microsoft SQL Server), please see the System Requirements, download the software
and follow the Installation Guide.
2. Get Licenses
Once Secret Server is installed, you will need to install either your purchased or evaluation licenses. If
you need evaluation licenses, request your free evaluation licenses here. Then install them under
Administration | Licenses | Install New License in Secret Server.
3. Terminology
Throughout this user guide, certain terms are used to refer to specific features or concepts within Secret
Server.
Administrator
All the features within Secret Server can be separated out into different Roles. Administrator is
one of the default Roles that comes installed with Secret Server. This Role can be customized to
have different permissions. In this guide, 'Administrator' will be used when referring to the
user(s) who manage the system. Administrators have control over the global security and
configuration settings. Note that Administrators in Secret Server DO NOT automatically have
access to all data stored in the system – access to data is still controlled by explicit permissions
on that data.
Secret
A Secret is any sensitive piece of information (typically a password) that you would like to
manage within Secret Server. Secrets are derived from customizable Secret Templates. Typical
Secrets include, but are not limited to, privileged passwords on routers, servers, applications,
Page 4
and devices. Files can also be stored in Secrets allowing for storage of private key files, SSL
certificates, license keys, network documentation info or even a Microsoft Word or Excel
document.
Secret Template
Used for creating Secrets, Secret Templates allow you to customize and format Secrets to meet
your company's needs and standards. Examples include: Local Administrator Account, SQL
Server Login, Oracle Login, Credit Card and Website Logins. Templates can contain passwords,
user names, notes, uploaded files, and drop-down list values. Templates can be customized and
new Secret Templates can also be created.
Role-based Security
Secret Server uses Role Based Access Control (RBAC). All features in Secret Server map to
permissions which can then be assigned to Roles. Users and groups can then be given one or
more Roles. Role Based Security provides Administrators the ability to set strict, granular
permissions for each user.
Unlimited Administration Mode
This is the emergency ("break-the-glass") feature. When this mode is enabled, Administrators
are able to access all content within the system regardless of explicit permissions. Access to the
Unlimited Administration Mode is controlled using Roles.
Remote Password Changing
Secret Server can automatically change passwords on remote devices and various platforms
including: Windows Accounts, various database logins, Active Directory accounts,
UNIX/Linux/Mac accounts (including root passwords), network appliances/devices and more.
II. What sensitive data or passwords do you want to store?
Do a quick brainstorming session and try to think of all the types of sensitive data that need to be
securely stored and managed. Where are the pain points for your teams?
Here are some guidelines to get you started:
Think of all privileged passwords:
o These are passwords that don’t identify an individual (for example: Administrator, root,
enable, shared accounts, service accounts, etc.).
o These should all be randomized passwords and should be changed frequently.
Every password in your organization should be the different.
Any password that could be needed should an employee quit or be fired.
Any password that could be needed in an emergency or outside of regular business hours or
when someone is on vacation.
Page 5
Typical passwords and sensitive data being stored in Secret Server:
Windows local Administrator passwords.
UNIX, Linux, Mac root and local user passwords.
Active Directory service account passwords.
Database passwords (MS SQL, Oracle, MySQL, etc.).
Network equipment passwords (router, switches, firewalls, phones, appliances, etc.).
Application passwords (SAP, custom apps, etc.).
Website passwords (cloud services, DNS, Amazon AWS, vendor passwords).
Sensitive files (private key files, SSL certificates, network documentation info, etc.).
Software license keys, serial numbers, personnel data, Wi-Fi passwords.
4. Secret Templates
Secret Templates in Secret Server define the types of data (“Secrets”) that can be stored. Review the
available templates by going to Administration | Secret Templates. You can decide which Secret
Templates should be available to your users and you can customize the existing templates (rename
fields, change fields, add fields). You can also create new Secret Templates to match your types of data
if needed. You can basically store *any* type of sensitive data in Secret Server.
Secret Templates are the way that you control which data can be stored in your Secret Server and the
settings for that data.
5. Things to consider
a. Password Requirements
Password Requirements determine the password compliance rules (for example, 16 characters, 1 upper,
1 lower, 1 symbol and 1 number). Password requirements can be customized and then applied to
passwords at the Secret Template level. This will control the complexity of the passwords generated by
Secret Server and can be enforced by the system and also can be viewed for password compliance in
reports. This also allows you to have different complexity rules for different types of passwords if
needed (Oracle, SQL, Windows, UNIX, etc.). Also, choose to have Secret Server enforce the Password
Requirements on add/edit by turning on validation on the Secret Template.
Talk to your security management, auditors and industry experts – find out the best password
complexity settings for your environment. Don’t be afraid to dial up the settings (e.g., 100 character
random generated passwords with symbols, alphanumeric and upper/lower) – using a platform like
Secret Server makes it easy to work with passwords so length won’t matter (launchers, copy to
clipboard, autochange). In fact very large passwords can add to security since Administrators will be far
less likely to remember them or write them down or want to type them.
Another thing to consider when creating Password Requirements is the Character Sets to use. Some
systems may not work well with certain characters; for example, underscores can be problematic in
Page 6
certain mainframe environments. You can create your own Character Sets (Administration | Secret
Templates | Character Sets) for use in Password Requirements. These can then be used when passwords
are generated by Secret Server.
b. Secret Expiration
Secret Server uses Secret Expiration to ensure that passwords are changed on a regular basis. Secrets
can be set to expire on an interval such as 30 days (or other intervals as needed). Expiration means that
the password should be changed. Passwords can either be automatically changed by Secret Server (this
will change the password on the account across the network if configured to do so) or can be manually
updated by an Administrator on expiration.
You can also control which field is used for expiration (it doesn’t have to be the password). You could
use expiration on a license key and set expiration to when the license is going to expire. When a Secret
expires, you can then update the expiration field (say license key) and it will no longer be expired. This is
a generic way to ensure that a specific field on a Secret is changed on a regular basis.
c. Soft Deletes
Secret Server uses soft deletes rather than hard deletes (data is marked as inactive rather than actually
deleted). This is essential for auditing since data cannot just be removed from the system causing all
audit activity to be lost. Secrets and Secret Templates can be inactivated but not deleted. This is
something to bear in mind when configuring your Secret Server.
d. Password History
Secret Server will automatically keep all history on all fields on a Secret Template. This means that all
previous values for machine, username, password and any other fields will be kept. This is helpful in
ensuring that previous passwords can be found if needed.
e. Session Launcher
The Launcher can be configured on the Secret Template to allow any tool to be launched using the
Secret such as Remote Desktop, PuTTY, web launcher or a custom launcher you configure for a
particular .exe; for example, MS SQL Management Studio, SSH clients, FTP tools and more. This can also
be used with the “Hide Launcher Password” (Secret | Security tab) to allow Administrators to launch
tools without revealing the password.
f. Override Settings at the Secret
Many of the settings at the Secret Template can also be overridden at the Secret; for example, if you
create a Secret for your AD service accounts with a 30-day expiration but need 90 days for one particular
AD service account, you can set it to 90 days for that one Secret. This gives some flexibility for Secrets
that need to behave differently than other Secrets using the same Secret Template.
Page 7
g. Limit Secret Template Administrators
Changing Secret Templates should be limited to only a small subset of the Admins. Create a separate
role that has the Administer Secret Templates role permission and remove it from Administrator if you
have a lot of Administrators. Once you have Secret Templates configured, it is unlikely they will need to
be changed frequently so very few people should need access.
h. Use Descriptive Secret Template Names
Make sure your Secret Template names are descriptive and use terms your users will understand. For
instance, if you have one template that expires and one that does not, make sure it is clear from the
name. If your organization does not use the term Active Directory Account, change it to match the
organization’s language.
i. Create All Your Secret Templates Before Rollout
It is worth spending time in the beginning to get your Secret Templates the way you want them before
users start adding data. When an Administrator goes to create a new Secret, it will be clear which Secret
Template to use and not try to fit the Secret into another template because the right Secret Template
does not exist yet. You can use Secret Convert later to change a Secret from one to another but it is a
lot easier to just plan ahead before your Administrators start adding data.
j. Create New Secret Templates Correctly
When creating new Secret Templates, make sure you wire up Remote Password Changing, Password
Requirements, Secret Expiration and the Session Launcher.
k. Implement Naming Patterns
Secret Server supports Naming Patterns for Secret Templates. Naming patterns allow you to maintain
consistency for Secret names and can help ease both browsing and grouping Secrets by name. Naming
Patterns use Regular Expression and allow you to enter a descriptive error message. Use this error
message to describe your naming standard to your Administrators. The most common naming standard
used is RESOURCE\ACCOUNT (for example, server0001\administrator).
l. Deactivate Unused or Retired Templates
Secret Server comes with many Secret Templates preconfigured. You should decide which you want to
use and then deactivate the others. You can also retire Secret Templates if your requirements change
over time – Secrets will remain when a Secret Template is deactivated but no one will be able to create
new Secrets for that Secret Template.
m. Don’t Forget Your Files
Don't forget files. You can have fields on your Secret Template that are for file attachments. This can be
used for storing license key files, private keys, SSL certificates, even Microsoft Word or Excel documents
that contain sensitive data.
Page 8
III. Who will manage these passwords and sensitive data?
Now that you know which data you will be managing in Secret Server, the next step is to decide who will
use Secret Server to manage that data. Start by thinking about which privileged passwords need the
most attention first – maybe Windows local Administrator passwords, service accounts, UNIX root
passwords, network equipment passwords or others? The Administrators who manage those passwords
and need access to them on a regular basis will need to access your Secret Server.
There are few different options for configuring access to Secret Server for your Administrators:
6. Use Active Directory Integration
Use Active Directory Integration to allow use of AD accounts to access Secret Server:
a) These accounts can be created manually (one by one) by adding an AD Domain to Secret Server
and then adding users to that Domain within Secret Server (see Adding an AD Domain, and
Creating an AD User).
OR
b) These accounts can be synchronized with one or more AD groups with Secret Server so that
users in those groups automatically have access to Secret Server. This can be done by adding a
Domain to Secret Server, then choosing which AD groups to synchronize (see Adding an AD
Domain, and Choosing AD Synchronize Groups).
7. Use Local Groups and Users
Use local users and groups within Secret Server. These users and groups have to be created and
managed manually (not integrated with Active Directory) but it provides the most security since users,
groups and group membership can be controlled entirely through Role Based Access Control (RBAC)
within Secret Server.
IV. How will you control access to Secrets?
You have different sets of passwords that should only be viewed by particular Administrators. You may
also have certain passwords that should be read-only to some Administrators, editable by others and
not even visible to other Administrators. All of these options are possible to configure using the
permissions within Secret Server.
Permissions can be allocated at the individual user level but it tends to be easier to manage over time if
you allocate your permissions at the group level. You will need to decide if your existing AD groups
could work for these permissions or if you need to create new AD groups or if you want to create and
manage local groups in Secret Server.
Page 9
8. AD Groups or Local Groups?
a. Using Existing AD Groups
Review your teams that need access and the corresponding groups in your Active Directory. If your AD
groups map to ways you want to separate out access to Secrets and levels of access (View / Edit /
Owner) then you can synchronize your AD groups into Secret Server. Go to Active Directory |
Synchronize Groups. By using your existing AD groups, you can effectively manage access to Secret
Server and to the Secrets stored within Secret Server completely from AD by changing AD group
membership. Many customers choose this option as they maintain control in AD and don’t have to
worry about any user or group maintenance within Secret Server.
Note This option is easy for user maintenance but it does limit the security of your Secret Server to the
level of security of your Active Directory. This may be fine but be sure to consider the question.
b. Creating New AD Groups
If your AD groups don’t really match the way you want to break out your access to Secrets, then you will
need to create new AD groups to match the permission levels needed.
c. Creating New Local Groups and Using AD Users
Another option is to grant access to AD users in Secret Server by creating their accounts manually or by
synchronizing one or more AD groups BUT then create local groups in Secret Server to match the levels
of access needed. The AD users can then be added to the local groups and all access is controlled in
Secret Server. This approach requires more maintenance since group membership has to be controlled
in Secret Server but it does provide the benefit that users are still managed in AD and they can use their
AD credentials to authenticate to Secret Server. Many customers who use this approach simply create a
single AD group (for example, “SecretServerUsers”) and then synchronize that group in Secret Server.
Note This hybrid approach is more secure than using AD groups and AD users but an adversary could
still reset an AD account password to gain access to your Secret Server. However this is more likely to
be noticed by the user whose password is reset but only after the fact.
d. Using Local Users and Local Groups
Creating local users and groups within Secret Server provides a lot of flexibility since you can tailor the
groups and access to your exact needs but it also requires more maintenance than the other options.
9. Using Folders to Control Access (Inherit Permission)
You can apply permissions (View / Edit / Owner) at the Secret level. This allows you to apply very
granular permissions on a single Secret if needed. Managing permissions on each Secret is powerful for
situations where you need that flexibility but it tends to be harder to manage over hundreds or
thousands of Secrets. Instead, you should consider using Folders to control permissions for most
Secrets. This can be done by creating a folder structure that best represents your organization, teams or
Page 10
data being stored; then apply permissions (View / Edit / Owner) on the folders, using inheritance across
folders where appropriate. Secrets placed in a folder can then inherit the permissions of the folder.
10. Deciding on your Folder Structure
The folder structure creates a hierarchy for organization and permissions. This means that folders near
the root level need to break out access in high level terms and then get more specific permissions
(typically breaking inheritance) as you move down to the “leaf level” sub-folders.
For example:
Information Technology
o Technical Services
Systems
Windows
UNIX
Network Infrastructure
Database
Oracle
SQL Server
o Development Services
Programmers
Vendors
Human Resources
Customers
The most typical configuration is to break out the folders based on the teams that need to use those
folders with the most restrictive permissions at the outer most “leaf” folders of the tree.
An Oracle DBA might have the following permissions on the above folders:
Information Technology (VIEW)
o Technical Services (VIEW)
Database (VIEW)
Oracle (VIEW / EDIT / OWNER)
SQL Server (VIEW / EDIT)
Note A user will not be able to see the full folder structure unless they have View permissions on all the
parent folders of a particular folder. For example, a user with View on the “Oracle” folder, would also
need View on “Database”, “Technical Services” and “Information Technology” to be able to see the full
folder path.
Page 11
There are settings in Administration | Configuration to control whether inheritance on Folders and
Secrets should be turned on and also whether users should always see all folders. There are many ways
to configure this for your organization.
The most common approach is:
Use inheritance.
Don’t allow users to see folders unless they explicitly have View permissions.
Require all Secrets to have a Folder.
This allows different teams or even different departments within your organization to use the same
Secret Server instance independently.
V. Controlling Access to Features using Roles Secret Server Administrators do not automatically have access to all data stored in your Secret Server.
Secrets are only visible based on the explicit permissions assigned. This ensures that the data is safe and
cannot be easily viewed by the Administrators. However, there are still features within Secret Server
that need to be controlled and even monitored for use or abuse.
Access to features within Secret Server can be controlled using the Role Based Access Control (RBAC).
Features in Secret Server have corresponding Role Permissions which can be assigned to different Roles.
Roles can be customized and new Roles can be created as needed.
Secret Server comes with three (3) Roles by default: Administrator, User and Read Only. You should
review these roles and also decide if your organization needs further Roles for third party consultants or
auditors or if you need to break out the Administrator Role into several Roles.
11. Things to consider
a. Export
Exporting Secrets from your Secret Server as cleartext is very helpful for meeting regulations in certain
industries (Secrets can then be printed to paper and locked in a physical safe). It can also be used as
another Disaster Recovery option but access to exporting data from the Secret Server should be tightly
controlled. You could create a separate Role with just that permission for anyone needing to perform
exports.
b. Unlimited Administrator Mode
Unlimited Administrator Mode allows anyone with the Unlimited Administrator Role Permission to see
all Secrets in the Secret Server. This mode is very helpful for recovering passwords in emergencies or
when staff are terminated. You can tightly control access to this feature by splitting out the Role
Permissions for Administer Unlimited Administrator and Unlimited Administrator into two different
Roles. This allows you to create the “two key effect” for access to use this feature.
Page 12
c. Role Definition and Assignment
Once you have defined your Roles, they will seldom need to be changed. Access to modify and assign
roles should be tightly controlled.
d. Group Assignment
If Roles are assigned to groups then assignment of the groups also needs to be controlled. Often very
sensitive Role Permissions are assigned at the user level to limit the risk of granting group assignment
permissions.
e. Secret Templates
As mentioned in the section on Secret Templates, you should control access to modifying your Secret
Templates. Anyone with this access can change the definitions of the data being stored and this access
should be tightly controlled. Once again, your Secret Templates are unlikely to need changing once you
have defined them so limiting access to a select number of individuals should be fine.
f. Event Subscriptions
Another option when protecting roles is to configure Event Subscriptions to notify appropriate staff in
the event that Roles are changed or assigned. Event Subscriptions are email alerts that can be sent to
users, groups or specific email addresses, based on different events in Secret Server. There are also
events available around Unlimited Administrator to further protect its use.
12. Locking Down the Unlimited Administrator Mode
The Unlimited Administrator role permissions are all assigned to the Administrator Role when you first
install Secret Server. This works for teams where a single highly trusted individual (or a few) will control
all the Administrative functions of Secret Server (for example, single IT team or MSP).
For larger enterprise environments where more control is needed or there are compliance
requirements, you will need to split out the Administrator role. Customers often struggle with how to
adequately lock down the Unlimited Administrator feature because there are lots of loopholes such as
manipulating roles, role assignment and even group assignment that could allow a malicious
Administrator to get access to Unlimited Administrator.
a. How it works
Unlimited Administrator is a Role Permission that can be assigned to a Role (an existing Role or you
could create a new Role if needed). Users and groups can then be assigned to this Role. Anyone who
has this Role either by direct assignment to their user account or through their group membership can
then see all Secrets in Secret Server when Unlimited Administrator Mode is turned on (it is turned off by
default but can be turned on by going to Administration | Configuration | Unlimited Administrator
Mode).
Page 13
There is another Role Permission named Configure Unlimited Administrator which allows access to turn
the Unlimited Administrator Mode on or off. This can be separately assigned to a Role and given to
other users. Separating the Unlimited Administrator and Configure Unlimited Administrator Role
Permissions makes it possible to split the ability to use Unlimited Administrator to more than one
person for dual verification.
b. The Problem
Although these role permissions make it easy to separate and control access to Unlimited Administrator,
there are loopholes since an Administrator who can change Role definitions or who can assign roles
could just assign both role permissions to their own user account.
c. The Solution
The solution is to find all the ways through which an Administrator could manipulate Unlimited
Administrator Mode and lock them down accordingly.
Here are the recommended guidelines:
1) Split out the Unlimited Administrator and Administer Configuration Unlimited Admin Role
Permissions into two separate Roles and assign them to the appropriate trusted individuals who
will need to collaborate to use Unlimited Administrator Mode. Add the View Configuration
permission to the role containing Administer Configuration Unlimited Admin permission (to
allow for the user to access the setting from the Configuration page). Assign at the user level,
not at the group level, so that group management does not come into scope). These individuals
do not have to be regular users of Secret Server but will need to be available in emergencies
should Unlimited Administrator be needed.
2) Review the “User” role and adjust or customize as needed. This should be the default Role for
new users and should be assigned to the Everyone group.
3) Create another role (something like “Role Administrator”) and put all the role permissions that
effect roles into that Role.
a. Administer Role Assignment
b. Administer Roles
4) Make sure that your “Administrator” Role no longer has the above role permissions or the
Unlimited Administrator role permissions.
5) “Role Administrator” should only be assigned to a very limited number of trusted individuals
(ISO, Executive, or Senior Manager). The Role should be assigned directly to their user accounts,
not to a group; otherwise, group management comes into the scope of this problem). This Role
should very seldom be used since it is only needed to change role assignments or change role
definitions.
6) Create a new Event Subscription (under Administration | Event Subscriptions) to notify via email
the appropriate people when suspicious things happen and target the following events:
a. Role > Assign User or Group
b. Role > Create
Page 14
c. Role > Unassign User or Group
d. Role Permission > Add To Role
e. Role Permission > Removed From Role
f. Unlimited Administrator > Enable
g. Unlimited Administrator > Disable
h. Configuration > Edit (this is recommended since changing mail server settings could
prevent emails from being sent)
Other events to consider:
i. Secret > View (for any very sensitive Secrets)
j. User > Login Failure (in case someone is trying to brute force the password of another
User)
VI. How do I secure my Secret Server?
Security is a process, not a product, so it is critical to build a secure process around your Secret Server
implementation. This needs to include a layered approach to security (defense in depth) starting at the
operating system, software updates, access to physical systems, protocols, system settings, backups and
personnel procedures.
13. Things to consider
a. General
i) Keep Windows up-to-date
Microsoft regularly releases security patches that resolve vulnerabilities in Windows operating systems.
We recommend keeping your server up to date.
ii) Backup At Least Daily
Consider your Disaster Recovery plan. Review Business Continuity and Disaster Recovery Planning (KB
article) for more information.
iii) Review System Log for Errors
It is important to periodically check the System Log for any recurring errors. After an upgrade, check for
any errors in the System Log (Administration | System Log).
b. Database
i) Limit access to your Secret Server database
When you create your Secret Server database, you should limit access to as few users as possible. We
recommend you disable the “sa” account in the SQL instance that contains Secret Server.
Page 15
ii) Limit access to other databases
When you create a database account for use by Secret Server, you should ensure it only has access to
the Secret Server database. Also consider limiting access to sensitive system databases such as master –
refer to Restricting Access to Master Database in SQL Server (Microsoft Support KB) for details.
iii) Use Windows Authentication for database access
Windows Authentication is much more secure than SQL authentication. For a detailed explanation of
why this is true, please refer to Choose an Authentication Mode (TechNet article).
To use Windows Authentication in Secret Server, you will need to create a service account. For details
on how to do this, please refer to Using Windows Authentication to access SQL Server (KB article).
iv) Limit access to your database backups
Database backups are critical for disaster recovery, but they also carry a risk if someone gains access.
The Secret Server database is encrypted but you should still limit access to ensure you are following
“defense in depth”. Make sure to limit access to database backups to as few individuals as possible.
v) Don't store the database on a SQL instance that contains less sensitive databases
Putting the database on a server with other less secure database instances can open up vulnerabilities.
For example, an attacker could potentially use SQL injection on another application to access your
private Secret Server database.
c. Application Server - Web
i) Use SSL / HTTPS
Secure Sockets Layer (SSL) is required to ensure that all communication between the web browser and
Secret Server is encrypted and secure (and not cleartext travelling across your network). We
recommend you install a third-party certificate, domain certificate, or self-signed certificate on your
Website. For information on creating and installing a self-signed certificate, please see Installing a Self-
Signed SSL/HTTPS Certificate (KB article).
ii) Force SSL / HTTPS
Even after you install an SSL certificate, users may still be able to access Secret Server through HTTP. To
prevent access via HTTP, enable the Force HTTPS/SSL option in Secret Server (Administration |
Configuration).
d. Application Server – Operating System and File System
i) Limit access to your Secret Server directory
It is very important to limit access to your Secret Server directory. This contains the Secret Server
encryption key as well as the database connection information. (These values are encrypted but
remember “defense in depth”. Try to grant access to as few users as possible.)
Page 16
ii) Limit logon rights to the Application Server
Administrators accessing the Application Server directly could attempt to monitor memory in use on the
server. Secret Server does several things to protect application memory but the best safeguard is to
limit access to the Application Server to as few users as possible.
iii) Protect your encryption key
Use DPAPI to encrypt your encryption.config file. Go to Administration | Configuration | Security tab |
Encrypt Key Using DPAPI. This will use machine specific encryption to encrypt the file - make sure you
backup the original file before turning on this option.
The encryption key for secret server is contained in the encryption.config file, which resides in your
Secret Server directory. This file is obfuscated and encrypted, but defense in depth would require
limiting access to the file. To further protect the file, you can enable EFS encryption. EFS (Encrypting File
System) is a Microsoft technology that allows a user or service account to encrypt files with login
passwords. For more details, please read Protecting Your Encryption Key Using EFS (KB article).
Note When setting up clustering, it will be necessary to copy a version of your encryption.config file
that is NOT encrypted to the additional server. Once Secret Server is up and running on that server, you
can then DPAPI-encrypt the encryption.config file by logging into Secret Server locally and turning on
DPAPI.
e. Application Settings
i) Review the Security Hardening Report
Go to Reports | Security Hardening Report in Secret Server. Review each setting and get as many to
“green” as feasible for your environment. These recommendations will help to secure your Secret
Server at the application settings level.
ii) Use DoubleLock for your most sensitive Secrets
DoubleLock is a feature in Secret Server that allows Secrets to be protected with additional AES256 bit
encryption keys. Each Administrator gets their own public/private key when using DoubleLock. Their
private key is protected by an additional password (user specific--not a shared password) that each
Administrator must enter when using DoubleLock. DoubleLock protects from situations where you
accidentally assign someone to the wrong AD group or an attacker gains full access to both your
database and web server - they still will not be able to access DoubleLocked secrets. For more
information, refer to Using DoubleLock (KB article).
iii) Use Two Factor Authentication
In the event that a password gets compromised, you can protect yourself by enabling two factor
authentication (TFA). Secret Server currently supports two forms of two-factor authentication. First, you
can use your email address as an extra form of identification. Second, you can use a RADIUS compliant
device (such as an RSA or CryptoCard token), as an extra form of authentication. For more details, please
refer to the following KB articles:
Page 17
How does Two Factor Authentication work?
Enabling RADIUS Two-Factor Authentication
iv) Secure the Local Admin Account
When you create the first user in Secret Server, it will be a privileged Admin account that you can use
when your domain is down. We recommend that you choose a non-obvious name for this account and
protect it with a very strong password. This password should be stored in a physical safe with limited
access (there is no need to use this account except in emergencies where other accounts are not
working if AD is down or some other reason).
v) Review Activity Reports
It is a good practice to regularly review the activity and permissions reports. This can help find anomalies
in Secret permissions and login failures.
vi) Use Event Subscriptions to notify of any security anomalies
Event Subscriptions can be used to send email alerts on various events in the system. This could be used
to notify Administrators if there are failed login attempts or if certain Secrets are viewed, etc.
VII. Further Resources
Please review these resources for more information:
Secret Server User Guide
Secret Server Installation Guide
Secret Server Knowledge Base
Secret Server Video Tutorials
Secret Server Customer Forums
Thycotic Blog
VIII. Suggestions?
Please let us know if you are still unable to find the answer to a question after reviewing this document
and the resources listed above. Please send an email to [email protected] with your suggestions.