Security Kaizen - Part II: System, Roles and Groups + Anomalies
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.
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?
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:
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.
- Part I of this article: http://community.centrify.com/t5/TechBlog/Security
- Centrify Server Suite Report Services Guide - https://docs.centrify.com/en/css/suite2016/centrif
- Centrify Splunk App - https://splunkbase.splunk.com/app/3272/
- Centrify Splunk Add-on - https://splunkbase.splunk.com/app/3271/
- Centrify PowerShell Guide - https://docs.centrify.com/en/css/suite2016/centrif
This article describes the steps to install, configure and test the Centrify Reports feature included with Centrify Suite 2016. You will find this article useful if you're looking to accomplish the following goals:
- Increase the speed of Access and Privilege related reports
- Provide information to your Security or Audit counterparts for Access or Attestation purposes
- Automate Attestation report generation and delivery
- Provide a data source for custom report generation.
Disclaimer: This post is not a best practice, it's simply to aid you to study and test the feature before your consider it for production scenarios.
What is the Centrify Reports feature designed for?
It's designed to overcome the limitations of existing report generation via LDAP (speed), provide flexibility (SSRS or Bring your Own Reporting), and increase productivity (automate report generation and distribution).
Can you describe an example?
The typical scenario is that depending on your risk or regulatory profile you need to provide user entitlements (who has access to a server or collection of servers in a Centrify zone and what can they do with Privilege using DirectAuthorize). For example:
- Who has access to UNIX/Linux or Windows Server? What privileges do they have (dzdo/dzwin)? What AD object grants access?
- Who can access this collection of systems? What privileges do they have (dzdo/dzwin)?
These entitlement reports, are used typically in attestation exercises. Attestation may be done manually (you get together an ratify that these are the proper people that should have access) or automatically using a Security Governance tool (at that point, a feed is inserted to the tool).Read more...