Security Kaizen - Part II:  System, Roles and Groups + Anomalies

Part I | Part II | Part III | Part IV

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

comp-roles.png

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.

logins-by-system.png

 

 

Computers subject to more privileges

comp-most-priv.png

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

priv-access-most-comp.png

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)

priv-act-by-type.png

 

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.

roles-wmost-access.png

 

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.

groups-most-members.png

AD Group Attestation - Access

access-group.png

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.

access-group.png

 

AD Group/Role Attestation

This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.

rights-report-group.png

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

failed-logins-reason.png

Users with Multiple Login Failures

users-mult-login-fail.png

Failed Logins over Time

failed-logins-overtime.png

Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.

 

 Denied Privileged Activities over Time

denied-overtime.png

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

leave-activities.png

When a system is not in AD, you lose access control and the Centrify audit trail log.

 

DirectAudit Agent Service Stoppages

audit-stop.png

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

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel