Sunday, February 4, 2018

Centrify and the Microsoft Enhanced Security Administrative Environment - The basics (FAQ)

This is an article I wrote for the Centrify community around Microsoft Red Forest (ESAE).  The goal of the article is to serve as an introduction to the topic.  For the full series, visit 

FAQ: Microsoft Enhanced Security Administrative Environment and Centrify - The Basics
1. What's the MS Enhanced Security Administrative Environment?
It's a series of recommendations and technologies to prevent credential theft in Windows environments.

2. What is Red Forest?
Although the terms MS ESAE and Red forest are often interchanged, Red Forest refers specifically to ONE of the recommendations:  Set-up an administrative Active Directory forest exclusively for privileged accounts and connect it to the corporate forest by a selective one-way trust.  Note that this is an over-simplification.  For more info, click here.

3. What is Pass the Hash (PtH)?
PtH is a very commonly used attack used in Windows networks to harvest credentials, it's been around since early this decade (but may have been around earlier). The idea is that after a Windows system is compromised with a specific program running with Administrator rights, the NTLM password hash of a user can be captured once any of these things happen:

  • A user logs in interactively to the infected system (remotely or using RDP).
  • A user launches a program using the "Run As"  command.
  • The user types-in a new credential to access a network resource that she is not authorized to use (or under a different realm).
  • A Windows service configured with a credential is started.
  • And many more.
Note that PtH is one (quite popular) way to harvest credentials to move laterally in an environment. There are many other techniques used to harvest credentials.
For more info about PtH, click here.

For more info about attractive credentials in Windows environments, click here.

4. What's the worse case scenario when PtH (and other related techniques) are used?
Total breach, including the ability to impersonate any user on an Active Directory-based infrastructure.

5. What is the goal of MS ESAE?
Although the ideal goal is to completely protect against techniques for credential theft, the more realistic goal is to take the credential theft techniques off the attacker's toolbox, like PtH. This will force them to use riskier techniques that increase the likelihood of detection.

6. What are the principles around ESAE?
Although any principles outlined in this section are likely to evolve as Microsoft adds newer technologies (and bad actors adapt to them), There have been several versions of the techniques to protect Windows Networks starting with some of the original "Securing Active Directory" whitepapers.

