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 I: Privileged User
To be an effective security analyst, one must employ techniques like the continuous (or constant) improvement process (CIP); this concept is commonly applied in manufacturing, but it has been extended to many disciplines. The idea is to optimize the elements (people-process-technology) of a product, process or service to make it better.
In the security discipline, this requires partnership with stakeholders (infrastructure, application and business leads) to makes sure the process is not about "pointing out what's wrong" but about minimizing risk and working together to constantly align with the best security practices. This means that your stakeholders need to be part of the optimization process. This is not a top/down or policy-based approach; the idea is that everyone understands the risk factors around databreaches and can volunteer information to optimize the current security posture of the organization.
In this article I discuss the metrics provided by Centrify and integrations with third parties to aid in this constant improvement process.
We'll start with the information produced by our Centrify Server Suite (CSS). For those who don't know, CSS provides:
- Centralized administration for UNIX, Linux and OS X leveraging Active Directory
- Streamlined authentication leveraging Microsoft Kerberos
- Strong Authentication (smart card) and MFA for UNIX, Linux, OS X and Windows systems.
- Privilege Management leveraging RBAC for UNIX, LInux, and Windows systems.
- Session capture + replay and access/privilege tracking for UNIX, LInux, and Windows systems.
Centrify Zones - A powerful ally
Centrify Server Suite has been successful due to the introduction of Centrify Zones. This exclusive capability is implemented as a set of AD objects that allow the following capabilities:
- Cross-platform groupings of systems based on a governance model (zones, child-zones, computer roles)
- Access Control enforcement (least access) - only users that are UNIX identified or authorized can access a system
- UNIX identity management - consolidated AD and Local account (user/group) management
- Role-based access control - enforcement of how (what protocol or method) and what (commands, apps, desktops) can be run with privilege: without exposing a password.
This means that we have in Active Directory the definitions for access and privileges, plus the corresponding clients always send the information to the correct place (event log, syslog); making CSS a rich source of information for any security professional.
The Goal: Least Access & Least Privilege Management
Before you can embark in the journey to operational efficiency, you must understand what are the goals and establish baselines; each goal can be an independent program or project; after all, "you can't manage what you can't measure."
The universal goal of privilege identity management (PIM) is to implement least access and least privilege principles. This means that users only can access the systems they require to perform their functions and their privileges don't exceed what's required for them to do their assigned duties. Shared accounts or powerful roles must have limited use, only with approval in a temporary basis.
With that established we can look at access and privileges using 4 dimensions: Users, Groups, Roles and Systems. The reasoning behind this model is simple: in mature environments, access and privileges are not assigned to the individual, but to groups (e.g. AD security groups) and these may be applied in the context of a system. Let's review some user-based metrics that can be gathered using Centrify Report Services (a tool included with CSS Standard Edition) and our integration with Splunk.
User View Metrics
Who are the users with most access on systems?
This is a basic metric because it defines your universe. It allows you to start a conversation about attestation and use the challenge "do you really need access to all these systems?"; another conversation starter is identifying non-IT or business users that have access to systems and why; if the answer is "It takes too long for me to get access" then the optimization is at the process-granting level.
Users with more access roles
This metric allows you to identify users with aggregated roles that grant access. In organizations that have not embraced temporary access control, the reports associated with this metric allows us to identify instances of granting too many access rights. This is also a great opportunity to identify redundancies and problems with the role/privilege design.
Example: note the report above. Diana is already a powerful user, but she has a role-assignment override in the Ubuntu system named engubu14. This is unnecessary because she's already a zone-level cross-platform sysadmin.
Local UNIX Accounts Managed by Centrify
If you are leveraging Centrify Zones to manage local user accounts in your UNIX-like systems, understanding how these fit in the access model is important. The question to be asked is how are the passwords for these local accounts being managed. You can leverage Centrify Privilege Service or your existing SAPM solution.
Who are the users with most privileges? Do they require those privileges?
This is another baseline metric. Now the focus is on privileges and understanding the population of users that have privileges and its context is important. If temporary access control is not being used, then attestation exercises should focus on why the privileges are needed. If the answer is that "app X breaks all the time and I need to reboot from home" then target the root of the problem (the App).
Privileged vs. Access Users
Now we're using the information in Centrify Zones about access and privileges to understand the landscape and profiles of users.
Who are the most active privileged users?
This metric can be used to find out who are really using their privileges. Watch out for users that haven't been active in a 30-day period.
How frequently are the privileged users changing their passwords?
This is a classic identity management metric. Not only this allows to identify poor practices (like account without expiration) but also compliance to policy. Frequent password changes (e.g. within a 2-3 minute threshold) if group policy allows, should also be subject to a security operations alarm.
The report above can be generated with this PowerShell one-liner:
Get-ADUser -Filter * -Properties passwordlastset, passwordneverexpires
| sort-object name | select-object Name, passwordlastset,
passwordneverexpires | Export-csv -Path c:\reports\passwd.csv
User Overview - Attestation Report
Obtaining consolidated attestation reports is a challenge for all organzations. With Server Suite report services, you can get reports that show the user's access across platforms like Windows and UNIX systems; what granted access (role assignment) and the rights contained within those roles.
Logins by User - Organization View
Identifying our most active users (leveraging access rights) will allow us to correlate activity vs. our universe. Make a habit of running this with a 30-day threshold to find out what users fall out of the access report - those are great candidates for temporary access.
User Overview - Most Privileged User Commands (cross-platform)
These types of reports can be generated using different criteria (time period, user, system, etc); These could allow us to identify what are the user's biases and preferences. For example, looks like my sysadmin performs edits of files most of the time.
Making the most of your Centrify Investment
Most organizations have a journey that may or may not have been completed, perhaps it was all about authentication at one time, however Centrify has invested heavily to shift to the needs to control privileges the right way, by promoting the least access and least privilege principles across client/server platforms. Today we continue to innovate by providing multi-factor authentication; as we go to hybrid clouds, you can rest assured that we'll continue to innovate and provide the valuable insight needed to make the right decisions. In the next entry, we'll discuss the other dimensions.
- Part II 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/centrify-reporting-guide.pdf
- Centrify Splunk App - https://splunkbase.splunk.com/app/3272/
- Centrify Splunk Add-on - https://splunkbase.splunk.com/app/3271/
IT Professionals are often required to provide evidence of alignment with security regulations. At Centrify, since we provide Identity and Access Management solutions, this means that providing capabilities that satisfy regulations is at the heart of many of our products; it drives design, engineering and marketing efforts.
All this would be nothing if we weren't in the position to coach our customers and prospects on how we can meet or exceed their needs. This entry is based on a template email that we developed in the New York Metro region to assist when our customers ask us how to prove Server Suite's alignment with the Sarbanes-Oxley Act.Read more...