- Read the release notes and upgrade guide.
- Even if you don't plan to update your clients right away, you can upgrade your consoles and group policy templates.
- This is a major release and all components must be upgraded DirectControl, DirectAudit (agents/collectors/database), this is because:
- Kerberos upgrade (enables FAST/Kerberos Armoring) and AES256 Smart Card
- New LRPC2 transaction protocol
- New Open-source packaging
- OpenSSL Upgrade
- Plan for Centrify Licensing Service - have the service installed on one or two highly-available windows servers. Have your technical and procurement leads in the notification lists and designate a thresold to get proactively sent deployment reports.
- Due to the new DirectControl packaging, plan to update your DevOps recipes/cookbooks (Chef, Puppet, Ansible, etc)
Tip: adjoin has a new option “-F/--forceDeleteObj” to clean up the existing computer object and extension object in Active Directory before performing the adjoin operation. - If you're using Centrify-enhanced OpenSSH on AIX platforms, plan phase out unsupported versions or to migrate and test existing PAM support; this is because Centrify no longer ship a LAM version.
- SmartCard: RC4 and DES are no longer supported; this means you have to plan to upgrade to AES-128 or AES-256 to ensure compatibility.
- Leverage the Centrify Repo for quick updates on RPM, APT or Zypper-compatible distributions.
- The new capabilities of DirectAudit (config file monitoring, monitored execution, etc) are not turned on by default. You have to turn on the event.execution.monitor, event.monitor.commands and dash.cmd.audi.show.actual.user parameters in the /etc/centrifyda/centrifyda.conf file. Make sure you do a baseline analysis first.
- Hybrid-cloud support: remember that you can use Server Suite in your AWS, Azure or GCP deployments and that Centrify provides unique support for complex AD scenarior like one-way trusts, RODC and now Kerberos Armoring.
Implementing Identity and Access Management on Unix, Linux, SaaS and Mobile systems leveraging Active Directory and Centrify Platforms
Tuesday, February 28, 2017
Ten Tips for Server Suite 2017
Centrify Server Suite 2017 is here and it's not a trivial upgrade, there are major upgrades including Kerberos libraries and how the client packages are laid out. For those architects or sysadmins looking to implement this upgrade, let's review 10 important tips.
What's new on Centrify Server Suite 2017
What's new on Server Suite 2017
Kerberos
Flexible open-source packaging
Platform Support
Platforms Added
Kerberos- Kerberos Library Upgrade: In this release, Kerberos libraries have been upgraded to MIT 5-1.14.1.
- Flexible Authentication Secure Tunneling (FAST): Also known as Kerberos armoring, secures pre-authentication traffic and protects KDCs from error spoofing.
- This upgrade allows support for Smart Cards using AES-256 encryption. Centrify has tested with Oberthur ID One 128 v5.5 Dual SHA256 and G&D FIPS 201 SCE 3.2 SHA256 Cards.
Flexible open-source packaging
- Centrify DirectControl has leveraged OSS packages (OpenLDAP, cURL and OpenSSL); in versions prior to 2017 updating these packages required a re-spin of the whole suite (in all supported platforms)
- Starting with CSS 2017 (DirectControl 5.4) the packages for cURL, OpenSSL and OpenLDAP are independent and can be separately updated, this will allow for faster response to any CVEs that apply to those components.
- Implemented transaction control for LRPC2, this provides security improvements over heavy load. Requires that both DirectControl and DirectAudit are upgraded.
- MFA: Since Centrify Identity Service version 16.10 the IWA negotiations happen over SSL. This means that either Enterprise CA, Public CA or IWA root certificate trust must be established for Centrify Multi-factor Authentication to be successful.
- New Operation Mode (zone mode): The first release of report services works in "domain mode" this means that the "Replicating Directory Changes" delegation was required. Now in this mode, only delegations at the zones container is needed, keeping the scope of the information sent to report services only to Centrify data.
- Report options: include the ability not to generate charts as well as reports for local users.
- SSHv1 is no longer supported.
- AIX: The LAM version of Centrify-enhanced OpenSSH is no longer shipped. This is because supported versions of AIX ship with PAM enabled.
- Customers are asking to provide more efficient and proactive licence capacity and usage and many are asking for elastic licensing to support public cloud workloads.
- Centrify Licensing Service (v1) targets perpetual
licensing and provides mechanisms for streamlined capacity, inventory
and notification.
- CLS requires a highly-available Windows server that runs the licensing service (this does not have to be a dedicated server)
- The LDAP Proxy now implements new caching mechanisms (at the server auth and client) that can result in performance increases.
- MFA:
Supported at login (console, RDP, screensaver unlock) in two modes:
zone mode and zoneless mode. Zoneless mode requires a Centrify Identity
Service device license.
- Support for both MFA at login and with privilege elevation (desktop, applications) is exclusive to zone mode (requires Standard Edition license)
- Just like UNIX/Linux MFA, requires IWA over SSL, this means that Enterprise, Public or IWA root cert trust must be planned and implemented.
- Compiled with libaudit support (system call monitoring at the Kernel level) on RHEL and derivatives (more platforms coming in the next releases)
- DirectAudit is now able to monitor file changes on /etc/, /var/centrifydc and /var/centrifyda
- DirectAudit is now able to audit commands run inside scripts
- DirectAudit is now able to monitor for specific command executions.
Platform Support
Platforms Added
- Amazon Linux AMI
- CentOS 6.8 (x86, x86_64)
- CentOS 7.3 (x86_64)
- Debian Linux 7.1, 8.5-8.7 (x86, x86_64)
- Fedora 24, 25 (x86, x86_64)
- Mac 10.12 (x86_64)
- Oracle Linux 6.8 (x86, x86_64)
- Oracle Linux 7.3 (x86_64)
- Red Hat Enterprise Linux 6.8 (x86, x86_64)
- Red Hat Enterprise Linux 7.1, 7.2, 7.3 (ppc64le)
- Red Hat Enterprise Linux 7.2 (zLinux) on Standard Edition
- Red Hat Enterprise Linux 7.3 (x86_64)
- Red Hat Enterprise Linux 7.3 (ppc64)
- SUSE 12 (ppc64le)
- Ubuntu 16.10 (x86, x86_64)
- Fedora 21
- Mac 10.9
- OpenSUSE 13.1
- SUSE Linux Enterprise 10.x
- Ubuntu 15.04, 15.10
- Centrify-enhanced OpenSSH is now based on OpenSSH 7.3p1
- Centrify-enhanced sudo (dzdo) is now based on sudo 1.8.17p1
- Centrify-curl is based on libcurl version 7.51.0
- Centrify-openssl is upgraded to version 1.0.2j
- Centrify PuTTY is upgraded to version 0.67
Wednesday, February 22, 2017
Using Centrify tools to review your access and privilege management model - Part II
Security Kaizen - Part II: System, Roles and Groups + Anomalies
Part I | Part III
In the previous article of this series, we discussed the application of continuous improvement process (CIP) to security practices in the context of access control and privilege management.
We defined that the goal is to implement the least access and least privilege principles across the board and that we start by collecting metrics like the number of users with system access, privileges, etc. The idea is to Identity-Plan-Implement and Review. For example: If after reviewing the roles assigned to a user, we realize that this was a one-time request that was implemented permanently, we can eliminate the role assignment and have a process to review (perhaps every 30 days); an improvement over this could be an automatic email sent to the user to extend the access instead of removing it.
We also introduced the concept of dimensions. In the past article we focused on the user view, in this article we discuss other dimensions.
System View
Total Centrify-managed systems vs Domain-joined systems
To identify Centrify-managed systems, first you need to identify the existing zones in your environment.
Once you have identified the zones, you can enumerate the number of systems under all active zones. An improvement point is to ask: "Why are these zones in existence if no systems are currently being managed?"
Another point of concern is if a large number of classic zones are encountered. Centrify best practices since 2010 favor hierarchical zones over classic zones.
The goal in this measurement is to understand which systems are under Centrify management and aren't. For example, you can use these commandlets:
to count the Centrified systems and all AD-joined systems. This will give you a ratio of the % of systems that are managed by Centrify. For example, in my test system I have 12 total systems with 5 managed by Centrify.
This is important because you need an alternative strategy for assessing who has access and privileges on those systems OR you can ask "Why haven't these systems been set up under Centrify management?"
Computers that grant more access and computers subject to more assignments
These metrics allow you to identify the systems that have the less stringent access controls; in addition, you can identify the systems that are subject to more role assignments. Reviewing the data classification of the apps on these systems is advisable since the more access exists, the more possibilities of users saving privileged data.
Logins by System
This system view complements the "logins by user" metric discussed in the previous article. This one has an interesting twist. Note that I said I have 5 Centrified systems, however, I seem to be only getting data for 2 systems. This is an indication that perhaps there is a misconfiguration; in my case I only have the Splunk forwarder installed in two of my demo VMs. Note that in the case of hybrid cloud, because systems are treated as cattle, you may not notice users logging in at all.
Computers subject to more privileges
This is the privilege view of systems. Notice that my Ubuntu system grants more privileges than the rest; if this was a PCI or SOx system, you want to dig deeper to find out why.
Privileged Access with most computers in scope
This metric allows you to identify what rights are more prevalent in the computer population. The more common the right is, the more prevalent it will be; expect login rights (e.g. ssh, sshd or login-all) to be more prevalent. If you see something like "run as root" or "Administrative Desktop" as a prevalent command, this may be part of a sysadmin role.
Privilege Activities by Type
Often you may need to look at a system and find out exactly what the privileges activities are most common. This complements the user view (e.g. most used privileged commands)
Group and Role views
Before moving into groups and roles, let's add some context. In Centrify DirectAuthorize, the best practice is to assign roles to AD security groups; however AD security groups constitute what are called "Computer Roles" - these are nothing more than "Teams of Servers"; these constructs allow a system to belong to different types (e.g. a web server and a database server) which may be subject to roles assigned to different populations (e.g. web admins and DBAs respectively).
Roles with Most Access
These are the roles that have the broadest scope in a Centrify deployment. Note that design principles suggest that Zone-level and computer-level role assignments should be used sparingly.
AD Groups with Most Members
Depending on the deployment mode of Report Services (domain or zone) you can get information about all or only the zone-relevant groups. In this case, this graph indicates the membership numbers of groups that grant privileges in a Centrify deployment.
AD Group Attestation - Access
The picture above provides information about an AD group that is used in a Centrify deployment. Note that it also highlights if the group has any nested groups and includes a detail of the systems it grants access to.
AD Groups with Most Privileged Access
The common practice is to provide both access and privileges within the same group; therefore this report should be very familiar to the access report; however there are exceptions, especially when using selective auditing.
AD Group/Role Attestation
This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.
This is a great report to generate if you need to answer these questions:
Anomalies
Ideally anomalies are subject to security operation actions, however, as part of your overview of the access model, it's not uncommon to collect metrics of the kinds below, some of them are self-explanatory; the others we'll provide some color.
Failed Logins by reason
Users with Multiple Login Failures
Failed Logins over Time
Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.
Denied Privileged Activities over Time
A spike on these could indicate a compromised account with attempts to perform privilege elevation. MFA can help mitigate this risk.
Centrify Software Operations
Because a system that is not under management is easier to compromise, there are several operational activities that we should track:
Leave Activities
When a system is not in AD, you lose access control and the Centrify audit trail log.
DirectAudit Agent Service Stoppages
Privileged users can stop the session-capture client (DirectAudit), not without audit trail recording it. Since most systems subject to this capability most likely are highly-sensitive, all anomalies should be investigated to make sure there's no collusion.
Resources
Part I | Part III
In the previous article of this series, we discussed the application of continuous improvement process (CIP) to security practices in the context of access control and privilege management.
We defined that the goal is to implement the least access and least privilege principles across the board and that we start by collecting metrics like the number of users with system access, privileges, etc. The idea is to Identity-Plan-Implement and Review. For example: If after reviewing the roles assigned to a user, we realize that this was a one-time request that was implemented permanently, we can eliminate the role assignment and have a process to review (perhaps every 30 days); an improvement over this could be an automatic email sent to the user to extend the access instead of removing it.
We also introduced the concept of dimensions. In the past article we focused on the user view, in this article we discuss other dimensions.
System View
Total Centrify-managed systems vs Domain-joined systems
To identify Centrify-managed systems, first you need to identify the existing zones in your environment.
Get-CdmZone | Select Name, Domain, DistinguishedName, Schema
Once you have identified the zones, you can enumerate the number of systems under all active zones. An improvement point is to ask: "Why are these zones in existence if no systems are currently being managed?"
Another point of concern is if a large number of classic zones are encountered. Centrify best practices since 2010 favor hierarchical zones over classic zones.
The goal in this measurement is to understand which systems are under Centrify management and aren't. For example, you can use these commandlets:
Get-CdmManagedComputer -Zone (Get-CdmZone -Name Global) | Measure Get-ADComputer -Filter * | Measure
to count the Centrified systems and all AD-joined systems. This will give you a ratio of the % of systems that are managed by Centrify. For example, in my test system I have 12 total systems with 5 managed by Centrify.
This is important because you need an alternative strategy for assessing who has access and privileges on those systems OR you can ask "Why haven't these systems been set up under Centrify management?"
Computers that grant more access and computers subject to more assignments
These metrics allow you to identify the systems that have the less stringent access controls; in addition, you can identify the systems that are subject to more role assignments. Reviewing the data classification of the apps on these systems is advisable since the more access exists, the more possibilities of users saving privileged data.
Logins by System
This system view complements the "logins by user" metric discussed in the previous article. This one has an interesting twist. Note that I said I have 5 Centrified systems, however, I seem to be only getting data for 2 systems. This is an indication that perhaps there is a misconfiguration; in my case I only have the Splunk forwarder installed in two of my demo VMs. Note that in the case of hybrid cloud, because systems are treated as cattle, you may not notice users logging in at all.
Computers subject to more privileges
This is the privilege view of systems. Notice that my Ubuntu system grants more privileges than the rest; if this was a PCI or SOx system, you want to dig deeper to find out why.
Privileged Access with most computers in scope
This metric allows you to identify what rights are more prevalent in the computer population. The more common the right is, the more prevalent it will be; expect login rights (e.g. ssh, sshd or login-all) to be more prevalent. If you see something like "run as root" or "Administrative Desktop" as a prevalent command, this may be part of a sysadmin role.
Privilege Activities by Type
Often you may need to look at a system and find out exactly what the privileges activities are most common. This complements the user view (e.g. most used privileged commands)
Group and Role views
Before moving into groups and roles, let's add some context. In Centrify DirectAuthorize, the best practice is to assign roles to AD security groups; however AD security groups constitute what are called "Computer Roles" - these are nothing more than "Teams of Servers"; these constructs allow a system to belong to different types (e.g. a web server and a database server) which may be subject to roles assigned to different populations (e.g. web admins and DBAs respectively).
Roles with Most Access
These are the roles that have the broadest scope in a Centrify deployment. Note that design principles suggest that Zone-level and computer-level role assignments should be used sparingly.
AD Groups with Most Members
Depending on the deployment mode of Report Services (domain or zone) you can get information about all or only the zone-relevant groups. In this case, this graph indicates the membership numbers of groups that grant privileges in a Centrify deployment.
AD Group Attestation - Access
The picture above provides information about an AD group that is used in a Centrify deployment. Note that it also highlights if the group has any nested groups and includes a detail of the systems it grants access to.
AD Groups with Most Privileged Access
The common practice is to provide both access and privileges within the same group; therefore this report should be very familiar to the access report; however there are exceptions, especially when using selective auditing.
AD Group/Role Attestation
This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.
This is a great report to generate if you need to answer these questions:
- What privileges does the "Apache Web Admin" group provides?
- What role(s) are associated with it?
- What is the scope of the role assignment?
- What is the definition of the role (commands) that it provides?
Anomalies
Ideally anomalies are subject to security operation actions, however, as part of your overview of the access model, it's not uncommon to collect metrics of the kinds below, some of them are self-explanatory; the others we'll provide some color.
Failed Logins by reason
Users with Multiple Login Failures
Failed Logins over Time
Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.
Denied Privileged Activities over Time
A spike on these could indicate a compromised account with attempts to perform privilege elevation. MFA can help mitigate this risk.
Centrify Software Operations
Because a system that is not under management is easier to compromise, there are several operational activities that we should track:
Leave Activities
When a system is not in AD, you lose access control and the Centrify audit trail log.
DirectAudit Agent Service Stoppages
Privileged users can stop the session-capture client (DirectAudit), not without audit trail recording it. Since most systems subject to this capability most likely are highly-sensitive, all anomalies should be investigated to make sure there's no collusion.
Resources
- Centrify PowerShell Guide - https://docs.centrify.com/en/css/suite2016/centrify-win-powershell-guide.pdf
Tuesday, February 21, 2017
Using Centrify tools to review your access and privilege management model - Part I
Security Kaizen
This is a mirror of an article I wrote for the Centrify Community.
To be an effective security analyst, one must employ techniques like the continuous (or constant) improvement process (CIP); this concept is commonly applied in manufacturing, but it has been extended to many disciplines. The idea is to optimize the elements (people-process-technology) of a product, process or service to make it better.
In the security discipline, this requires partnership with stakeholders (infrastructure, application and business leads) to makes sure the process is not about "pointing out what's wrong" but about minimizing risk and working together to constantly align with the best security practices. This means that your stakeholders need to be part of the optimization process. This is not a top/down or policy-based approach; the idea is that everyone understands the risk factors around databreaches and can volunteer information to optimize the current security posture of the organization.
In this article I discuss the metrics provided by Centrify and integrations with third parties to aid in this constant improvement process.
We'll start with the information produced by our Centrify Server Suite (CSS). For those who don't know, CSS provides:
Centrify Zones - A powerful ally
Centrify Server Suite has been successful due to the introduction of Centrify Zones. This exclusive capability is implemented as a set of AD objects that allow the following capabilities:
The Goal: Least Access & Least Privilege Management
Before you can embark in the journey to operational efficiency, you must understand what are the goals and establish baselines; each goal can be an independent program or project; after all, "you can't manage what you can't measure."
The universal goal of privilege identity management (PIM) is to implement least access and least privilege principles. This means that users only can access the systems they require to perform their functions and their privileges don't exceed what's required for them to do their assigned duties. Shared accounts or powerful roles must have limited use, only with approval in a temporary basis.
With that established we can look at access and privileges using 4 dimensions: Users, Groups, Roles and Systems. The reasoning behind this model is simple: in mature environments, access and privileges are not assigned to the individual, but to groups (e.g. AD security groups) and these may be applied in the context of a system. Let's review some user-based metrics that can be gathered using Centrify Report Services (a tool included with CSS Standard Edition) and our integration with Splunk.
User View Metrics
Who are the users with most access on systems?
This is a basic metric because it defines your universe. It allows you to start a conversation about attestation and use the challenge "do you really need access to all these systems?"; another conversation starter is identifying non-IT or business users that have access to systems and why; if the answer is "It takes too long for me to get access" then the optimization is at the process-granting level.
Users with more access roles
This metric allows you to identify users with aggregated roles that grant access. In organizations that have not embraced temporary access control, the reports associated with this metric allows us to identify instances of granting too many access rights. This is also a great opportunity to identify redundancies and problems with the role/privilege design.
Example: note the report above. Diana is already a powerful user, but she has a role-assignment override in the Ubuntu system named engubu14. This is unnecessary because she's already a zone-level cross-platform sysadmin.
Local UNIX Accounts Managed by Centrify
If you are leveraging Centrify Zones to manage local user accounts in your UNIX-like systems, understanding how these fit in the access model is important. The question to be asked is how are the passwords for these local accounts being managed. You can leverage Centrify Privilege Service or your existing SAPM solution.
Who are the users with most privileges? Do they require those privileges?
This is another baseline metric. Now the focus is on privileges and understanding the population of users that have privileges and its context is important. If temporary access control is not being used, then attestation exercises should focus on why the privileges are needed. If the answer is that "app X breaks all the time and I need to reboot from home" then target the root of the problem (the App).
Privileged vs. Access Users
Now we're using the information in Centrify Zones about access and privileges to understand the landscape and profiles of users.
Who are the most active privileged users?
This metric can be used to find out who are really using their privileges. Watch out for users that haven't been active in a 30-day period.
How frequently are the privileged users changing their passwords?
This is a classic identity management metric. Not only this allows to identify poor practices (like account without expiration) but also compliance to policy. Frequent password changes (e.g. within a 2-3 minute threshold) if group policy allows, should also be subject to a security operations alarm.
User Overview - Attestation Report
Logins by User - Organization View
Identifying our most active users (leveraging access rights) will allow us to correlate activity vs. our universe. Make a habit of running this with a 30-day threshold to find out what users fall out of the access report - those are great candidates for temporary access.
User Overview - Most Privileged User Commands (cross-platform)
UNIX/Linux
Windows
These types of reports can be generated using different criteria (time period, user, system, etc); These could allow us to identify what are the user's biases and preferences. For example, looks like my sysadmin performs edits of files most of the time.
Making the most of your Centrify Investment
Most organizations have a journey that may or may not have been completed, perhaps it was all about authentication at one time, however Centrify has invested heavily to shift to the needs to control privileges the right way, by promoting the least access and least privilege principles across client/server platforms. Today we continue to innovate by providing multi-factor authentication; as we go to hybrid clouds, you can rest assured that we'll continue to innovate and provide the valuable insight needed to make the right decisions. In the next entry, we'll discuss the other dimensions.
Resources
This is a mirror of an article I wrote for the Centrify Community.
To be an effective security analyst, one must employ techniques like the continuous (or constant) improvement process (CIP); this concept is commonly applied in manufacturing, but it has been extended to many disciplines. The idea is to optimize the elements (people-process-technology) of a product, process or service to make it better.
In the security discipline, this requires partnership with stakeholders (infrastructure, application and business leads) to makes sure the process is not about "pointing out what's wrong" but about minimizing risk and working together to constantly align with the best security practices. This means that your stakeholders need to be part of the optimization process. This is not a top/down or policy-based approach; the idea is that everyone understands the risk factors around databreaches and can volunteer information to optimize the current security posture of the organization.
In this article I discuss the metrics provided by Centrify and integrations with third parties to aid in this constant improvement process.
We'll start with the information produced by our Centrify Server Suite (CSS). For those who don't know, CSS provides:
- Centralized administration for UNIX, Linux and OS X leveraging Active Directory
- Streamlined authentication leveraging Microsoft Kerberos
- Strong Authentication (smart card) and MFA for UNIX, Linux, OS X and Windows systems.
- Privilege Management leveraging RBAC for UNIX, LInux, and Windows systems.
- Session capture + replay and access/privilege tracking for UNIX, LInux, and Windows systems.
Centrify Zones - A powerful ally
Centrify Server Suite has been successful due to the introduction of Centrify Zones. This exclusive capability is implemented as a set of AD objects that allow the following capabilities:
- Cross-platform groupings of systems based on a governance model (zones, child-zones, computer roles)
- Access Control enforcement (least access) - only users that are UNIX identified or authorized can access a system
- UNIX identity management - consolidated AD and Local account (user/group) management
- Role-based access control - enforcement of how (what protocol or method) and what (commands, apps, desktops) can be run with privilege: without exposing a password.
The Goal: Least Access & Least Privilege Management
Before you can embark in the journey to operational efficiency, you must understand what are the goals and establish baselines; each goal can be an independent program or project; after all, "you can't manage what you can't measure."
The universal goal of privilege identity management (PIM) is to implement least access and least privilege principles. This means that users only can access the systems they require to perform their functions and their privileges don't exceed what's required for them to do their assigned duties. Shared accounts or powerful roles must have limited use, only with approval in a temporary basis.
With that established we can look at access and privileges using 4 dimensions: Users, Groups, Roles and Systems. The reasoning behind this model is simple: in mature environments, access and privileges are not assigned to the individual, but to groups (e.g. AD security groups) and these may be applied in the context of a system. Let's review some user-based metrics that can be gathered using Centrify Report Services (a tool included with CSS Standard Edition) and our integration with Splunk.
User View Metrics
Who are the users with most access on systems?
This is a basic metric because it defines your universe. It allows you to start a conversation about attestation and use the challenge "do you really need access to all these systems?"; another conversation starter is identifying non-IT or business users that have access to systems and why; if the answer is "It takes too long for me to get access" then the optimization is at the process-granting level.
Users with more access roles
This metric allows you to identify users with aggregated roles that grant access. In organizations that have not embraced temporary access control, the reports associated with this metric allows us to identify instances of granting too many access rights. This is also a great opportunity to identify redundancies and problems with the role/privilege design.
Example: note the report above. Diana is already a powerful user, but she has a role-assignment override in the Ubuntu system named engubu14. This is unnecessary because she's already a zone-level cross-platform sysadmin.
Local UNIX Accounts Managed by Centrify
If you are leveraging Centrify Zones to manage local user accounts in your UNIX-like systems, understanding how these fit in the access model is important. The question to be asked is how are the passwords for these local accounts being managed. You can leverage Centrify Privilege Service or your existing SAPM solution.
Who are the users with most privileges? Do they require those privileges?
This is another baseline metric. Now the focus is on privileges and understanding the population of users that have privileges and its context is important. If temporary access control is not being used, then attestation exercises should focus on why the privileges are needed. If the answer is that "app X breaks all the time and I need to reboot from home" then target the root of the problem (the App).
Privileged vs. Access Users
Now we're using the information in Centrify Zones about access and privileges to understand the landscape and profiles of users.
Who are the most active privileged users?
This metric can be used to find out who are really using their privileges. Watch out for users that haven't been active in a 30-day period.
How frequently are the privileged users changing their passwords?
This is a classic identity management metric. Not only this allows to identify poor practices (like account without expiration) but also compliance to policy. Frequent password changes (e.g. within a 2-3 minute threshold) if group policy allows, should also be subject to a security operations alarm.
User Overview - Attestation Report
Logins by User - Organization View
Identifying our most active users (leveraging access rights) will allow us to correlate activity vs. our universe. Make a habit of running this with a 30-day threshold to find out what users fall out of the access report - those are great candidates for temporary access.
User Overview - Most Privileged User Commands (cross-platform)
UNIX/Linux
Windows
These types of reports can be generated using different criteria (time period, user, system, etc); These could allow us to identify what are the user's biases and preferences. For example, looks like my sysadmin performs edits of files most of the time.
Making the most of your Centrify Investment
Most organizations have a journey that may or may not have been completed, perhaps it was all about authentication at one time, however Centrify has invested heavily to shift to the needs to control privileges the right way, by promoting the least access and least privilege principles across client/server platforms. Today we continue to innovate by providing multi-factor authentication; as we go to hybrid clouds, you can rest assured that we'll continue to innovate and provide the valuable insight needed to make the right decisions. In the next entry, we'll discuss the other dimensions.
Resources
- Centrify Server Suite Report Services Guide - https://docs.centrify.com/en/css/suite2016/centrify-reporting-guide.pdf
- Centrify Splunk App - https://splunkbase.splunk.com/app/3272/
- Centrify Splunk Add-on - https://splunkbase.splunk.com/app/3271/
Subscribe to:
Posts (Atom)