Assume Node Breach
Based on my research, the most basic principle is to operate under an assumed "node breach" - this is aligned with another assumption in a different stack: networking.  In this stack ideally you'll treat every network as if it were a public network. In the context of Windows systems, this is to assume all nodes can potentially be compromised unless you have deployed controls to provide the assurance otherwise.  This aligns as well with some of the concepts around our Zero Trust Model.
The pillars of the Zero Trust Model
Now, here's my attempt to consolidate the principles outlined by the different whitepapers that discuss the Microsoft Enhanced Security Model.  We will expand on each principle (as it relates to Centrify in the next posts in this series).

  • Principle # 1 (P1)  Perform the basic steps to secure your Active DirectoryWhy?  Because any serious security shop makes this into their normal policy.  It's all about reducing the attack surface.
    Here are some of the "common-sense" practices (however, the reality is that even the most mature organizations struggle with these).
    • Reduce the number of Administrators and manage security group membership.
    • Establish administrative workstations (or servers).
    • Protect Domain Controllers and maintain them up-to-date.
    • Monitor your environment.
  • Principle #2 (P2) Have a plan to migrate applications and services that depend on NTLM.Why? Because eliminates PtH outright.  If there's no NTLM hash to be harvested, the bad actor needs to move on and use other techniques.
    This is probably one of the hardest projects for any major enterprise.  Windows services and business apps "just work" in many instances because of the backwards-compatibility capability enabled by supporting NTLM. 
    The good news is that Centrify for UNIX, Linux and Mac does not need NTLM to work. You can disable it in favor of Kerberos-only, nonetheless, as stated, your mission critial application or service may not agree with you disabling NTLM.
  • Principle #3 (P3)  Separate user accounts vs admin accounts.Why?  Malware has limited effect on regular user accounts.  Also, remember the preconditions for the common credential theft techniques:  Rogue software needs to be running with administrative rights.
    This one has been controversial over the years, especially because Centrify has always embraced least privilege. 

    At Centrify we are commited to making the best Administrative account management capability and this will be evident in a couple of months with our Infrastructure Service CPS; however, rest assured that Centrify supports Separation of Duties and Delegation in all its products.

  • Principle #4 (P4)  Implement distinct admin passwords per workstation.
    Why?  Same as above:  to prevent lateral movement.  If the same "corporate password"  is used for local Administrators, you just enabled the bad actor to move laterally times all the workstations/servers that are available.
    At Centrify, with our vault we have attacked this problem on servers and desktops, last year we tackled the problem on OS X for laptop users, and we are working to bring this for laptop users on Windows.
    Centrify's LAPM for Mac offers a Self-Service capability
  • Principle #5 (P5)  Use "Privilege Access Worksations" for administration (using the clean source principle).
    Why:  to limit the possibility of malware (or persistent malware).
    This is an enhanced versio of one of the common-sense Windows practices; but now with how pervasive VDI technologies are, it's possible to almost eliminate the possibility of malware.   For example, a computer with Windows administrative tools (or Centrify's) can be launched as a non-persistent VDI session from a clean source.  This provides the assurance that this is a "clean" system.  Centrify does offer additional capabilities to enhance the use of PAWs:
    • MFA
    • Conditional Access
    • Centrify Zone-based access control (this layers an additional access model to Windows leveraging AD)
    • Secure Privilege Elevation (use token manipulation instead of password replay)
    • Audit Trail to enrich security operations
    • Session Capture and Replay
    • Attestation for Access and Privileges
      We will dedicate a post only to discuss how we can enhance Microsoft's PAW recommendation.
  • Principle #6 (P6)  Control the privileges of service accounts.Why:  control privileges, reduce the attack surface.
    This is another hard goal to achieve because it's deeply tied to how
    applications are written.  In the subsequent articles we'll discuss how we can discover, manage and secure Windows Services, Scheduled Tasks and IIS Application pool identities.
    Service Discovery in Infrastructure Services
    These principles have been in Centrify products for a while.  We use a reduced number of service accounts and we guide you with exactly what's required for least privilege when those are needed.
  • Principle #7 (P7)  Don't allow regular users to have administrative rights in endpoints (desktops, laptops, etc.)
    Why:  the attack surface in an organization where all users have admin rights is: all users and workstations.  It's about reducing the attack surface.
    Unfortunately, organizations struggle with this concept because the security industry has not embraced temporary access in a way that makes it easy to request spot administrative rights in Windows workstations. 

    We have some capabilities already and are working focused in this area.  In the next few articles we'll discuss in-depth.
  • Principle #8 (P8) Embrace Temporary Access Controls (JIT, on-demand).
    Why:  Because once a credential is used, if it's no longer privileged, lateral movement and the effects of compromise can be limited.
    Organizations must declare war to permanent privileged accounts; however, this problem is not about technology but around workflow. 

    This is why we are investing in areas like faster and simpler workflow, mobile approvals, ServiceNow integration and fast communication to our clients.  The idea is to eliminate some of the "business dynamics" that challenge the implementation of just in time access and privileges.  Just in time access is another pillar of our implementation of the Zero Trust Model.
  • Principle #9 (P9)  Deploy an administrative forest (Red Forest) with a selective one-way trust and limit upwards administration in the corporate side.
    Why:  To proctect privileged accounts and set new rules.
    Although we are of the opinion that Red Forest adds a lot of complexity, it comes from Microsoft and many organizations will deploy the model or components of it.
    Figure showing an ESAE forest used for administration of Tier 0 Assets and a PRIV forest configured for use with Microsoft Identity Manager's Privileged Access Management capability
    Depending on the data classification of the information on systems secured by Centrify; administrative accounts need to adhere to the principles; and we can provide administrative privileges to accounts coming from the red forest.  This is something our competitors (especially on the UNIX/Linux side, have a tough time achieving).  Ultimately this works in conjunction with all the principles outlined here.
  • Principle #10 (P10) Use critical thinking - MS ESAE is complex and may not work in all instances
    Why:  Because the principles of security need to be maintained.  This is all about risk mitigation or management and due-diligence. 
    At Centrify we specialize in Access Controls and have always preached the maximization of "what you have" and the use in non-Windows systems on premises and in IaaS.  Follow the principles of controls stacking (spend more on prevention and correction than detection). 
    For example, our Identity Broker capability on Linux allows for AD (LDAP, Google, etc) users to be authenticated to AD without the need of using Domain Controllers nearby.  There is no NTLM hash.

