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
No comments:
Post a Comment