Security Kaizen - Part III: Web Apps, Mobile/Mac and MFA
In the first two articles of this series we have discussed some metrics that can help security analysts in the evaluation of their access and privilege management models in a Centrify deployment using Server Suite.
The whole premise is to treat the process of limiting access/privileges as a subject of a continuous improvement cycle where we apply root-cause analysis and implement improvements to the security posture of the organization.
In this third iteration we're going to shift gears to other areas of the Centrify world and we'll focus on web applications. In this entry we'll focus on Centrify Identity Service. CIS is a best-of-breed Identity as a Service solution that provides simple federated SSO, self-service, mobile device/application/container management and much more. What you'll see below is included with the product in the form of reports and dashboards; in addition to these capabilities, we have released an analytics engine that is a companion to CIS. Read all about it here.
With CIS, we're going to discuss these dimensions: Apps, Users (including admin users), Roles, MFA and Mobile.
When dealing with Applications, one of the most common goals in the context of access management is to consolidate application authentication patterns. The principle is to move away from local user/password repositories because this is one less point of risk and compliance enforcement. For each user/password app, security analysts must worry about alignment with policy, roles/rights, mitigation for advanced threats, attestation, etc.
If an application is using a modern approach (like federation) is easier to provide the assurance of compliance and this also makes the application much more portable.
Total Deployed Apps
The first place to start is to identify your application real-estate. Understanding how many applications are deployed in your environment is the first place.
select count (*) from application;
Apps not in use
Another great piece of information is to find out what applications are not in use. If an app is published and has no audience, perhaps this needs to be reconsidered. This can be found under Reports > Applications > Unused Web Apps
% of Apps using Federation
As stated above, the goal is to eliminate user/password applications. You can create a ratio of total apps that support federation / total apps; this will give you a good target percentage; since some apps are kept due to legacy and political reasons, each app move to modern patters may be a project or a program in itself.
As an example, you can modify one of the built-in reports to obtain the SAML-capable apps from the existing installation:
select ID AS _ID, DisplayName, WebAppType, Category, Description
order by AppTypeDisplayName, Category, DisplayName
Unique application launches and App launch events
Although these are operational metrics, they are correlated with user activity and roles (see below); For example in the pics above I've drilled on App launches related to the Amazon root account and the IAM federated app. This is because those apps are use by very high-privileged users.
Most Commonly Used Apps
This can be generated as a report; commonly used apps may indicate heavy line-of-business apps and is an indicator of potentially-sensitive information.
Look at the Top apps in this example: Salesforce (sales/customer data); Office 365 (all kinds of data), Workday (employee data).
There are multiple areas to focus on apps (including mobile) but let's focus on the CIS user view.
Users in Identity Service can have assigned applications, provisioned applications and roles. Roles may be used for application access (RBAC) and for privileges in the platform.
Assigned Apps (user)
The goal continues to be the least access principle and we want to make sure that users only have access to the apps that they need.
Provisioned Apps (user)
Provisioned apps allow for just-in-time provisioning (or de-provisioning) of users and if supported, role assignments.
Notice how you can also identify anomalies.
Roles Assigned (and Entitlements)
Note how a role also provides the user with privileges in the platform.
User Logins vs. User Failed Logins
It's always important to review this type of activity, however Identity Service provides an additional dimension - geo-location; this provides better intelligence for security operation decision.
Any failure attempts in geographies that the enterprise does not have a presence should be flagged or subject to additional scrutiny.
Administrative users may change apps, roles and settings in the overall platform. Typically, when apps are being deployed, there are many changes being logged, but once an application is stable, it should be "locked" and the changes should only be under approval by change control committee unless there's emergency changes needed.
Activities in this area depend on the RBAC model implemented. If administrators make membership changes directly on the Identity Service roles, then activity will reflect natural business operations;however, if using the target groups (e.g. AD security groups), then the changes to roles should be minimal.
Challenges and Multi-factor Authentication
MFA is a key part of Identity service and the metrics around this capability can be very useful to understand user behavior and potential threats. Identity Service supports different types of authentication profiles that may include Smart Card/YubiKey/OATH as MFA methods and SMS, phone factor, and e-mail as step-up methods; it can also support RADIUS challenges to accommodate for legacy tokens like RSA SecurID, Vasco or Symantec.
Successful and Failed Challenges
A challenge happens when MfA is invoked, therefore a failed challenge is a causal factor behind failed logins.
Challenges and Authentication Events
Pay special attention to failed challenges; these are instances in which an MFA (or step-up) mechanism has been invoked but it hasn't been satisfied. Repeated attempts are subject to security alarms.
Authentication Events - Pattern
Authentication patterns are relatively predictable in some organizations (this depends on their timezone footprint), this means that you should understand a normal ratio (e.g. failed challenges/total challenges) over certain periods of time (after all, users miss challenges), but any spike, especially outside normal hours should be a subject of additional investigation. Notice the change on the wave pattern once we hit Saturday (18).
Stats around mobile could be geared towards maintaining device conformance to a standard (e.g. minimum version for iOS shall be v10), understanding the make-up of the devices and making sure that capabilities that are compensating controls for data protection or leakage are deployed.
Enrolled Device Compliance
In this metric it's important to understand what are the key components of device alignment with policy. As new mobile devices and OSs are deployed, capabilities may evolve or can be superseded for better ones. User intervention is also a challenge when it comes to mobile devices, however, organizations can have stronger policy in corporate-owned devices vs. devices brought by the end-user (BYOD).
A large percentage of unreachable devices may mean that if you're using self-service enrollment, you may be allowing too many of them. For example, a limit of 2 devices is preferable than 5 (default).
Device Real Estate
This pie chart provides the answer to a key question - how many devices are out there and what's the make-up.
Identity service provides a set of policies that provide the assurance that users can't enroll older devices that may not be subject to manufacturer updates that are vulnerable to risks.
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-Corner-Reviewing-your-Access-and-Privilege-Manage...
- 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/centrify-win-powershell-guide.pdf