7. I see Centrify has a Password Vault, can it protect me against Windows Credential Theft techniques like PtH?
I think no security vendor with regards to their credibility will pitch a password vault as the sole mechanism against Windows credential theft.  It can't... just use privilege session or replay the password and that's it!  Compromised credential; and most likely, since you had it vaulted, it will be very useful to move laterally or escalate privileges.   

A vault can, however:
  • Help you separate user vs. administrative accounts
  • Help you rotate passwords automatically
  • Be used to in conjunction with a Privilege Access Workstation
  • Allow you to establish distinct local server/workstation passwords and help you rotate them
  • Some vaults provide the ability to provide and enforce Temporary Access
The answer you want to hear here is:  A PV can help you as part of the toolset to implement controls against credential theft. The benefit here is that Centrify is the only vendor uniquely positioned to provide vault-based, system-based and IDaaS based security.  This helps in vendor consolidation and productivity.

8. I see Centrify provides MFA capabilities, can it protect me against Windows Credential Theft techniques like PtH?
Same response as above.  MFA can't help you against a compromised Windows system running malware.  You have to replay your password!  If your system, group or policy allows for you to issue an NTLM hash, you are done (in the case of PtH). 

MFA can absolutely protect you against credential theft if the credential is being used interactively on a resource being protected by MFA.   The difference here is that most of the time, when a credential is harvested, it tends to be used programmatically.

9. I see Centrify supports Smart Card authentication, we are deploying it as a technique to prevent Windows Credential Theft techniques like PtH.  Am I in the right track?
Same response as above.  MFA can't help you against a compromised Windows system running malware.  In the case of Smart Cards, there is still a password generated for you by the AD domain controllers.  Great control to prevent interactive theft.

10. What are the Active Directory Capabilities that help against Credential Theft and how do they map to Centrify capabilities?
At this point there are dozens of capabilites in place, starting with stronger crypto in Windows Server 2008 Active Directory all the way to Shadow Groups in Windows Server 2016 AD.  We will dedicate a full community post just to go over these in the context of a Centrify deployment.

  • Microsoft's PTH website:
  • Microsoft's Securing Privilege Access:
  • Best practices for securing Active Directory:
  • Channel9:
Next Article:
MS ESAE - Principles Showcase: How Centrify aids, enhances or fits in this model.

Saturday, December 30, 2017

Centrify 2017.3 - Windows: Self-Service and Win10 MDM Enrollment

This article is based on an entry I wrote for the Centrify Community.

Platform Capabilities
Self-Service Overview
The Centrify Identity Platform provides self-service capabilities that can be leveraged from the web portal  These capabilities include:
  • Self-Service Password Reset for Centrify Directory and Active Directory users.
  • Self-Service Account Unlock for Centrify Directory and Active Directory users.
Self-Service - How it works
  • Policy-based implementation:  Self-service capabilities are implemented by policy.  This means that you can enable/disable these capabilities based on the scope of the policy and this is quite handy especially if you want to offer these capabilities only to a segment of the population.
  •  Multi-factor Authentication:  MFA is the mechanism to establish identity assurance when performing self-service operations (password reset and unlock).  This allows for administrators to adjust Authentication Profiles based on the type and sensitivity of these operations in the target population.  For example, for a user that does not deal with sensitive data, step-up methods (like SMS, Phone Factor, e-mail or questions) may be acceptable; however, for an admin-type, you may require of them to use a physical (true) MFA method via Mobile Authenticator, RADIUS-legacy OTP, OATH OTP or even FIDO U2F device (like Yubikey) to facilitate.
  • Automatic detection of locked accounts:  A locked CD or AD account is detected automatically and the corresponding activity workflow is triggered (e.g. walking the user through the unlock authentication profile).

Endpoint Management - Overview
Centrify was the first Identity as a Service (IDaaS) provider to include both endpoint (mobile device/container/application management) as a built-in capability (along with MFA).  This has given us a unique position in the market.  With Windows 10 supporting MDM operations we are embarked in a process of incrementally adding capabilities to the Centrify Agent for Windows(tm).

