× Welcome to the Centrify Community! Looking for Express & Smart Card Help? Click Here

[Security Corner] Reviewing your Access and Privilege Management Model with Centrify tools (3/4)

[Security Corner] Reviewing your Access and Privilege Management Model with Centrify tools (3/4)

By Centrify Guru I ‎02-22-2017 09:48 AM

Security Kaizen - Part III: Web Apps, Mobile/Mac and MFA

Part I | Part II | Part III | Part IV

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 iterationid-service.PNG 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.

 

Application Dimension

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

usused apps.png 

% 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 
from Application
where WebAppType='Saml'
order by AppTypeDisplayName, Category, DisplayName

saml-apps.png

Unique application launches and App launch events

app-launch-events.pngapplaunches.png

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.
apps.PNG

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.

 

User Dimension

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)

assigned-applications.png

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-applications.png

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)

role-user-view.png 

Note how a role also provides the user with privileges in the platform.

 

User Logins vs. User Failed Logins

logins.png

failed-logins.png

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.

failed-login-map.png

Any failure attempts in geographies that the enterprise does not have a presence should be flagged or subject to additional scrutiny.

 

Administrative User

 

Application Changes

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.

 

app changes.png

 

Role Changes

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.

role-changes.png

 

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

faild-logins.png

A challenge happens when MfA is invoked, therefore a failed challenge is a causal factor behind failed logins.

 

Challenges and Authentication Events

chall-type.png

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

auth-events.png

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).

 

 

Mobile

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

dev-comp.png

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).

 

Device Status

 

status-dev.png

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

dev-realestate.png

This pie chart provides the answer to a key question - how many devices are out there and what's the make-up. 

dev-os.png

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. 

 

Resources

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel