SAFE DESIGN
Basic Safe Concepts
! Access to passwords are controlled through Safe
Authorizations
! Only Users that are authorized for a specific Safe (i.e.
Safe Members) can access safe data
! If a User has “retrieve permissions” in a Safe, all objects
inside the can be accessed by this user
Defining a Safe Model
How should Password Objects be split and stored in
several safes in order to implement a custom
authorization and access model that fits for an
organization?
! Generally, there is no common, generic “Safe Model” that
fits for all Cyber-Ark implementations!
! Defining a Safe Model is an individual, implementation
specific process during implementation planning.
Questions to answer in defining safe model
! Who needs access to which data stored in the
Vault?
! Internal (e.g. Employees) or External Users (e.g. Partners, Contractors, etc.)
! What is the security level of data stored in the Vault?
! Secret, Informational, etc.
! Who must not see a specific type of data?
! Is there any type of data that needs to be especially protected in front of others?
! Should additional access limitations apply to
(specific) objects?
! Dual Control, Exclusive access
! …
! Write down the relevant questions and corresponding answers in natural language
first!
Example Criteria for Deriving a Safe Model
! Organizational Structure of the Enterprise
! e.g. Each Organization Unit has a set of dedicated safes, like OPS team Web
Servers or Database team, etc.
! Functional Structure
! e.g. group Passwords of a certain platform type in a safe, like Windows, Linux,
Oracle, etc.
! e.g. group types of passwords like all passwords of local administrator accounts
of Windows Workstations on place them in one safe
! Geographic Structure of the Enterprise
! e.g. Group Data in Safes based on the geographic locations of the users access
this data
! Security Level or Classification of Data
! e.g. group Passwords in Safes based on Security Classification
! Some other, individual criteria for separating password
objects
! A Combination of several aspects and criteria mentioned
above
! Note: These are examples! Start understanding the local requirements and
business processes first!
Theory of Sets
! Start defining sets of entities, e.g. like:
! Sets of Users (Groups) that need access to Data
! Sets of Password Objects that need to be managed
! Define access restrictions that should apply
! e.g. “Only Windows Administrators must see passwords of Windows
Systems”
! Apply defined restrictions to Sets of Passwords by
building subsets resulting in a new set presentation
! Map Groups and Access requirements to the
password objects sets by identifying intersections
! Each “Mapping” will result in a dedicated safe
Using Theory of Sets
! Ok, we really need a few very basic ideas of the
Theory of Sets for this purpose, but …
! Using Set of Objects and Entities will be help
you to draw a picture of the situation.
! Using this picture will help to identify the number
and the structure of Safes easily.
Example Requirements
! “EPV will be used by Windows, Unix and Oracle
Teams”.
! “EPV will store password of Windows Systems,
Unix Servers and Oracle Database Users (built-
in and shared passwords).”
! “Password objects of a specific platform should
be used by team members only.”
! “Unix Admins need to authenticate to PVWA
using RSA SecurID!”
! “Windows Team has a second team of external
Administrators that takes care of Windows
Workstations only.”
Sample Requirement Continued
! “Workstation Admins must not have access to
Server passwords, but Server Admins have to
have access to Workstation passwords.”
! “Passwords of Domain Administrator Users must
only be accessible after confirmation by IT
Managers!”
! “Oracle Administrators need Access to Servers
(Windows and Unix) hosting Oracle Databases.”
A Sample Solution Approach
! Define sets that need Access, i.e. identify Users
and Groups of Users that need to be handled:
! Windows Server Admins
! Windows Workstation Admins
! Unix Administrators
! Oracle Administrators
! IT Managers
! Split set of all password objects in 3 major sub
sets:
! Windows,
! Unix
! Oracle
! Start splitting Passwords Sets and start defining
sub sets to meet requirements now!
Define user groups and sets of passwords
Windows Server
Admins Windows
Passwords
IT Managers
Oracle
Windows Passwords
Workstation
Admins
Unix
Passwords
Oracle Admins
à A Minimum of 3 Safes is required (“Password objects of a
specific platform must be used by team members only.”)
Unix Admins
Drilling down the safe model
1. Basic Safe Model will need at least 3 Safes!
! “Password objects of a specific platform must be used by
team members only .”
2. Split Windows Passwords into Server and
Workstations Sets
! “Workstation Admins must not have access to Server
passwords, but Server Admins have to have access to
Workstation passwords” à Reflected by 2 Safes
3. Separate Windows Domain Admin Passwords
! “Passwords of Domain Administrator Users must only be
accessible after confirmation by IT Managers!” à 1
additional Safe
4. Separate Passwords of Unix and Windows Servers
that need to be accessed by Oracle team(s)
! “Oracle Administrators need Access to Servers (Windows and
Unix) hosting Oracle Databases.” à 2 additional Safes
5. Grant Access to resulting Safes
! Privileges will depend on your authorization model/
definitions
Basic Safe Model
Windows
Passwords
“Password objects of a
specific platform must be
used by team members only.”
Oracle
Passwords
Unix
Passwords
Split Windows Passwords
Windows
Passwords
“Workstation Admins must “Password objects of a
not have access to Server specific platform must be
passwords, but Server Windows used by team members only.”
Admins have to have Workstation
access to Workstation
passwords.” Passwords
Oracle
Windows
Passwords
Server
Passwords
Unix
Passwords
Separate Windows Domain Admin Passwords
Windows
Passwords
“Workstation Admins must
not have access to Server
“Password objects of a
passwords, but Server Windows specific platform must be
Admins have to have Workstation
access to Workstation used by team members only.”
passwords.” Passwords
Windows
Oracle
Server
Passwords
Passwords
Unix
Domain Passwords
Admin
Passwords
“Passwords of Domain
Administrator Users must only be
accessible after confirmation by
IT Managers!”
Separate Passwords for Oracle Team
Windows “Password objects of a
Passwords specific platform must be
“Workstation Admins must used by team members only.”
not have access to Server
passwords, but Server Windows
Admins have to have Workstation
access to Workstation
passwords.” Passwords Oracle
Passwords
Windows
Server Unix
Passwords Passwords
Servers
Domain Servers
running
Admin running
Oracle
Passwords Oracle
Passwords
Passwords
“Passwords of Domain “Oracle Administrators need
Administrator Users must only be Access to Servers (Windows and
accessible after confirmation by Unix) hosting Oracle Databases.”
IT Managers!”
The Resulting Safe Model 1/2
Windows
Passwords
Oracle
Passwords
Windows
Workstation
Passwords
Windows
Server Unix
Passwords Passwords
Servers
Domain Servers
running
Admin running
Oracle
Oracle
Passwords Passwords
Passwords
The Resulting Safe Model 2/2
! Result: 7 Safes
1. Safe for Windows Server Passwords
2. Safe for Windows Workstation Passwords
3. Safe for Windows Domain Admin Passwords
that need Approval (Dual Control)
4. Safe for Unix Passwords
5. Safe for Oracle Passwords (Windows Servers)
6. Safe for Oracle Passwords (Unix Servers)
7. Safe for Oracle Passwords (Databases)
A Sample Safe Naming Convention
1. Safe Win-SRV
! Safe for Windows Server Passwords
2. Safe Win-WKS
! Safe for Windows Workstation Passwords
3. Safe Win-DomAdm
! Safe for Windows Domain Admin Passwords that need
Approval (Dual Control)
4. Safe Unix-SRV
! Safe for Unix Passwords
5. Safe Win-SRV-Ora
! Safe for Oracle Passwords (Windows Servers)
6. Safe Unix-SRV-Ora
! Safe for Oracle Passwords (Unix Servers)
7. Safe Ora-DBs
! Safe for Oracle Passwords (Databases)
Grant Access to Resulting Safes 1/2
Windows
Passwords
Windows Unix Admins
Windows
Workstation
Workstation
Admins
Passwords
Unix
Passwords
Windows Servers
Server running
Passwords Windows
Oracle
Domain Server Admins
Passwords
Admin Servers
Passwords running
Oracle
Passwords
Oracle Oracle Admins
Passwords
IT Managers
Grant Access to Resulting Safes 2/2
! In general Access Permissions to safes are assigned
to single users or users groups
! Monitor, Retrieve, Store, Delete, …
! Authentication Settings are defined for users and
groups, not on a safe level!
! Some restrictions apply to safes only, i.e. have to be
configured on a Safe level!
! Exclusive Passwords, Dual Control, Access Reasons, …
! In order to restrict access to safes, additional features
like locations and network areas could be used
! Note: Be careful and think twice before making use of this!