Endpoint Management - How it works
  • Policy-based implementation:  Endpoint policies are implemented by policy.  This means that you can enable/disable these capabilities based on the scope of the policy and this is quite handy especially if you want to offer these capabilities only to a segment of the population (e.g. users with corporate-owned devices vs. personalized or BYO).
    The policy payload can be delivered using Centrify's policy engine or Active Directory Group Policy.
  • Platform Diversity and frameworks:  Depending on the platform, Centrify can provide varying degrees of depth.  For example, iOS, Android and other mobile devices have their own frameworks (e.g. APNS for iOS), however with OS X, not only we support the existing framework, but we enhance application management via Munki-based services.  In the case of Windows, expect incremental capabilities to be delivered when Configuration Service Providers are implemented.

Self-Service Capabilities in Microsoft Windows
Password reset (and account unlock) are popular identity management capabilities, and Windows has had the framework for years.   The graphical identification and authentication (GINA) in earlier versions of Windows, and now with Windows 8  and above, the Credential Provider is the framework used to deliver these capabilities.

Since MFA was introduced on Windows a couple of years ago, weintroduced a Credential Provider that is now extended to provide self-service password reset (2017.3) and account unlock (2018).  These capabilities in this version apply to Active Directory accounts only.

User Flow
Precondition:  An Active Directory writable domain controller has to be reachable by means of the corporate network or VPN.
  1. User presses ctrl+alt+delete to invoke the Windows credential provider.
  2. User clicks the "Forgot Password" link and confirms and presses the arrow.
  3. At this point, the Windows client talks to the Centrify connector that will verify if the user is allowed by policy to perform the operation.
  4. Once verified, the user will be presented with the MFA or step-up methods defined for the SSPR authentication profile in the Centrify platform.
  5. Provided the user types a password that is allowed by the Active Directory password policy rules, the user will successfully reset their password. 
  6. An audit trail event will be logged in the application log of the Windows system and the Centrify platform event table will be updated.
Notes:  although account unlock is not officially released in 2017.3, the behavior is relatively similar, the biggest difference is that we will automatically detect the unlock state and trigger the proper identity assurance mechanism.

  • Multi-factor authentication for identity assurance.
  • Audit trail (application event log) to provide a mechanism for Security Operations solutions like Splunk, etc.
  • CIP Events are also tracked in the platform's event table.
Audit Trail
Audit trails detail is especially important given that self-service metrics are usually captured to illustrate how these capabilities contribute to productivity.

Self-Service operations are tracked by the security dashboard in Centrify Identity Platform.
The dashboard allows administrators or security leads to focus on an operation (e.g. denied self-service) and offers the scoping of the date range, once selected, you can drill into the users, failure reason as well as an overlay of their geo-location (if the client is reporting it) as well as the factors being used.

Windows 10 MDM Enrollment
MDM enrollment with the "connect to work or school"  facility.  Based on their own website:
" Windows 10 provides an enterprise management solution to help IT pros manage company security policies and business applications, while avoiding compromise of the users’ privacy on their personal devices. A built-in management component can communicate with the management server.

There are two parts to the Windows 10 management component:
  • The enrollment client, which enrolls and configures the device to communicate with the enterprise management server.
  • The management client, which periodically synchronizes with the management server to check for updates and apply the latest policies set by IT.
Third-party MDM servers can manage Windows 10 by using the MDM protocol."

With the Centrify Agent for Windows included with Infrastructure Services  2017.3, we now support automatic Windows 10 MDM enrollment as corporate-owned systems, with the optional capability for personalization.  In this release we provide:
  • Administrative (bulk) enrollment (corporate-owned)
  • Enrollment personalization (personal)
  • Zero sign-on for to Centrify Apps Service from Windows (Internet Explorer or Edge) and Google Chrome browsers.
 This opens the possibility for future capabilities, including the configuration service providers.

Videos - Self-Service
Centrify Identity Platform - Self-Service Features Overview
Self-Service Password Reset using the Windows Credential Provider

Bulk Deployment - Corporate Owned Devices

Enrollment Personalization and Zero Sign-On

Friday, December 29, 2017

Centrify 2017.3 - Container Linux by CoreOS is now supported

In this article, we'll discuss Centrify's support for Container Linux by CoreOS introduced with 2017.3 (5.4.3).  This is based on an article I wrote for the Centrify Community.

