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!