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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.