About Container Linux by CoreOS
"Container Linux by CoreOS (formerly CoreOS Linux) is an open-source lightweight operating system based on the Linux kernel and designed for providing infrastructure to clustered deployments, while focusing on automation, ease of application deployment, security, reliability and scalability. As an operating system, Container Linux provides only the minimal functionality required for deploying applications inside software containers, together with built-in mechanisms for service discovery and configuration sharing." - Source: Wikipedia.

Engineering Challenges
We had to overcome some challenges based on how Container Linux is architected.
  • No package manager (required to deploy our solutions).
  • Read-only /usr filesystem (Centrify usually installs under /usr/share/centrifydc and audit under /usr/share/centrifyda).
  • No Perl (required by group policy and other utilities).
  • Kernel not compiled with auditd support (required for file/monitoring).
Needless to say, our Engineering team was up to the task and was able to provide a solution that enabled our capabilities and maintained the ease-of-use that is common with Centrify solutions.

  • Centrify provides an installation tarball with the 2017.3 agent bundle that includes Access and Audit components.
  • A special version of the utility will allow for interactive or automatic installations.
  • Centrify software is installed in the /opt/centrify folder.
  • Limitations:  Express mode, deployment manager installation and monitoring service are not available.
Host-Based Security
  • Increased accountability - Container Linux users can sign-in with their Active Directory account.  We provide identity assurance with Multi-Factor Authentication.
    In AWS deployments, organizations don't need to rely on the shared SSH Key-based credential called "core"
  • Centralized administration - Organizations don't have to duplicate effort and continue to leverage Active Directory as the directory of record.  No modifications required.
  • Identity Management - Leverage Centrify zones to maintain a consistent UNIX namespace.
    You can leverage AD groups to control the memberships in the docker secondary UNIX group.
  • Role-based Access Control - Use Centrify zones to control who can access a system, and what commands can be run with privilege.  For example:
    • You can create a role that defines who can elevate to root or the core accounts.
    • You can use Active Directory group membership to define who is a member of the docker(233) secondary group.
    • You can define very granular docker commands that can be granted to minimize risk or enforce separation of duties.
  • Attestation and Security Operations -  Leverage Centrify Reports to facilitate attestation and Centrify Audit Trail to enrich security operations.
  • Advanced Auditing -  Enjoy audit trail events as well as session capture and replay. 
  • Extend host-based security to Linux Containers (LXC) - Centrify "bridges" capabilities to Linux Containers to enjoy the same level of accountability at the container level.
Vault-Based Security 
  • Shared Account Password Management - if you need to use shared credentials, use the Centrify Privilege Service vault and enjoy the deployment flexibility and traditional password-related controls.
  • Secure Access -  privilege Service connector infrastructure allows for Web, Native or SSH jumpbox client access regardless of on-premises or IaaS deployments. 
  • Session Proctoring, termination and recording - Enjoy the benefits of session control as well as auditing without the need to add local capabilities.

Videos - Centrify + Container Linux in action

What's different in Container Linux

Host-based  Access Control, Identity Assurance and Role-Based Privilege Management
Vault-based Access Control, Shared Accounts and Secure Access

Using Role-based Access Control to manage and establish accountability for Docker operations

Centrify and Linux Containers (LXC)

Saturday, November 18, 2017

[Labs] Centrify's SSH Gateway Explored - On Premises, AWS, Azure and GCP

This article illustrates the steps to set-up a lab to test the SSH Gateway capability of Infrastructure Service.  This capability provides secure access to on premises or IaaS (AWS, Azure or Google Cloud Platform) systems leveraging the Secure Shell protocol (SSH+File Transfer).

Centrify Infrastructure Services provides a full-fledged secure shell and file transfer capability (SSH Gateway).  This "jumpbox"  supports all the core features of the platform including multi-factor authentication, workflow, real-time monitoring and session capture and replay.

Goals of this Lab
  • Identity Consolidation:
    • Leverage existing Organizational Directory Services.
    • Accomodate for user populations outside the organization (e.g. Federation, other Directories, etc).
  • Usability:  Provide secure access to systems running the SSH Service without visiting the Centrify portal.
  • Access Control:  Align with best practices for security access controls, like:
    • Identity Assurance via Multi-factor Authentication.
    • Adherence to the Least Privilege principle  (users shall only access systems and accounts that they have a business need to access).
  • Auditability:
    • Event tracking (who, what, when).
    • Allow the real-time proctoring of shell sessions as well as the session recording to be replayed later (e.g. PCI DSS 10.2.2).
  • Simplicity and multi-use:  Provide these capabilities with minimal infrastructure or to reuse components of Centrify Infrastructure Service (E.g. leverage other services like AD or LDAP Proxy, or RDP jumpbox services).

  • A Centrify Infrastructure Services instance (SaaS or Customer Managed) - 17.10 and above.
  • A Centrify Connector running the SSH gateway in all the subnets required for SSH jumpbox access.
  • A handful of test systems running the SSH Service.
  • SSH and sFTP client software.
  • If testing "true MFA": An OATH OTP, configured RADIUS token or enrolled Mobile Authenticator.
  • Familiarity with Centrify Infrastructure Services.
    • Policy and Authentication Profiles.
    • A configured "Corporate IP Range." 
    • Familiarity with CPS Roles, Permissions and Sets.
  • Understanding of the communication paths for CPS (e.g. between connector and instance (HTTPS), between connector and SSH Servers (standard SSH port TCP 22).  Note that these ports are customizable.
  • Understading of Infrastructure Services Role-based Access Control.

Conceptual Diagram

This diagram showcases the major components, the location, firewall rules, and additional details depend on the environment.

Diagram for this Lab

High-level Implementation Steps
  • In this implementation, I'm using an AWS VPC as my "corporate HQ"  it has an AD domain, some systems (Windows and Linux) as well as a hosted AD domain.  This will allow me to have different user populations.
  • I am leveraging an existing Active Directory and DirectAudit infrastructure.
  • Launched a Windows 2012 R2 instance with a public IP address, Fthis instance is in a security group,  that allows inbound HTTPS and SSH from the internet to the instance, plus it can reach the rest of the systems internally, including AD (to allow for it to be joined).
  • For internet name resolution, I created a CNAME record in the DNS domain for the cps record that resolves to the public DNS name for the EC2 instance above
  • Obtained a publicly rooted certificate, and exported it with the private key for Privilege Service to use.
  • Installed Privilege Service (on-premises) in single-master mode (no HA);
    Note:  The single-master configuration does not provide HA or allows for upgrades.  This is for testing purposes only.
  • Added a Centrify connector with the adproxy and SSH gateway services.
  • Configured Privilege Service to use my ISP's IP address as part of the corporate IP range.  This is to provide the assurance that only I can access it.
  • Configured 2 roles:  An Administrator, and a Least Access role.
  • Configured Workflow for the resources.
Microsoft Azure
  • Created inbound rules that allow the connector in AWS to reach the systems over RDP and SSH.
    Note: Depending on the services needed, an additional connector in Azure (or GCP) is needed.
  • Launched existing Windows and Linux systems.

Test Matrix (Success Criteria)
Identity ConsolidationUsers from Active Directory and Centrify Directory can access systems via Web Portal or SSH Gateway.Pass
Identity Assurance with MFAUsers must use an MFA or Step-up method to authenticate via Web portal or SSH Gateway.Pass
PolicyUsers can only access from a specific subnet.Pass
Least AccessUsers can only access the systems based on business need to know via Web Portal or SSH Gateway.Pass
Access RequestUsers must request temporary access to shared accounts.Pass
Monitoring (real time)SSH/RDP – Sessions can be monitored in real time.
SFTP – Active sessions can be tracked.
Advanced AuditingSessions can be reviewed after the fact (indexing, replay, etc.)Pass
Infrastructure Simplicity and ReuseThe same components can be used for other capabilities (e.g. RDP, etc).Pass

Test Videos
Identity Consolidation and  Assurance with MFA

Policy, Least Privilege and Access Request

Real-time Monitoring  + Session Capture and Replay

Infrastructure Simplicity and Reuse

Monday, September 11, 2017

Centrify's Support for IBM i (AS/400) with Privilege Service

In a nutshell
  • Centrify Infrastructure Service provides support for AS/400 systems
  • Versions 6.x and 7.x (although 6.x will be EoL soon)
  • You must be running SSH on your AS/400
  • Apply all platform PIM features (Policy, MFA, Workflow, RBAC, SSH Gateway, etc)
  • Secure Access via SSH
  • Password Lifecycle
  • Support for different password profiles.

See it in Action

Friday, September 8, 2017

How to check out passwords from the CLI using Centrify Infrastructure Services

How to check out passwords from the CLI using Centrify Infrastructure Services
As part of the security toolbox, we must deal with shared credentials, more specifically passwords.  Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases.  In this article we'll discover the options available to retrieve passwords from the CLI and we'll focus on using it as a way for programs or scripts to retrieve them.

Using shared passwords in CLI scenarios while maintaining assurance
Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials.  However, at the same time we need to maintain assurance and enforce principles like:
  • Try to eliminate passwords
  • Limit lateral movement
  • Just in time/just enough access/privileges
  • Identity Assurance
  • Monitoring and Auditing
  • Policy enforcement, etc
The maturity model illustrates this best:

Eliminate Passwords
Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party.  The enrollment process looks like this:

Each system is represented by a service account in Centrify Infrastructure Service.  Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system.

In Linux, this is implemented with the cenroll command.  If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here:
sudo cenroll --tenant vault.centrify.vms --user admin@opie.demo 
--verbose --features all --agentauth identity-broker-users 
--name centos7 --address centos7.centrify.vms

If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code:
Enroll-CIPSystem -EnrollCode "THISIS-YADA-YADA-CODE-682DBEF6CA78"  
-FQDN 'member.centrify.vms'  -ResourceName 'member-vault' 
-Endpoint 'https://vault.centrify.vms'

Access Control, Entitlements and Visibility
Centrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation.  In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform.  Centrify includes a built-in group called:  Centrify Agent Computers;  by default, this group has visibility to systems, domains and databases.

As a best practice, don't overload the Centrify Agent Computers built-in group.  Just use it for visibility purposes.  Create sets and other roles, and leverage those instead.

For accounts, there are several entitlements

This means that you need View+Check out at the account level to check out a password.  This is a mechanism for least access and limiting lateral movement.

Policy Enforcement and Monitoring
The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.

A great policy that can be implemented is the use of internal/external, datetime or even Risk.  This can be applied at the account level.

Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like:  Dashboards, Reports or the ability to send events to a security operations or SIEM tool.

Deployment Utilities
  • Enrollment codes:  allow Centrify clients to enroll the platform automatically.  The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.
  • Sets:  Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.
  • Packages:  The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.

The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).

Here's more info about cgetaccount.
Here's how it looks in PowerShell  (checking out the sa SQL server account from the database enterprise for 2 minutes)

Note that these examples are interactive checkouts.  Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable.  Notice that you can specify the checkout lifetime.

This is an area of a lot of interest for Centrify.  Stay tuned.

Friday, April 28, 2017

Examples of Identity Assurance with Centrify MFA in AWS (Console, EC2 and CLI with PowerShell)

Note:  This is a repost of an article I recently wrote for the Centrify Community Techblog

Centrify recently commissioned a study with Forrester Research that yielded some important information about the state of Security.  Bottom-line, we have decided to throw money and resources to the problems around information security rather than rethinking our approach, the results are more breaches and exposures.
You can access the study results here:

A key conclusion on over 200 organizations surveyed is that those with higher Identity and Access Management (IAM) maturity were breached 50% less while maintaining operational efficiency. 

As you read the previous paragraph, you may ask yourself: what is the first step the journey to the continuous improvement required for IAM maturity?  As illustrated in the model below,
a the key component is to establish identity assurance with technologies like MFA or PKI, however this is challenging enough because many organizations have not achieved this on-premises, much less in IaaS/PaaS platforms like Amazon AWS.

This is where Centrify can help.  This article is about guiding you on how to use the Centrify platform to establish identity assurance in several use cases:  
  • Accessing the AWS Consoles with shared accounts (like Amazon root) or Federated identities
  • Accessing EC2 instances locally (Linux or Windows)
  • Accessing AWS commands via the CLI (E.g. PowerShell or Python)
Please note that identity assurance concepts apply to both users and systems (due to API access);  in this use case we'll focus on interactive (user) use cases.  For system/system or app/app, other mechanisms like PKI or Kerberos can be used and we can cover in another entry.

The Centrify Advantage
The biggest advantage for Centrify lies in it's platform and integrations, as a company that covers both Identity as a Service (IDaaS) as well as Privileged Identity Management (PIM) we understand that everything starts with Identity Consolidation.   This is not the "legacy" (metadirectory/connector-based mid-2000s) identity consolidation, this is the "straight-to-the-source" standards based approach using Federation in the IDaaS side, plus direct-integration (with Kerberos) in the case of heterogeneous OS platforms.  We add to this a series of services:
  • A policy service
  • A multi-factor authentication engine (that includes modern and legacy-based support)
  • A risk-based engine (analytics) 
Our native integrations with Active Directory make us a prime vendor to consolidate capabilities;  here's an example, if an organization wants to secure access to a web app, integrate a non-windows platform to a central directory like AD and get MFA, they may engage 3 distinct vendors, however Centrify can help with world-class solutions on the three areas.  Let's look at a the examples.
Securing Shared or Federated Access to the AWS Console
Centrify Identity Service provides several turn-key templates to help with shared or federated (via SAML or using the AWS API) SSO for Amazon Web Services.  We have covered these integrations here:

However, the powerful policy engine and the support for multiple authentication profiles makes this integration simple and flexible.  
Here's a quick demo on how this integration is enabled and the user experience:
Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to Linux and Windows AWS EC2 Instances
Centrify Server Suite provides native integration with Active Directory, regardless of your deployment model. 
By leveraging AD (hosted by you or in AWS), you are eliminating the duplication of identity sources caused by SSH keys with the addition of DirectAuthorize technology that provides role-based access control and privilege elevation and is fully-integrated with the policy and authentication profiles provided by Identity Service or Privilege Service.  We have discussed these integrations here:
Provided the Identity Service/Privilege Service setup is correct and the proper PKI trust is in place, for Access and Privilege elevation, all we need to do is set up the proper checkbox at the role, UNIX command or Windows desktop or application.
Here's the user experience that meets the requirements for identity assurance via MFA for both Linux and Windows in the context of access and privilege elevation.
Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to AWS CLI (e.g. PowerShell)
Administration of AWS Services is often performed via the AWS CLI (implemented via Windows PowerShell or UNIX CLI).
If you're using Centrify Identity Service with SAML federation into AWS, you can implement the SSO plugin provided with the template.
Here's the user experience in PowerShell.  Note that the experience will be based on the authentication profile that applies to the user by policy.
If you have multiple roles, you get to select them:
Finally, the authentication token is stored in the $me variable and the user can move-on to use AWS PowerShell commandlets.   See the pattern here?  Identity assurance with MFA and role-based access without compromising usability and achieving this with with a single solution set.
A cliché of business schools is the statement "you can't manage what you can't measure"; but since we're dealing with IT security, you may want to track how we are performing towards our goal of consistent identity assurance, in these AWS examples, we can use AWS CloudWatch metrics to measure the percentage of access in the proper context (e.g. Console, EC2, etc) is performed with assurance.  Therefore a good metric to track would be:

MFA events are tracked for Linux, Windows and Identity Platform, this allows you to be creative and get information from CloudWatch or from Identity Service.
Note the CloudWatch widgets above.  In my Linux space, I have a ratio of close to 60% identity assurance (4 out of 7 successful logins were with MFA), however my track record on the sample data I created on Windows is much better (100%).  You use the same approach for privilege elevation via Centrify-enhanced sudo or Centrify Agent for Windows.

In the case of Identity Service or Privilege Service, the platform provide dashboards and reports like the Security Overview - User Logins
These dashboards allow for reviewing information within 7 days or 24 hours and to look at specific date-time ranges. 

Identity assurance is closer than what you think, with the "barriers of entry" for MFA solutions going down, it's all about working with the right partner and Centrify excels at securing apps, endpoints, infrastructure and secrets; finally, the obvious challenge is organizational dynamics;   If you still have groups opposed to centralizing directories or maintaining legacy infrastructure, you can split the project in several phases and attack the platforms that are easier from a people/process standpoint.  Once you can demonstrate identity assurance within those applications or infrastructure, it's going to be hard for those "holding on to the past" to ignore that the best practices are here to stay. The model applies to all aspects of any risk-sensitive information technology area and like every other framework it's not a silver bullet; new threats, attack vectors, compliance requirements and tools are introduced, therefore this has to evolve as well.